Time constraints and a need to deliver functionality quickly are one of the most common justifications I encounter for choosing expedience over proper design and practice in implementing software. I find this to be short term thinking at it’s worst, resulting in delivered systems that will ultimately cost far more and have significantly decreased utility over time.

Software that works right now has no business value. This statement seems to be false, even absurd. Of course it has value. It can be used to write documents, process orders, contact customers and do all kinds of business functions. Yet I argue that this is of no value unless it can keep doing these things, particularly in the face of changing business requirements. It is here that the expedient view fails. Expediently developed software does not support maintainability, and it is maintainability that ensures business software has value over time. A word processor that works today but tomorrow won’t let me access my document is worse than useless, it is actively robbing me of the work I’ve done.

This may be expressed in terms of my favourite software development metaphor: Technical Debt. Expediently developed systems are the sub-prime loans of the software development world. These projects carry large amounts of technical debt from conception and it is rarely if ever paid down. In the good times these systems can get by, although the cost of servicing the debt means that maintenance is significantly more costly than it should be. This ultimately results in less value to the customer but is survivable (although damaging to client relations and your reputation).

The real issues come when times aren’t as smooth. In the financial world unrealistic debt levels and financial stresses have caused enormous numbers of loans to go into default. The software equivalents are events such as changing business environments and technology platforms. Applications must adapt to these changes in circumstances in order to maintain business value. If the application is already carrying significant debt then the cost to make these changes may destroy any value the application gives to the business. In extreme cases a failure to adapt to changed conditions may even kill the business. Even in more moderate circumstances it will still result in the client bearing significantly higher costs than they should reasonably expect.

I’ve (fortunately rarely) encountered the view that this is irrelevant because you can bill the client more for bugfixes and changes, therefore ensuring work into the future. This really angers me; for two reasons. Firstly, and by far the most important, this is highly unethical. It’s the kind of thing that makes me wish professional bodies in software development were as prominent as they are with other fields (such as engineering). Secondly it’s highly stupid. Clients will either go out of business or wise up and fire you if using your services incurs excessive costs or prevents them from adapting their business as they require.

I’ve also seen what I call develop and run, where a system that kind of meets the requirements is thrown together and passed to an unsuspecting client who is left holding an unmaintainable mess while the responsible parties run away. This is also unethical and stupid. It takes advantage of clients who don’t know and shouldn’t be expected to know any better. There’s also only so many times you can do it before you run out of potential clients who aren’t aware of your practices. Again I’ve only seen this rarely but it does happen.

This is not a manifesto for Big Up Front Design (BUFD) or for always doing things in the most technically pure sense regardless of other concerns. I don’t think BUFD can possibly account properly for every contingency that will be found during development, and a pure system delivered too late may be of less value than a dirty system delivered in a more reasonable timeframe. Rather it is a call to recognise that technical debt exists and must be managed, and that a system that is too debt laden may exhibit negative value quickly. This means that expediency cannot and should not be the default position, and should be fought back wherever possible.