Your new website is proving very successful.

Great.

User numbers are up and sales are growing.

Absolutely great.

This naturally drives ongoing investment in the site to add new features and more functionality to make it even better. Typically, a program of continuous development with a roadmap of these additions is devised, prioritised by user demand or business need. Often, some of these demands are seen as urgent. Somewhat naturally, if users are clamoring for some new functionality, then everyone wants to build and launch it as quickly as feasibly possible. That’s not to say the urgency should bypass the delivery process of course. The work needs to be scoped, then the code written, tested and released.

However, we’re now flying the plane and working on the engine at the same time because, obviously, no one wants to stop whilst we’re on this fantastic upwards trajectory. And continuous development is exciting because we’re enhancing the product to make it better for users which, in turn, gives more for marketing to promote plus the business can now see results showing in the bottom line.

This success and increased demand go hand in hand, which is where, if you’re not careful, you can store up what’s referred to as ‘technical debt’. This is added to by the constant onslaught of new technologies and framework upgrades on top of continuous development. Code that was written just a few months ago could be improved with a framework or library upgrade that can reduce resource demands on things like CPU or memory, or just to improve the maintainability of the source code.

The concept of ‘technical debt’ was originally coined by Ward Cunningham, an American programmer who developed the first wiki, but it’s essentially the same principle as any other form of debt. For example, you take a loan from a bank so you can buy something straight away rather than saving up and then buying it. Obviously you pay extra for this as you have to pay back the loan and some interest on top. As long as you pay back the loan and the interest everything should be OK, but if you don’t pay the interest or if you miss some repayments you’re going to end up in trouble. Ultimately, you can rack up so much interest it exceeds your total income, making full repayment impossible.

The same thing applies with code. You can temporarily speed up development by just adding new code and testing new features, but this will gradually slow your progress as the code becomes unwieldy and then, eventually, more or less unmanageable. Eventually you’ll have to pay off the technical debt by re-factoring some of the code, which transforms a mess into clean code. The longer you carry on with continuous development without re-factoring the bigger the task is going to become. So allocating time for re-factoring is necessary and it should increase during the life cycle of the site.

Is re-factoring always needed? Well, there’s a perfectly justifiable argument with a site that doesn’t see much ongoing dev, that it isn’t. As long as the standard maintenance work is done, such as security patches (which is not the same as continuous development) it may be that the site reaches its natural end of life before any technical debt catches up with it, but then a budget for a new one will have been allocated anyway. However, a large and complex site which is continuously developed will need an increasing re-factoring budget to ensure the code is optimised.

Some clients take issue with budgeting for re-factoring - ‘if the code’s been well written surely there’s no need?’ Of course everyone does their best to write excellent ‘clean’ code from scratch. Programmers don’t intentionally write ‘unclean’ code to the detriment of the project. But over time - and especially with continuous development - that clean code can become ‘unclean’. OK, 'so, what is ‘unclean’ code?’ I can hear you ask. Things like inconsistent naming, bloated classes and methods all make code sloppy and difficult for another programmer to grasp. Clean code is easier for other programmers to work on and it doesn’t contain duplication because each time a change is made in a duplicate code, the programmer has to remember to make the same change to every instance. This increases the cognitive load, slows down progress and increases the risks of bugs that can be fixed in one place only to break something else. The problem just escalates with scale and more ongoing programming.

Re-factoring code to make it clean again has clear benefits:

  • Clean code is obvious for other programmers.
  • Clean code doesn’t contain duplication.
  • Clean code contains a minimal number of classes and other moving parts.
  • Clean code passes all tests.

And, most importantly, clean code is easier and cheaper to maintain because an ongoing investment in re-factoring fights technical debt. It maintains site performance, extends its life and therefore ultimately pays off.