Optionality

There are lots of reasons to have high internal software quality (ISQ). Minimizing WTFs/min is only one of them. One of the biggest reasons is not what ISQ does for you today, but what it will do for you tomorrow. The optionality it gives you for the future.

So what is optionality, and why should we care?

optionality (countable and uncountable, plural optionalities)

1. (finance, business) The value of additional optional investment opportunities available only after having made an initial investment.
       The short-term payoff for this is modest, but the optionality value is enormous.
2. Quality or state in which choice or discretion is allowed.
       Some offices do not follow the corporate procedure, due to a culture of optionality.

We care about optionality because software is all about change. In this case we care about both senses of the word. Sure, a particular release is a snapshot of a moment in time, and unchanging, but even in the days of shrink-wrapped software that you got off a shelf, there were often updates and patches, to say nothing of next year’s version. Now, with Software as a Service, Web execution, downloadable content, it’s not unusual to have multiple releases on any given day. So software changes, and optionality is important.

Some of you might be saying “But I write embedded code for an unconnected device. My code can’t be updated. I don’t care about change.” It’s true that once released that code can’t change. But right up until release the requirements can change, and they often do. So even in that case, writing software is about change.

Even more fundamentally, every character you add, remove, or change (there’s that word again) is a change to the software. The progression of a product, from idea, to design, to code, to release, is about change. Again, development, of any kind, including software, is about change.

Given that you know you’ll need to make changes, even if you can’t know what some of those changes are, giving yourself the optionality to go in whatever direction you need to go in is important. And that’s the biggest benefit of ISQ. Knowing that you can tackle the unknown unknowns that you know are coming with confidence.

ISQ is things like low coupling. That’s what lets you adjust the internals of one part of your code without having to worry about how it will impact other parts. As long as you don’t break your interface contract, you can do what you need to safely. Your unit tests, which are a part of high ISQ, let you know that you’re maintaining your contract.

ISQ is things like readability. I’ve talked about Coding for the Maintainer many times. Doing that is part of having high ISQ. If it’s easy to tell what’s happening, why choices were made, and more importantly, why other choices weren’t made, you have more options available to you. You can change your mind with more understanding, which leads to better decisions.

ISQ is things designing for test and using well written tests. If you have designed your components to be tested, you have lower coupling (see above) and you can test things without worrying about the testability of a dependency. It’s making sure your tests are tied to the outcomes of the things being tested, not the process of the thing being tested. It’s using fakes, mocks, stubs, and the real thing for dependencies at the right time¹. If you do those things, you can make changes with the confidence.

There are lots of other things that go into ISQ, but just doing those things isn’t the goal. And just having higher ISQ isn’t the goal. The goal is to give yourself more optionality. Higher ISQ is just one way to get that optionality. To have confidence that you’ve changed what you wanted to change, and just as importantly, that you haven’t changed anything you didn’t want to change.