The Dikstra quote I tweeted about "not introducing bugs" elicited a few responses, some predictable and some not, that highlight a severe problem that pervades in our industry. // 1
Predictable: "Programs were a lot smaller back then." So what? Many things are a lot simpler *today* than they were then (e.g. we don't have to build our own sort routines). // 2
We can effectively compile + link + execute code near-instantaneously now, which allows us to write fast-feedback tests to verify the tiniest of changes to logic. // 3
Logic-related defects approach zero with such controls. Code quality can be safely sustained. // 4
With fast-feedback controls, overall costs decrease, because the true cost of defects + the cost of understanding/changing difficult code is far higher than many think. // 5
Unpredictable: "We're so busy with other concerns, we don't have time to get the logic right." (paraphrased) Wow. If we don't think we have time to get the logic right, we should stop trying to build software. // 6
Somewhat predictable: "It's ok if we have defects, our software doesn't matter that much in the scheme of things, anyway." (paraphrased) // 7
Somewhat predictable: "Shit happens." // 8
Yes, we can't write automated tests for everything. Unpredictable things will sometimes happen. Gee, let's use that as an excuse to not concern ourselves with defects much at all, particularly if our system isn't all that important. // 9
Meanwhile, I'm sitting here with a $3000 laptop that is costing me dear time and money because of a degraded quality OS that demands a reboot at least a couple times daily. // 10
I guess MacOS is not "mission critical" to Apple anymore, so it's ok that basic operations (ability to do a pointer click) are defective. I can always reboot, right? // 11
I really don't care one bit if people adopt TDD or not. Practices don't matter, outcomes do. // 12
If you have a better way to achieve high quality, low defect, easily understood, and easily maintained code, by all means use it. And maybe show me some of that "how to." // 13
If you just slap code out & ship it--maybe because your company doesn't care about quality--stop. Find a better place to work. Or find better ways to work. // 14
Quality isn't just for your customers. We often annoy and waste time of our very own selves with the embarassing code we integrate into the codebase. // 15
Software development demands accuracy. It demands some care & concern for our teammates, our companies, our users. // 16
If we can't offer that, maybe it's time to rethink our choices or even move on. // 17
