software

What all programmers have in common

Bycoliveira May 12, 2009October 23, 2009

I have been working on software development for some time, and have seen a lot of different styles of programmers. There are the ones that clearly have a lot of talent and produce a lot of output. Others don’t have much talent, and are also not interested in improving their skills.

Experience has shown that there is a large gap between developers in terms of productivity. In some cases, it has been found that the best developers can produce software ten times faster than mediocre ones. This result has been validated independently of the language or tool used to develop software — which shows that the productivity gap cannot be easily fixed.

However, there is one trait that seems to be unchanged across programmers, the good and the bad ones. And this trait makes most of the schedules for software development to be late by some margin. The feature is that all developers are essentially optimistic when it comes to the time needed to create a new piece of software.

Bad programmers are clearly easy to blame on this area because they are slow and the software they create is of low quality. However, even good developers suffer from this problem. This mostly happens because of our tendency of overlooking critical aspects in the development process.

For example, although the programming time to finish a feature is 20 hours, this does not include the time necessary to attend meetings with a customer, or to optimize a database, or even to enter issues into the bug tracking system. All of these activities also count towards the working time of any developer, and need to be taken in consideration.

Fixing the Gap

The good news is that good or bad programmers can do something about their time management issues. Here is a quick list of things that I tried myself with good results:

Maintain a log of how your time is spent. It is amazing how we usually don’t have a clue about how we spend our time. As a result, we just spend a lot of our time on areas that don’t provide enough return. By keeping a log, we can start to see where we need to cut some slack and where can we put some additional effort.

Increase your estimates by a factor. Once you get some experience on where your time is spent, you will be able to estimate what percentage of your time is spent on software development, and what time is spent in related activities. This factor is different for each situation. For example, companies that have lots of meetings will require a bigger factor compared to the ones where such formalities are not needed. Find a factor for your situation and apply it to your development estimates.

Learn to say no. A big problem in schedule estimation is that what you’re supposed to do might increase, while the time allotted to the task doesn’t. In this case, you need to say clearly that you think the time is not enough for the planned feature. Saying so is better than having to cope at the end with a late project.

Conclusion

Programmers have a common tendency to schedule less time than necessary to finish a set of features. It is a natural tendency that we have, and it happens because we don’t take the time to think about the extra tasks that everyone needs to go through. By carefully understanding your personal work flow and by learning to say no to things you can’t do, we all have is a big opportunity to improve the accuracy of our programming schedules.