I’m nearly four years on from starting with my current employer. This is quite an interesting phase of my employment, in that sites that I worked on when I first started are all reaching the stage where they’re being refreshed, upgraded or completely rewritten. What this seems to be doing is highlighting to me that there really is such a thing as Technical Debt and it really can be as evil as people say it can.
As developers, we are often rewarded with praise (or more) for turning new features around quickly. If your company estimates that a particular feature will take eight hours to write, and you take only four, the company’s making a tidy profit, you can move to the next item in your schedule more quickly and everyone is happy. This is all very well, so long as that feature has been written properly and in accordance with your company’s general approach; everything ranging from naming conventions right through to the organisation of the filesystem. If it hasn’t been written properly, then you have incurred technical debt, and at a point in the future either you or another developer maintaining your code may need to spend more time writing a feature or changing your feature than anticipated.
This can cause all manner of problems. When you come to develop on from your last feature, you might estimate that another bit of functionality will take 8 hours to write. However, when trying to hook in to the existing feature, you discover your technical debt, and end up having to refactor the existing code to allow you to do what you wish. This might take another 4 hours. This might not seem to be a disaster; after all, you were 4 hours up on the first feature, and we’re just back where we should be now, right? Wrong! It is important to remember that managing our time isn’t just about managing the absolute amount of time taken, but keeping to schedules. The 4 hours it takes to sort out the mess in this second round of development delays the next item in your project schedule, which might result in a disappointed client.
In my opinion it would have been better to take the full scheduled 8 hours in the first round of development and avoid the unexpected hold-up during the second round of development. The 4 hours in the first instance are less expensive than the 4 hours in the second, as they’ve less of an effect on surrounding projects & priorities.
The trouble is, at the time the new feature is written, it can be difficult for someone non-technical to tell the difference between it having been done quickly and it having been done properly. In fact, from an end-user’s point of view, the system can look absolutely identical. So, given two developers, one who can turn the feature around in 4 hours, and another who takes twice as long at 8 hours, which will the project manager or client be more happy with? My money would nearly always be on the 4 hour guy. But long term, the 8 hour guy is actually going to be less expensive to run, or will at least facilitate more accurate estimates and quotes on the same system in the future. The problem is, as developers, we need to resist the temptation to be the 4 hour guy. The short term praise can be addictive and it’s understandable why it seems easier and more tempting to do things as quickly as possible and worry about the consequences later.
What I’m noticing is, in 2008 I WAS the 4 hour guy. I was turning around features faster than other people had in the past, and grew a reputation for being quicker. While I was quicker at the time, now, 4 years on, when I’m revisiting those sites and starting to improve or extend them, I’m paying off my technical debt with ‘expensive’ rewriting and refactoring. So now I’m in the position where I am expecting the implementation of a change request to take a given amount of time, but on loading up the project and seeing the way it was written in the first place, the implementation is taking much longer. This extra development time is difficult to explain and to justify to those responsible for project scheduling, and is something that I’m going to really strive to avoid in the future, even if it does seem to take me slightly longer to develop new features than before.
It seems sensible to finish this post with one of the more famous quotes about computer programming. I’m sure you’ll have read it before…
Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live
Trust me, it’s bad enough even if it’s YOU that ends up maintaining your code!
