It started happening while I was still at college. We students have informally divided into two groups, us that were constantly digging for more knowledge and them that were telling us that we will just be stupid programmers. We wanted to be great at software development, but they said that we will be zombies staring at out monitors for the rest of our lives. They had different future in mind for them, where they would be very smart without any effort, work little and be very good paid for that. My favorite quote from them was "I won't be a programmer, I will be a consultant to other programmers" ... straight from collage. Imagine that!  Or "I will stay at the collage and teach others on the advanced software development techniques"... techniques they have never experienced.

Think of some person you admire for what they have achieved in their profession. Do you think they earned your respect by being talented or with their passion and hard work? Do you think they were stupid to push so hard?

Albert Einstein was committed to his work but I never heard anybody says that he was staring at formulas for the whole day. Nobody complained that he was always lost in his taught or that his clothes were always wrinkled. And what about Jimmy Hendrix, when you think of him, do you think he was a freak locked up in a room all day long with his guitar? What about Michael Jordan, can you even imagine his commitment to basketball? Do you know he was rated as untalented player when he was in high school?

READ MORE...

In my previous blog post I have mentioned that most of our job candidates state in their CV-s that they work great under pressure. The thing is ... nobody works grate under pressure. The only difference between people is whether they break under pressure or not.

The pressure is something well known to probably every programmer, but hopefully it isn't present every day. When I say pressure, I don’t think of managers forcing programmers to code for long hours. I rather think about situations when you must finish something that you care about very much, but the situation makes it almost impossible.
This is often the truth for developers because we:

• have deadlines,
• do complicated things that are error prone,
• lack engineering practices and tend to throw the ones we got the first time we hit the wall

Because pressure is probably guaranteed thing, first thing we can do is become aware of it. I have met two kinds of pressure: negative and positive.

READ MORE...

Last few months Soprex was hiring new people which also meant I had to:

• read a lot of CV-s
• hold technical interviews
• judge people
• neglect my regular duties

As you can guess I wasn't too happy about it because I had other important staff to do and I don't like judging people, especially not based on some resume.  But still, this is a small effort compared to potential impact on our firm. Last thing you want to do is to misjudge people and spend few months getting them in the business to find out that it is not going to work out.

David Parnas said:

Q: What is the most often-overlooked risk in software engineering?

A: Incompetent programmers. There are estimates that the number of programmers needed in the U.S. exceeds 200,000. This is entirely misleading. It is not a quantity problem; we have a quality problem. One bad programmer can easily create two new jobs a year. Hiring more bad programmers will just increase our perceived need for them. If we had more good programmers, and could easily identify them, we would need fewer, not more.

 [READ MORE]

Few days ago I saw same ordinary scene on street while going to work that got me thinking... about code off course :) Car driver was complaining to parking service employee about a parking ticket he has just received. He said that he was late for only 15 minutes (parking ticked is valid for 2 hours and drivers are notified with SMS 15 minutes before expiration). At the first moment I taught that 15 minutes isn't that much of a big deal, but then I started thinking what about 20 minutes? Still OK? And 30 minutes? Too much?

The real question is where to draw the line? Because we obviously can't do this, the right answer is that there should be no tolerance. OK maybe 60 seconds :)

You said something about code?

Unfortunate driver reminded me about a question I often encounter on my work. Is all code important? Should really all code follow best coding practices and coding standard? (READ MORE...)

As programmers fight every day with deadline pressures to deliver meaningful software to customers on time, there is one code principle that can speed up and simplify their effort. This principle is called YAGNI, which is short for "You Aren't Going To Need It".

YAGNI is the principle in extreme programming stating that programmers should not add functionality until it is necessary, meaning that you should always implement things when you actually need them, and never when you just foresee that you need them.

The reason for enforcing this principle is that anticipation in software is very hard and usually leads code off track, while also spending valuable resource - time. Anticipation leads to half baked implementation that you maybe didn't need in the first place, and that implementation can turn out to be constraint on implementing some vital functionality that you really need. So what you have is lose-lose situation, you wasted your resources and made situation harder for yourself.

Ron Jeffries, one of the 3 founders of extreme programming, said it like this

Often you will be building some class and you’ll hear yourself saying "We’re going to need...".Resist that impulse, every time. Always implement things when you actually need them, never when you just foresee that you need them.

The best way to implement code quickly is to implement less of it. The best way to have fewer bugs is to implement less code.

You’re not gonna need it! 

(READ MORE)

As I already announced, I have held two presentations at Sinergija 2009 in Belgrade. Presentations were on the same subject as my previous two presentations in .NET Belgrade user group, only this time they were more refined (I hope). I approximate that I had around 100 listeners at both presentations which is my new record

1. #24H Code Refactoring - download presentation | browse online
2. #26E Coding Standard & Code Review best practices - download presentation | browse online

When two men in business always agree, one of them is unnecessary. ~William Wrigley Jr. 

This is another post dedicated to team communication. In previous posts I have already stated that communication is important and that two people are more likely to solve problems. Today I will talk about importance of early feedback, and regular developer sanity checks.

Earliest Feedback

In every agile development early customer feedback is very important. Today I will talk about even earlier feedback… I mean feedback from your team members. This is earliest feedback you can get and maybe most important, because often this is only technical feedback you can have.  If you are building some API or planning some architecture, than at that point other programmers are your customers as your API users.

The question is why is this feedback needed any way? Thes because variations, combination and potential code usage scenarios are uncountable. Ok, maybe they can be counted, but rest assure that when the time comes, you will not have them all in you head. One more thing we want to avoid with this is over-engineering.

So tell your ides to your teammates and ask them for opinion. If you do this, you will often hear the phrase "The problem with that is...". And there it is, one future gotcha you have just avoided.

In the past I was annoyed with this feedback that was constantly proving my "super" ideas wrong, but today I cherish them as a proven strength of positive critics. Always give, cherish and encourage positive critics in your team.

Another way to look at this early feedback is as early WTF?!. Instead of living some other developer  thinking many WTF!? while trying to understand your code, you cam tell your ides and wait to here WTF!?.

READ REST ON MY BLOG>>

Last night I have held presentation about Coding Standard and Code Review at Microsoft Serbia quarters in Belgrade. This was resumption of previous presentation on Code Refactoring. In amazing 3 hours I have managed to break every record (rule) regarding presentation length, so I want to thank all of you who came and survived. I know it was hard but I can only hope that it was useful.

For all of you who are interested in these subjects but couldn’t make it, I will be holding these two presentations in November at Sinergija.

You can download presentation here or browse it online here, and see photographs here.

Here are some useful links:

• Style Cop team blog
• Code Analysis team blog
• FxCop Warnings
• How to hold a more effective code review
• Checklist of things that you should look for during a code review

... And here are some funny links

• KLINGON GUIDE To Writing Perfect Code
• Cargo cult programming
• Unusual software bugs

In my previous blog post, I have stated that communication is very important for programmers, and maybe essential for successful teams. Today I want to clarify this subject by defining jet another guideline: Two heads are smarter than one. What this means is that two people are more likely to solve some problem faster and better.

Let’s put this in context of real programmer’s working day: you are trying to solve some problem, you cannot find good enough solution or you cannot decide which alternative solution to choose or how to organize your code, you aren’t sure will underlying technology cause problems…

What can you do about it?

You can do your best to focus, you can “google” solution all day long, you can pool out your hair trying to fit all that information in your head at once… or you can just ask for help person sitting next to you.

Often it is enough to try to explain some problem to another person and to see for yourself where you have gone wrong. If this doesn’t do the trick, your colleague already has advantage over you in solving the problem because he is approaching it from a different angle. It can be that coulage is more expirience with that kind of probelm, or that he is the developer who wrote original peace of code. Maybe he has already solved that problem, maybe he read something about it on the Internet, or maybe he knows that someone else in firms knows solution. It may also be that he is smarter than you, which again is great thing because what’s important is that problem is solved with little effort and that you learned something.

If all of these positive sides of communication didn’t solve the problem in first 2 minutes, you and the colleague are left to use power of brain storming, to inspect solution variations and alternatives.   The catch with programming is that it is very complex and that if some problem is not solved 100% than it isn’t solved at all. You can’t say to your customer, “I can obtain all data you need but I don’t know how to show them to you, can you pay me half?”  Sometimes you solve 95% of the problem for few minutes, and can be left struggling to solve rest 5% for days. Maybe your colleague has 50% of the solution, but it includes your missing 5%.

Other great thing about this rule is that motivates people to share problems. Beside the advantage of collective problem solving, it is great means for informing others about project state and sharing knowledge patterns in form problem -> solution. This way, some programmer is less likely to get stack solving problem that someone have already solved.

Read rest of the post on my blog >>

Yesterday I held presentation about Code Refactoring at Microsoft Serbia quarters in Belgrade. Main focus of this presentation was how to improve quality of code and what are the benefits of code quality.

Because of the last night games, we didn’t cover Coding Standard, Code Review and available tools for checking code quality and refactoring it. These topics will be covered in next presentation for which date is not yet set. Below is last night presentation. If you have any questions about it, please share them with us, I would be happy to apply.

Vukoje.NET - Refactoring

Few months ago I found out about a book How to Win Friends & Influence People by Dale Carnegie that was recommended by Joel Spolsky:

Finally, and I know it sounds cheesy, but Dale Carnegie’s 1937 book How to Win Friends & Influence People is actually a fantastic introduction to interpersonal skills. It’s the first book I make all the management trainees at Fog Creek read, before anything else, and they always snicker when I tell them to read it, and love it when they’re done.

Well, book did sound really cheesy. Accidentally I came across this book in audio format which duration was little more than 5 hours. The book was short, simple, pragmatic and surprisingly reviling. It focuses on people relations, communications and misunderstandings. The whole book is composed of real world anecdotes so messages are clear and very easy for listening. The book main lesson on people relations (in my own interpretation) is: listen, understand and respect other. For summary of all advices see this link.

Who is this book for?

Well book title sounds like a weapon for some insincere and manipulative manager, but turns out that it contains useful lessons for everyday life and surprisingly useful in everyday work of  an engineer.

Programmers and Communication

Programmers, probably like any other engineers, aren't focused so much on people relations in every day work. They are focused on technical issues that are very much enough for consuming person's whole taught in one day. Problem is that problems being solved by programmers tend to be complex and like that are better solved when more brains are involved in synergy. 

Problems being solved by programmers are such that there is no “one right solution”, so informed decisions must be made by team members on daily basis and all team members should be aware of them. Usually, decision process consists of every man contributing with ideas. All ideas are valuable in some way but small amount of them will be accepted. This can lead to broken pride and programmers are known to have ego issues.

From all said above it should be clear that good engineer should also be good communicators. If we take a look at Scrum, we'll see that basically Scrum Master is playing role of communication facilitator in software development. That’s how important is communication in Scrum.

Avoiding Confrontations

One of the best advices I have received from this book is “Avoid arguments, you can only lose”. [... read more on my blog]

Last month I have attended Scrum Master training at Faculty of Organizational Sciences in Belgrade. My mentor was excellent Dan Rawsthorne, with huge experience in production and strong hold in agile development. His experience gave his opinions huge credibility and his agile approach gave me a completely new view point to Scrum compared to one I have gained from Ken Schwaber’s book.

Here is list of my most interesting notes from training:

Agility:

• Brains solve problems, not processes. Process should only exist to enable focusing on brain power. Scrum is designed to force us to make hard decisions.
• Agility is opposite to prediction. We can not control the world, we can only adapt to it and that requires constant attention which is hard. Waterfall gives illusion of control and false comfort.
• “Every team member is doing the best they can, but not the best they could be doing.” This is really interesting statement and I think that one should always remember it when evaluating and improving team abilities.
• Programmer’s job is to create value, not to write code.
• Perfect is the enemy of good. Good is what we want, perfect is impossible.  
• There are no “I don’t knows” in Scrum, every decision has to have good reason which should be known to all (or most of) team members.
• Scrum is about committing, not about knowing. If you focus on knowing, you will be too slow. If you are not sure, build something and get feedback as fast as possible. You are committing to agreement, not to tasks. Tasks are there to help you commit. Do something and than get better.
• You can not build quality back in to the code, you can only replace it. Regular questions like “Has anyone written code he’s not proud of?” can help identify problematic implementations. If they can’t be addressed right away, related correction tasks should be added to product backlog.

(Read rest of the post on my blog)

This week I have attended Microsoft one day conference DevDays 2009 committed to fresh and soon to come Microsoft development technologies. Excitement as one geek can be, I still was annoyed by new technology rush, so I wanted to share some of my taught on that subject.


Term explosion

When ever I hear about new things I find my self in mental process of translating them in set of terms that I understand. This probably is related to lack of IQ but it is mainly due to term explosion. Every new thing that comes out has to have some cool name although problem is widely known and defined few decades ago. Please, don’t do this.

Technology and problems

Technology is here to solve problems, so to use it you first need to have a problem for solving. If you don't have problems, new technology will bring them to you. New technology needs to be learned and the God knows what errors it has. Yes, I still have urge to use newest, fanciest tool, but can I justify it to my manager? Best thing to do when you get existed about the new stuff is to ask what are the technology faults, and rest assure it does have them. Following are some of the question:

• Will it take too much time to learn it?
• Will other developers except it and learn it good enough?
• Are enough resources available?
• Are there any major issues?
• Will the product be supported over next few years?
• What about performance? 
• What are software and hardware requirements for running it?
• Is the software mature and fast enough?

I will quote Facts and Fallacies of Software Engineering:

• Hype (about tools and technology) is a plague on the house of software.
• New tools and techniques cause an initial loss of productivity / quality.
• COBOL is a very bad language, but all the others are so much worse. 

(Read rest of the post on my blog...)

When you want to do something, next question always comes up “What should we do next?” The answer will differ if you are making decision what module to develop in next few months, or you are wondering what functionality to code next. 

Choosing next module

When you pick a development task for a longer period, always pick the hardest one. This approach is also called “Swallow the biggest frog first”. This means that if you will be developing some software in period of one year, in first quarter you should tackle all biggest risks and most difficult implementations. These hard problems must be solved before project is completed and if you delay them:

• they will only become harder because already implemented components introduced higher complexity
• you will not have sufficient time to solve them because you already burned big amount of time solving less important issues
• it is more likely that important feedback will come too late when too much time and money is spent 

This approach will lead to early pain in project, where you have large problems right on project start. You should cherish early pain because alternative is slow and painful project death.

Choosing next functionality

When you are choosing next feature the code, choose the smallest/simplest one that will work.(READ MORE)