I was developing a wee web-based application the other day, playing around with parsing HTML and developing my love hate relationship with regular expressions. The same relationship I have with CSS.
Don’t get me wrong I love them! They are both extremely powerful and the deeper I delve the more respect I gain. However my lack of experience leads to frustration as debugging them is a nightmare.
Stop me if you’ve heard this one. You get it working…you tinker a little…it breaks! You cannot step into it or have some compiler tell you where it went wrong it’s just broken till you work methodically back through all the changes you made just to reach square one again!
What is DLI?
This got me thinking. What I was feeling was very similar to how I feel about some parts of software I have maintained over the years. I am sure everyone at some point has had some code where debugging an issue was a laborious and tedious task.
Indulge me as I attempt to define this through the following formula 🙂
IF TIME TO REPRODUCE >= DEVELOPER’S ATTENTION SPAN THEN
DEVELOPER LOSES INTEREST
If the time it takes to reproduce the issue and therefore debug the exact point where it goes wrong is longer than the attention span of the developer, the developer loses interest.
The Cost of DLI
When a developer loses interest they are much more likely to take their eye off the ball. Best case scenario would be a sloppy check-in which breaks the build! Worst case is a very bug-centric fix which in fact creates more bugs, which may or may not be found until a much later date (hopefully before it’s released) when the developer has left and it takes someone else ten times the effort to resolve.
Now it is easy to determine the cost of fixing an issue. We can simply use the time spent fixing it along with the developer’s rate. I am not going to go into the cost of bug fixing here, but if you are interested check out Economics for Developers: Understanding Opportunity Cost by Joseph Finsterwald.
I would say however the cost of DLI is far greater than the time taken to resolve the issue. I would also say it is even greater than the cost of not fixing the bug at all. The cost of DLI lies in the time spent fixing waves of bugs specific to one functional area. Bugs which pop up in a variety of disguises but all smell the same. Bugs which could have been prevented. In fact the true cost of DLI may not surface in a project until it is too late and your developer has moved on!
Keeping the cost down
Here are my top 3 tips to ensuring your project does not suffer from DLI:
- Test Driven Development – Unit tests can significantly reduce the time taken to reproduce issues. Less TIME TO REPRODUCE is less likely to lead to DLI!
- Keep those creative juices flowing – Don’t let your developer’s stagnate. Have them work on new areas of functionality. Increase the DEVELOPER’S ATTENTION SPAN as well as spread knowledge throughout the team.
- Pair Programming – Having developers verify each other’s work ensures they care more about the code they produce. Less likely to let DLI get in the way of a good job.
Of course you could just bin my CV when it comes your way 🙂
NOTE: I am a developer so I am not having a dig. I have a short attention span and this article is purely based on my personal experience. For all I know DLI may be solvable with a quick trip to the psychiatrist 🙂