The 3 kinds of code

You can look at any chunk of code as belonging to one of three categories. Confusion between them plus a misunderstanding about the relative cost lead many people into trouble. With a little communication and some discipline, you can save yourself a lot of pain.

The 3 kinds

A few weeks back, I had to help smooth over a conflict between two co-workers. One was a seasoned developer. The other was a businessperson who just wanted some things added to their company’s web site. The conflict arose because they had very different ideas of the costs of software.

For their purposes, there were three plausible paths to take, matching the three kinds of code:

  • Temporary – Code written with a plan to throw away in a day, a week, or maybe a month. If it breaks, that’s ok — we were going to get rid of it anyhow.
  • Sustainable – Code that’s built to last. Well factored, well understood by the team, with strong automated tests, and generally meeting the team’s standards for something they’d happily maintain forever.
  • Half-assed – Everything in the middle. Code written by amateurs. Quick fixes that become permanent. Rush jobs. Things written when people say “we’ll clean it up later” and don’t.

When the businessperson expressed their desires, they wanted something cheap and quick. However, they didn’t want it to be fragile or throwaway; it had to be reliable and last indefinitely. They proposed bolting on an off-the-shelf solution that fell in the “half-assed” category. When the developer reacted poorly, they couldn’t understand why.

Follow the money

The misunderstanding comes because they had different perceptions of the costs:

businessperson
view
developer
view
Temporary low low
Sustainable high medium
Half-assed medium high

Given their perceptions, it’s natural that the businessperson would prefer the half-assed option. It’s more valuable to them than the temporary option. But doing things sustainably doesn’t get them any apparent increase in value, and they think it costs them more. Just as naturally, the developer resists what they see as the high-cost option.

In truth, they’re both right. They’re just looking at different sorts of costs. We can rewrite the column headers this way:

short-term
costs
long-term
costs
Temporary low low
Sustainable high medium
Half-assed medium high

The experienced developer is more aware of the long-term costs not only because they have more experience, but because long-term costs are generally thought of as their problem. As the maintenance costs of half-assed code add up, they won’t be attributed to last year’s excess schedule pressure from business stakeholders. Instead, the developers will be perceived as increasingly unproductive or unreliable.

Of course, that’s not just bad for the developers. It’s bad for the company as a whole. If a company’s costs for software continuously increase, that eventually becomes a powerful advantage for competitors who are more thoughtful and disciplined about their approach to software development.

Don’t fall in the trap

This is why many parts of the Agile world either explicitly or implicitly rule out the option of writing half-assed code.

Extreme Programming, for example, started out with a number of sustainability-focused practices, including pair programming, test-driven development, and merciless refactoring. As the book Planning Extreme Programming says, “With most of our planning, we assume that quality [is] fixed.” This continues up to the present day with efforts like Bob Martin’s Manifesto for Software Craftsmanship.

No matter what process you use, you can avoid the trap of half-assed code:

  1. Make sure everybody agrees that they are in it for the long haul.
  2. Educate stakeholders on how expensive supposedly cheap solutions are in the long term.
  3. Whenever people agree on a temporary solution, make sure that it is really temporary. In particular:
    • Agree in advance on the end date and expected issues. Write that down.
    • Budget for the costs of removing the temporary solution.
    • If a permanent solution is to follow the temporary solution, budget for that, too.
    • When the end date approaches, people will try to fudge it. Politely refuse, reminding everyone of the earlier agreement.

In addition, be constantly vigilant about half-assed code returning in disguise. For example, a lot of people get sold on outsourcing or offshoring because it looks cheap and easy. Sometimes it might be, but most of the projects like that I’ve seen are really half-assed code that got sold as sustainable. Just as dangerous is the cowboy coder who rides in to save the day, but leaves a lot of half-assed code behind for other people to deal with.

4 Comments

  1. Alex Chaffee:

    Well put.

    Also:

    sustainable code = tests + half-assed code + refactoring

  2. Chris Sterling:

    Great article. We usually write an equation such as:

    high business expectations + low engineering push-back = high technical debt which leads to low engineering performance

    thus leading to the higher costs expressed by developers for half-assed code. Thank you for the great content.

  3. Danfo:

    What a great article! I am sick of looking at poorly coded sites, especially when it’s a web design firm’s own site. Yet I can’t find a job and I code efficiently for web standards? WTF?!?!

  4. Agile Focus » Blog Archive » Responsible technical debt: not an oxymoron:

    [...] quicker, they will often interrupt to say, “Yes! Do that!” As I explain in “The 3 Kinds of Code“, a lot of business/engineering fights arise because engineers are more aware of the [...]

Clicky Web Analytics