The biggest cause of technical debt in IT departments

I am writing this post to correct a mistake I made. I had this twitter conversation with Jeremy Kahn:

are deadlines the biggest cause of dirty code?

Discussion with Jeremy Kahn on comments and documentation

When faced with these deadlines, developers often take whatever shortcuts they can find to meet the deadline, and the code suffers as a result. Although it is certainly true that this is a major cause of sins to code, I later realised that there is another cause that is even bigger than this: one man development projects.

This is something that I have seen over and over again in just about any and every IT department, and always with a similar set of circumstances. An IT manager is asked to deliver a new project. It is not the company’s highest priority project, and not part of the company’s main application, but it is an important part of the company’s overall business strategy and something too important to avoid doing, although the other projects being worked on mean that there is a lack of development resource for this new project.

The IT manager knows a generally good developer in the department who is able to get things done quickly. The manager recruits this developer to work on this special project on his own. The developer will usually be offered paid overtime in order to get more features implemented. The IT manager may be able to secure a small amount of time from a Quality Assurance tester, but at least the majority of testing is done by the developer and no code reviews are done.

A few months later the developer has met all of the basic requirements and delivered a phase 1 release of this new application. Phase 2 is initially planned for sorting out various problems that the developer didn’t have enough time to do in phase 1, but otherwise the project is considered a big success. Phase 2 is later dropped from the business plans and the application is mostly neglected for a few years.

Then something happens in the business requiring immediate changes to this application. Most of the time the original developer will have left the company by now. It may have even been the original project that prompted the developer to find another job. Even if the original developer is still there, changes in the company over the last few years will mean some other developers need to take over responsibility for the application.

The new developers find no unit tests, almost no documentation, several classes that thousands of lines long, many methods that are hundreds of lines long, long loops, long parameter lists, singletons here there and everywhere (static cling), primitive obsession, every method with side effects etc. After a bit more time looking through the code, their appear to be a number of bugs in there, but there isn’t anyone who remembers the original requirements well or any documentation in the area to clarify whether they are bugs or intended behavior. The original developer had little idea of how bad his code was because he understood it well enough at the time and it was his application so no need for anyone else to learn it anyway.

At least that was how it was at the time. Often the one man developer team is combined with the number 2 cause which is very tight deadlines. If this is the case then the developers eventually inheriting the application will find a truly horrible mess. Almost any change to the system results in a regression, but these are hard to spot because of a total lack of automated testing as well as no documentation on what the correct functionality is.

It always seems to be the case that the original developer was fairly senior and in general a smart guy. If you compare his code in this application to the code he writes in a developer team, the difference is day and night. Pair programming, or regular code reviews, make a huge difference to the quality of code. Even without these, just working in a team means all developers have to write code that others can understand.

So I have been wondering what makes us accept smelly code when its written by ourselves on our own, when we wouldn’t accept it in a team? The answer is we sometimes rationalise our mistakes to ourselves, but these do not stand up to scrutiny when working in a team.

Additional Reading

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s