Nice post! Applicable to giant multi-decade monolithic projects too, like mine.
I like that you gave a shout-out to Jay Bazuzi, we worked at the same company (but on different projects), he's awesome.
"You cannot leave anything pending."
Taking that point a small step forward: keeping the bug count low. (Yes, it can be surmised from the quality section, but I think it deserves special emphasis.)
If your bug count is very much above zero, you don't know when you'll be able to ship.
1 month to go to the scheduled ship date, and 200 outstanding bugs? Will the team make it? Don't know.
Bugs hide bugs.
Once those 200 bugs are fixed, you may now be able to discover the 500 bugs that were obscured by those 200 bugs.
Untested code is buggy code.
That includes any untested code paths that are supposed to handle the "rarely happen" and "never happen" scenarios.
It's great when the code follows the well-trodden happy path, but when something goes awry (oh no, we lost network connectivity) and all of a sudden the code path is one that was not tested as things evolved, it could very well be a rough ride.
Joe Rainsberger would promote (TDD-style) unit tests here, as a way to ensure basic correctness of all possible code paths.
If you have a programming language that supports TDD-style programming (like C#, NUnit, using Visual Studio with NCrunch), you'll find that it is fabulous.
If you have a programming language that does not well support TDD-style programming (like C++, using Google Test or Boost.Test or Catch2), you may find the experience to be uncomfortable to painful... but still, arguably, worth it.
If you have a programming language that support contracts natively (Eiffel, D, C++20, Spec#, Sing#, Ada 2012, and I've heard that Clojure, Kotlin, Oxygene (REMObject's version of Object-Pascal), Scala, and a few others do too), the design by contract can be leveraged to eliminate the need for a majority of precondition, invariance, and postcondition unit tests.
Some languages, like D, even have unit testing as part of the core language.
Nice post! Applicable to giant multi-decade monolithic projects too, like mine.
I like that you gave a shout-out to Jay Bazuzi, we worked at the same company (but on different projects), he's awesome.
"You cannot leave anything pending."
Taking that point a small step forward: keeping the bug count low. (Yes, it can be surmised from the quality section, but I think it deserves special emphasis.)
If your bug count is very much above zero, you don't know when you'll be able to ship.
1 month to go to the scheduled ship date, and 200 outstanding bugs? Will the team make it? Don't know.
Bugs hide bugs.
Once those 200 bugs are fixed, you may now be able to discover the 500 bugs that were obscured by those 200 bugs.
Untested code is buggy code.
That includes any untested code paths that are supposed to handle the "rarely happen" and "never happen" scenarios.
It's great when the code follows the well-trodden happy path, but when something goes awry (oh no, we lost network connectivity) and all of a sudden the code path is one that was not tested as things evolved, it could very well be a rough ride.
Joe Rainsberger would promote (TDD-style) unit tests here, as a way to ensure basic correctness of all possible code paths.
If you have a programming language that supports TDD-style programming (like C#, NUnit, using Visual Studio with NCrunch), you'll find that it is fabulous.
If you have a programming language that does not well support TDD-style programming (like C++, using Google Test or Boost.Test or Catch2), you may find the experience to be uncomfortable to painful... but still, arguably, worth it.
If you have a programming language that support contracts natively (Eiffel, D, C++20, Spec#, Sing#, Ada 2012, and I've heard that Clojure, Kotlin, Oxygene (REMObject's version of Object-Pascal), Scala, and a few others do too), the design by contract can be leveraged to eliminate the need for a majority of precondition, invariance, and postcondition unit tests.
Some languages, like D, even have unit testing as part of the core language.
Fantastic feedback, I'm glad to see this article resonate!