The Two Values of Software

Sure enough: If your team’s software fails to provide value now (or in the near future), something’s gone badly wrong. You don’t like your software project to end up similar to this, right?

Smoking remainders of a ‘Biikebrennen’ — don’t let your project end like this.

As Alistair Cockburn explained in “Agile Software Development” software development can be seen as a game played in rounds — and most teams prefer to stay in the game for many rounds.

To me it’s interesting (and a bit worrying) that most of the testing techniques and approaches are focussed on whether the current version of our software…

1. is in fact the right software and
2. if it works correctly.

In other words, testing focusses on validation and verification, it concentrates on a relatively short period of time: the next release.

Now, Uncle Bob Martin presented the idea of the primary and secondary value of software in episode 9 (‘The Single Responsibility Principle’) of his CleanCoders video series. He presents the secondary value first (which most people believe to be more important): ‘The secondary value of software is its behavior.’ He also explains the primary, more important value as: ‘The ability of software to tolerate and facilitate such ongoing change is the primary value of software. The primary value of software is that it’s soft.’

In Alistair Cockburn’s description the order is reversed (see Agile Software Development, 2^nd edition p. 37 ff), but in my opinion the order isn’t always that important: I am worried that testing doesn’t consider one of the two values of software.

To my experience, essentially all projects focus on current or near-future behaviour of software, but rarely actively work to keep the software ready to deal with future requirements. I understand that YAGNI (You ain’t gonna need it) may play a role here. But mind you: YAGNI mostly applies to actually implemented features that are not needed. It may also be valid in order to prevent going overboard with too much abstraction and flexibility. In the end, you always need to find a balance between following and ignoring the SOLID principles (a good part of the Clean Coders videos covers this in detail).

Concerning the 1^st value of software (according to Uncle Bob Martin), I’m convinced that testing needs to answer questions like this:

• Is “the ability of software to tolerate and facilitate such ongoing change” a job purely for programmers?
• Can software testers contribute to the primary value? Should they?
  • If yes, is this part of the job or should we keep out of this business?
  • How can we as testers contribute?
• Can other disciplines help?

What do you think? Is this topic important for testing? Should we treat it in the way Michael Bolton advises testers with respect to “Quality Assurance Business” (spoiler alert/hint: He advises us to stay out of it)?

I personally think testers should get involved: A tester is somebody who knows that things can be different, as Jerry Weinberg says.

Also, I definitely want my clients, as well as their clients, to be happy with the software I help to develop, not only today, but also in the future, even when most original developers of a software system have left the team or company.

When your project (or product life cycle) comes to an end it should stay in your memory not like the smoking remainders of a fire, but with the bright colours of a great sunset.

Bright Sunset