What all programmers have in common

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.

About the Author

Carlos Oliveira holds a PhD in Systems Engineering and Optimization from University of Florida. He works as a software engineer, with more than 10 years of experience in developing high performance, commercial and scientific applications in C++, Java, and Objective-C. His most Recent Book is Practical C++ Financial Programming.

Published on May 12th, 2009

8 Responses to “What all programmers have in common”

I would like to thank you for your tip. As a web designer, this might be applicable to me as well.

By Alvin on May 12, 2009
@Alvin,
Thanks for your comment. I agree this is applicable to many knowledge workers. It is just that programmers are very susceptible to this kind of problem.

By coliveira on May 12, 2009
Most of the experienced programmers I know are actually very pessimistic about how long something will take.

It is the people who do not write software (managers, customers, etc.) who tend to underestimate and insist on unrealistic schedules.

Programming projects are almost always behind schedule because the people who have the final say on schedules are managers who do not understand the process of writing software.

By m on May 12, 2009
I don’t think this trait is limited to programmers; it’s a general property of human psychology.

http://www.overcomingbias.com/2007/09/planning-fallac.html

Personally, I like the following metric (I think I picked it up from Old New Thing): double the number and increase the unit. 3 hours becomes 6 days, 2 weeks is 4 months, etc. It’s been quite accurate so far :)

By Sharkey on May 13, 2009
What works for me is to
(1) estimate the time needed to complete a project if there are no major problems along the way, then double it
(2) do two versions of the project at the same time. The first version is what the customer wants. The second version is a list of all the ideas my programming team comes up with while doing the first version. Acknowledging their ideas by keeping a list (a) makes them feel more engaged with their work (b) keeps my team thinking about better ways of doing things (c) stops them from implementing their ideas before version 1 is finished (d) gives us a list of improvements for the next version to keep us ahead of the competition.

By Mike Lewis on May 13, 2009
I translated this article into Chinese. The url is http://chemhack.com/cn/2009/06/what-all-programmers-have-in-common/ . The translation is for non-profit purpose.

If you’re not comfortable with this translation, please let me know.

By Duan Lian on Jun 1, 2009