10 Reasons why creating a program takes longer than it should

June 27, 2007

The following is a list of annoying timewasters that I seem to stumble on over and over again… Bigger projects face more of these potential timewasters, making estimates more inaccurate.

10 - Coding Style Issues: I’ve had discussions about where to place {, whether it is better to have long lines on 1 line (and use the scrollbar) or on several lines. About prefixes for variables. The list goes on and on. The fun part about the discussion is: Nobody listens to your arguments, because it’s all about personal preference. Why can’t we just all agree on my style?

Tools like Checkstyle seem to magnify the problem rather than make it disappear.

9 - MS Word - An extremly poor tool to communicate requirements.

8 - Deploying: How much time should be between successfully testing a feature on the developers machine and getting that feature on a server for everyone to try out? In some places, the real work just begins at that point…

7 - Mapping Data, Data migration: Whenever you get in touch with data that needs to be moved from one system to another, you’re basically doomed. Services (of the SOA kind) can be just as painful. There is so much “data mapping” going on in Enterprise environments that I think it would make sense to find a new Job Title for the ‘Datamapper’.

6 - Strange Server Behaviour: Things that should just work, don’t. Of course, sometimes they do. The problem usually lies in your code - well, that doesn’t make it easier, because you think the problem lies somewhere else. For example: This is wrong. So wrong.

5 - classpath/dll mess: I don’t remember how long it took to find out exactly which dll made Crystal Reports crash. But it wasn’t fun to find out and it was more than a day. The same applies to “commonly used java jar files”, which are copied all over your system - often in different versions. It’s almost guaranteed you have the wrong one in your classpath.

4 - Useless Errormessages: Try integrating MS Office. No matter what you do, if something goes wrong a very helpful message appears. Like ‘Error’. Or my alltime favorite from the Jet Engine: “Reserved Error - There is no message for this error.”. Nothing beats a little humor in your daily life - especially when the deadline is close…

3 - Defects (aka bugs): Creating a feature is sometimes rather trivial. So is it justified to spend 1 h to write unit tests for a feature you can implement in 5 minutes? Well, you can always skip it and then spend 3 h testing and 3 h debugging next week, when sombody else broke your feature. Good thing the fix only takes 5 minutes (never mind that an other feature might be broke by the “fix”).

2 - Communicating with other systems/programs/services: It all looks nice and harmless. Always. OK - You have to map data, which can be a problem (see point 7).

If something doesn’t go right (and it never does) you sit there with no possibility to find out why - because you don’t have access to the logs of the other system. If you’re lucky you get an error (See point 4). Sometimes you’re not lucky and you just sit there and the stupid thing doesn’t do anything.

And don’t even get me started on Character Set Encodings. Retrieving data from an other system: 1 h. Figuring out why you get a ‘?’ instead of an ‘€’ sign: rest of the week.

1 - Bad Frameworks: First you spend time learning what the framework can do. Then you start doing a project and learn what it can’t do. Then you spend several hours trying to do something that should be trivial, just because the framework prevents you from doing it the trivial way.

Honorable mention goes to:

11 - Missing methods/Overdesigned classes: Give me one good reason why this


cal = new GregorianCalendar(2006, 1, 31);

creates an instance of the calendar set to the 3rd of March 2006.

And as a bonus

12 - Getting the GUI exactly right. Most of the things look and behave just like you’d like. But the few things that don’t, take forever until they do.

[UPDATE]:

13 - Reports: You can spend so much time on creating nice reports. To make things even more fun: The reports are usually some of the most important things to come out of the system, because they will often be sent to the customers. Therefore they have to be perfect. Oh. And usually work on the reports starts after everything is finished. So time is limited.

Posted by Jerome Mueller

Leave a Reply