Why is your software dying so soon?

Let’s have a look at the 3 main components of being a programmer and see what the effects are on a project.

1. Write code that a computer understands
2. Understand the business domain
3. Write code that a human understands

Write code that a computer can understand

This one sounds very straightforward, and in some way it is. If it works, it doesn’t crash and runs fine. When it doesn’t your code won’t compile, it won’t start, or it will crash at runtime. Luckily most of us developers have had years of training in this field during formal education or work experience. A modern computer also doesn’t care too much about how you structure your code. If it works, it works.

Strongly typed languages have a small advantage: Type checking is no longer a reason to crash (if you haven’t circumvented it).

The effects of getting this wrong are noticed VERY short term: compile time or fairly quickly at runtime when the feature is first used. Remediation is almost instant.

Understand the business domain

Writing something that doesn’t fail outright is a good skill to have but a bit pointless if it does not solve a problem. A large part of the developer’s job is to understand the business sufficiently to translate it into something a computer can understand. This is already a good deal harder than just making code that doesn’t crash. Business cases are rarely trivial and require a good deal of effort to internalise sufficiently.

Getting to know the business domain is usually part of the getting onboarded to the company or team. The translation part is often part of your formal education as well.

It’s hard to quantify how easily noticed the effects of getting this wrong are. It can be noticed by your client upon first use, or it can be a vague sensation that something’s not right, but they can’t quite put their finger on it. The effects of getting it wrong are still noticeable in relatively short term though. Days or weeks in most cases, or perhaps months for edge cases. Remediation takes a few hours to weeks.

Write code a human can understand

A perfectly working piece of software, nicely in sync with the business is great! Good job! But what if your colleagues have no clue how this magic works. They know the business case but have a hard time pinpointing exactly where and how things happen. This is the point where your codebase will die. Updates to this code will only make it a bigger mess, leading to symptomatic programing instead of figuring out which higher level changes need to be made. It’s a complex subject that deserves its own article.

The effects of doing this wrong mostly manifest themselves in the long term, usually measured in years. In about 3-5 years, or specifically when a key developer leaves, this codebase will be regarded as “impossible to work with”, “hard to update”, “buggy” and your project is soon scheduled for a complete ground-up rewrite. On the other side of the spectrum, if you do it right, this codebase will still be easy to update, run and debug and provides ongoing value instead of frustration. Remediation takes weeks to months.

What makes code easy to understand by humans?

Because we’re talking about how people interact with code, psychology is always around the corner. I’ll try and keep it practical and related to programming approaches.

• require a low cognitive load.
• be an accurate translation of the business domain / process
• require a minimal amount of changes when implementing a feature or fixing a bug.
• allows your compiler to do most of the semantic error checking instead of your brain