Do you know where your load-bearing code is?
90% of the time, TDD is enough to assure that code of the everyday variety is reliable enough.
But some code really, really needs to work. I call it “load-bearing code”, and it’s rare to find a software product or system that doesn’t have *any *code that’s critical to its users in some way.
In my 3-day Code Craft training workshop, we go beyond Test-Driven Development to look at a couple of more advanced testing techniques that can help us make sure that code that really, really needs to work in all likelihood does.
It raises the question, how do we know which parts of our code are load-bearing, and therefore might warrant going th…
Do you know where your load-bearing code is?
90% of the time, TDD is enough to assure that code of the everyday variety is reliable enough.
But some code really, really needs to work. I call it “load-bearing code”, and it’s rare to find a software product or system that doesn’t have *any *code that’s critical to its users in some way.
In my 3-day Code Craft training workshop, we go beyond Test-Driven Development to look at a couple of more advanced testing techniques that can help us make sure that code that really, really needs to work in all likelihood does.
It raises the question, how do we know which parts of our code are load-bearing, and therefore might warrant going that extra mile?
An obvious indicator is critical paths. If a feature or a usage scenario is a big deal for users and/or for the business, tracing which code lies on the execution path for it can lead us to code that may require higher assurance.
Some teams work with stakeholders to assess risk for usage scenarios, perhaps captured alongside examples that they use to drive the design (e.g., in .feature files), and then when these tests are run, use instrumentation (e.g., test coverage) to build a “heat map” of their code that graphically illustrates which code is cool – no big deal if this fails – and which code might be white hot – the consequences will be severe if it fails.
(It’s not as hard to build a tool like this as you might think, BTW.)
A less obvious indicator is dependencies. Code that’s widely reused, directly or indirectly, also presents a potentially higher risk. Static analysis tools like NDepend can calculate the “rank” of a method or a class or a package in the system (as in, the Page Rank) to show where code is widely reused.
Monitoring how often code’s executed in production can produce a similar, but dynamic, picture of which code’s used most often.
These are all measures of the potential impact of failure. But what about the *likelihood *of failure? A function may be on a critical path, and reused widely, but if it’s just adding a list of numbers together, it’s not very likely to fail.
Complex logic, on the other hand, presents many more ways of being wrong – the more complex, the greater that risk.
Code that’s load-bearing *and *complex should attract our attention.
And code that’s load-bearing, complex and changing *often *is white hot. That should be balanced by the strength of our testing. The hotter the code, the more exhaustively and the more frequently it might need testing.
Hopefully, with a testing specialist in the team, you will have a good repertoire of software verification techniques to match against the temperature of the code – guided inspection, property-based testing, DBC, decision tables, response matrices, state transition tables, model checking, maybe even proofs of correctness when it *really *needs to work.
But a good start is knowing where your hottest code actually is.
