A moment in the project plan; a lifetime in the codebase

Photo credit: Michele Blackwell via Unsplash

Software can be a source of regret as well as value. It is a common experience to find yourself looking at code and wondering what fool could possibly have written it, only to read the comments and find out that it was you.

The passage from choice to regret is often clear to developers, despite their faulty memories. You knew what you were doing when you made those decisions – and that you (or someone else) would pay for them in the future.

However, this path is not so clear to other stakeholders and non-technical decision makers – and their choices are often the ones that create the most regret.

Imagine a system which treats different types of end users in different ways. Perhaps it sets prices for loans based on credit risk. Perhaps it offers discounts based on past relationships. Perhaps it awards subsidies based on eligibility.

There are multiple ways to design such a system. Most developers know that the least flexible, most fragile, all-round worst way would be to hard-code values :

if customer_spend > 1000

discount = 0.05

Anybody can see that, as soon as the discount threshold or the discount level changes, the code will have to change. It would be far better to code these as parameters or database values which can be changed independently of the code.

Except . . .

Implementing such a solution properly would require a new database table, and a new interface to maintain the values in the table, and a whole load of new tests. And the project is already running late and over budget. The new launch date is set and everybody is terrified of missing it again.

So the decision drifts up to the project manager or the sponsor, who make what they believe to be an easy choice: is the project going to go live on time or not? They deny requests for more time, or for another feature on the backlog, and the developer holds their nose and hard codes the values. It takes ten minutes rather than one day, and the project stays on track.

This is a bad decision, but the project manager and the sponsor do not necessarily know why it is a bad decision. Even if they are not doing it consciously, they are optimising for short term delivery efficiency. Everything in their environment tells them that this is the right thing to do: the numbers in their spreadsheets, the RAG statuses in their reports, the raised voices in their board meetings, the objectives in their performance reviews.

What they do not realise is that, as well as making short term choices about their project, they are also making long term decisions about the agility of their business – decisions that they may not even have the authority to make.

When they need to make a rapid change to the discount regime – or the loan rules, or the subsidy scheme – they will be stuck behind a queue of other changes. There is a chance that someone will get the opportunity to refactor the code to make the parameters more flexible and user controlled – but at least as much of a chance that it will become an obscure and mysterious part of the legacy codebase, which everyone is scared to change in case it breaks something.

Of course, hard-coding is just an example of a bad choice: there are many, many other ways to go wrong in the practice of software development. And many have the characteristics that, at the point of decision, it’s not obvious what decision is actually being taken, whether we are choosing short term expediency or long term folly (or both).

The remedy to this problem is, as ever, for technical people to explain what they are up to, and for non-technical people to learn the nature of the work they are overseeing. Absent explanation, absent learning, it is impossible for a non-technical person to determine the difference in behaviour between a system which is hard-coded and a system which is flexible: as far as they are concerned, they both meet the needs of today, so why not pick the one which seems easiest?

We often talk of multi-functional teams. The deepest form of multi-functional organisation is one in which everybody can understand the work and appreciate the choices of everybody else. Choosing not to spend the time to learn and explain is as bad a decision as choosing not to make software flexible.