Someday I may write a much longer piece about this, but for now, here’s what I’ve been noodling on for well over a year:
My sorely-missed friend Alex Johnson used to say that calling Software Development by the title Engineering was a great disservice to our industry because it casts what we do as a science with clearly defined measurable parts throughout. The problem with that, as every developer knows, is that there’s still quite a lot of art and magic involved in software development.
Engineers build bridges and solid structures, and applying that metaphor to the entirety of software development is problematic, because developers are never building brick and mortar on solid foundations. They’re normally building structures of code on top of other people’s pre-existing structures of code within operating systems, software platforms, and programming languages that other people have built. And all of those systems, no matter how clean the code, or how well documented, will inevitably have some sorts of bugs. Bug free code is a misnomer and an impossibility, because as any good quality assurance analyst will tell you, you can have bug free use cases, but there are always edge case scenarios where you can produce bugs. The balance is determining what bugs matter and are a real risk and where things need to be iron clad.
How much technical debt is acceptable and low risk enough in order to ship your code? What’s the timeline on that technical debt becoming higher risk? What’s the natural entropy built into your software? When do advances in technology render your code problematic?
I have to get on a plane, so this is rough, but it’s been sitting in my drafts for months, and it’s time for me to start blogging again…