Dahlia Bock

Don't leave it to the last minute

My biggest pet peeve is procrastination. If there's something that is important and needs to be done, then there's no sense in leaving it till the last minute when you have to do it anyway and who can tell what problems might arise if you do it last. This post might seem like a rant, or might point out issues that are plain obvious to many, but some people just don't get it.

There are many things that we should not leave till the last possible minute in software development. Error handling, integration and testing are the few that I can pull off the top of my head right now.

The project that I am currently on has been building a shared-services tool that sits in between a 'repository' (upstream) that feeds data through to the systems that use, massage and display that data (downstream). We do a little bit of validation, filtering and massaging of that data and hand it downstream. One of the biggest challenges of the project is to consolidate all the requirements of the downstream systems (we have quite a few customers) so we can have one solution that caters to most of their needs. Some of them want us to do a lot of the work for them, others only want us to do the minimal and give them almost raw data. As a result, we've had to do very careful and detailed error handling and logging not only to cover the bad situations that could happen in our code but also in the code downstream.

Given that we have such complicated requirements, you would think that any error handling that needs to be done in a particular functionality be done as part of the card instead of having one big card at the end that covers all cases. I can't remember the reasoning behind this decision anymore, but it was a very short-sighted one. Now we experiencing the excruciating pain of having to go back through the many different situations in our code to figure out what to log when a particular event/problem happens... 2 days before a release. Fun!

-- Edited Fri Dec 19 9.03am --

The concern for slapping in error handling and logging into the initial design and implementation of a functionality is increased scope on an already complicated card. Seems like a valid concern, but I'm sure there's a better way to tackle the problem. Thoughts? Ideas? Another thing we brought up at yesterday's retro was that the team has never seen such complicated and detailed logging requirements, what used to be a second class citizen is now a VIP. Maybe we should be treating a VIP differently.