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.

Further Reading

• Mythical Man Month: an earlier view on scheduling issues for software development.
• Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software.
• A proposal for better software schedules, by Joel Spolsky.

Related Posts

• Why Learning Prolog Can Make You a Better Programmer
• New Features of C# 4.0
• Book Review: Effective Java 2nd Edition

Here are some topics I twittered about during the last week

• Clojure 1.0 (Lisp for Java) was released today: http://tinyurl.com/cl35jj 
• how to recognize a bad programmer: http://tinyurl.com/679c2s 
• Using Git and Svn at the same time: http://tinyurl.com/cu5tel 
• new features of C# 4.0: http://bit.ly/FiqUJ 
• amazon has released the new large-size Kindle: http://bit.ly/28V8D 
• first reaction: cool, finally it can display PDFs
• second reaction: I have better things to do with $500
• interesting discussion: what is the Obidos in Amazon? http://bit.ly/eiNnO
• it turns out, Obidos is a city in Brazil
• it is by the Amazon river
• A first view of Microsoft Solver Foundation http://bit.ly/7Mgxi
• company that created Wolfstein-3D goes bankrupt: http://news.bbc.co.uk/1/hi/technology/8037688.stm
• but they spent 12 years trying to finish a game… :-)
• nice description of .NET and C# internals: http://bit.ly/jZDs7
• Google is dominating the mobile market: http://www.reuters.com/article/bigMoney/idUS53191739520090507 
• everybody knows I like Prolog: http://bit.ly/jy7vI
• automatic translation now on Google connect: http://bit.ly/11qdlC
• review of virtual functions in C++ http://bit.ly/J7ecV
• how to use Google analytics effectively http://bit.ly/uPJJG
• In my opinion, the most essential book for software developers: http://is.gd/y7V1
• Translucent windows in Java 7: http://www.pushing-pixels.org/?p=1209 
• Princeton will give free Kindle-DX to some lucky students: http://bit.ly/SUzSs
• a new parallel language from Microsoft: http://bit.ly/TMODg 

In Computer Science programs, there is a tradition of having a course of two that represent the watershed between people that can grok CS concepts and the ones that can’t. Although anyone can do some programming in a language like Java, where anecdotal evidence seems to show that the most complicated concept is class, it takes real intelligence to do something useful in C or Lisp.

At my Alma mater, a course in Prolog was the division line between the hopeful and the real CS guys. The reasoning being that if you could get your head around a Prolog interpreter written in Prolog, then you can probably handle any programming concept.

These days however, CS programs are more interested in teaching marketable languages such as Java, Python, or Ruby. It seems like that they are looking for ways of getting people through the program as quick as possible (maybe before they realize where they are really going into).

A little of Prolog

Nowadays Prolog is not as trendy as it used to be, although at one time it was the main competitor of Lisp as a high level language for complex applications (at least for AI-people living in Europe). However, it is often said that it is an advantage to learn Lisp even if it is just for the learning experience.

I think it is just as fair to say the same of Prolog, and here are some of the reasons why Prolog still has something to teach most programmers.

Prolog can be though as a pure functional language. In fact, it is so pure that the only values it returns are the literals true or false! In Prolog, everything happens as a binding of parameters, so there are no variables to update — only method calls, which will match parameter values to formal arguments.

The language provides a simple mechanism for accessing databases. Databases are viewed in Prolog as a set of facts that can be consulted by the rules. In this way, access to external data is treated in a logical fashion, instead of requiring imperative actions to fetch and read data. The Prolog model provides reduced impedance between code and data, which is a good thing.

Provides a simple way to represent declarative programs. Prolog is based on matching rules in a way that is transparent to developers. It tries to satisfy the requirements of each declared boolean function using its internal rule-matching engine. It is easy to think of this as a non-deterministic machine that just does the right thing as needed, without programming intervention. Of course, this machinery won’t solve any problem without some additional help, but by necessity it frees the developer from thinking on how things are done, and concentrate instead in what is being done.

In summary, I think that good programmers should explore alternative ways to create software. Learning languages with a different paradigm, such as logic programming, is an excellent way of challenging traditional thinking processes. Understanding how things could be written in Prolog may provide better solutions to practical problems, even if you need to write the resulting code in C.

Further Reading

There are not many new books devoted to Prolog, but here are some of the classic along with a few more recent ones:

The Craft of Prolog (by R. O’Keefe), which has been the source of a lot of fun since I first started playing with the language. That is still the best source of wisdom when working with Prolog.

The Art of Prolog (by Sterling and Shapiro) is another classic that describes the language in detail, along with some more advanced applications.

Programming in Prolog: Using the ISO standard is a more recent one, worthy the price because it describes the Prolog standard in detail. It should be part of any serious Prolog developer’s bookshelf.

Prolog Programming For Artificial Intelligence (by I. Bratko): a best-selling guide to Prolog and Artificial Intelligence, which has been updated to include key developments in the field.

Logic Programming with Prolog (by M.Bramer): a great tutorial of logic programming using Prolog as the main implementation language.

Clause and Effect: Prolog Programming for the Working Programmer (W. Clocksin): A subset of Prolog is used to demonstrate important concepts of the language.