When we write software, sometimes our hands are so full making sure the code does what the customer wants that we can’t spend enough time thinking about how the code does it. We can then incur technical debt and end up negotiating re-writes and large-scale refactoring to our customer’s frustration, not to mention risk to our relationship.
Let’s Discuss ilities, aka Non-Functional Requirements
This post is a reflection on how I approach software development, specifically how I rank-order quality characteristics like scalability, testability, flexibility, maintainability, and operability. These quality characteristics are non-functional requirements casually referred to as ilities of a system. The software development community has identified more than fifty ilities but after 20+ years of experience as a software engineer, I’m going to argue that focusing on maintainability and testability will help you to reliably produce quality software that delights your customer and wins their trust.
So, are the other ilities important? Yes!
It’s difficult to objectively defend one rank ordering of software ilities or quality attributes, especially when the purpose of software systems varies so widely. Consider how a game might have different quality characteristics compared to an audio mixing app, and then compare those two with a large scale internet service like Twitter. They all might, and probably do, prioritize differently.
“If the customer can’t figure out how to use the system they’ll hate it!”
“No one will want to use a slow system.”
“A highly exploitable system will never pass security review.”
… insert additional reasonable defenses of other ilities here …
While all of the above are true, in my experience, in general, none of them matter very much early on in a software project. However, what does matter is:
- Keeping things simple
- Making sure the code reflects your intentions
- A solid automated test suite
Why Maintainability + Testability are My Top 2 ilities
“If the customer can’t figure out how to use the system they’ll hate it!” True, but if your code is well-factored, easy to change, and your tests are comprehensive you should find you can alter the user interface and API layer with relative ease.
“No one will want to use a slow system.” No argument here! But if your code is well-factored, easy to change, and your tests are comprehensive you should find you can tune or even re-write slow components with relative ease.
“A highly exploitable system will never pass security review.” Absolutely. But if your code is well-factored, easy to change, and your tests are comprehensive…
So, I probably don’t need to continue repeating myself on why maintainability and testability resonate so strongly for me. And I’m not trying to be snarky or cute with simple arguments in favor of them. The simple truth is maintainability and testability will be good to you if you focus on them. For example: write your tests first, write just enough (simple!) code to make them pass, tune for performance, build in flex-points, rinse, and repeat.
Additional ilities Resource
Below you can check out a recent tech talk where I, along with my BTI360 teammates, discussed how ilities are guiding principles that advise and influence our coding decisions, as well as how ilities encourage a culture of quality in our software craft. Plus, we consider as a team, which ilities should rank the highest and why. See if you agree…