| This series is about the origin of bugs. Although they did not come from an apocalypse, they are sure leading us towards it. | ||
|---|---|---|
| Part I | Part II | Part III |
| Part IV | Part V | |
“What do you mean?
When a mommy-bug and a daddy-bug (or any other gender bug) love each other very much…”
Well, that would explain how they multiply. But seriously, what gives? It’s 2019 (I’m pretty sure in ten years time it will be the same). How come we are still crashing systems, inviting hackers in and miscalculating money exchanges? Shouldn’t have all of those supposed to go away?
So here’s my rant, starting with a couple of excuses I hear.
“The things we build are complex”
That is true. I think it touches on the root cause, which I’ll talk about later. Yet, we also built software that took people to space and beyond in the 60s and 70s with stone age tools and with no debuggers. From the outset of computing we’ve been building complex software. Why is it only now we need so much testing power, and it falls so desperately short of the actual quality we hope for?
“We don’t have time to test”
That is true. We don’t have enough time to code too. We just hack things together, because… because the business says we need it, now, pronto. And the business takes risks, like releasing too early, without testing. So are the business people to blame? The markets? The global economy?
“No time” really means mismanaged time. Or mismanaged priorities. How much code do you produce? Now, how much of it is in use? Wouldn’t it be wiser to focus on building things that work, (as in test them, really test them) rather than twice as much code that only half works? Wouldn’t it make sense to write lean, clean code that does what we need now, rather than prepare it for features that may never come? Features that won’t be used?
We may not have time, but the truth is we don’t really use the time we have as we should.
“We don’t know everything”
That is true. Spoiler alert: We never will. What we learn tomorrow, will contradict what we built yesterday. Then, at the time we’ve learned of the discrepancy, yeah, there is a “bug” there. It gets fixed immediately, because it’s important, and suddenly there is no bug, right? Funny isn’t it, that what we perceive as a bug has a life expectancy. Only the non-important ones get to live longer.
However, most of them are not “it should not behave like this” kind, rather “it just doesn’t work”. A lot of the bugs are not a requirement surprise, they are mostly quality surprises. Yes, we should explore more. We should also validate and test more.
“The requirements change all the time”.
This is the child of “We don’t know everything” and “We don’t have time” arguments. This doesn’t explain bugs, it just gives them an excuse to exist. We still need to test.
“We don’t have enough testers”
Let me translate it for you: “We have so much code that goes untested”. Or “we don’t know what our programmers are doing”. Or “we don’t understand economics”. It has a ring of true, though. If producing code is a linear-order process, testing everything is exponential. Obviously, we need more testers.
(Maybe instead write more code that actually works? You know, automated tests, TDD, clean code? And maybe do some design reviews and code reviews? Sorry, my inner agile just reared its ugly head.)
The argument is really economic in nature. Developers cost more than testers. So getting a 3 devs to 1 tester ratio may seem economically viable. As viable as thinking developers producing more code equals product success. Makes sense on a piece of paper. The code quantity, however big, still you know, should work, or it’s a waste of precious developer money. And there are ways to do that. (TDD, clean code, automation, reviews. Sorry, that inner agile again).
All the above things almost don’t really explain bugs. Except for the complexity one. But how does complexity breeds bugs exactly?
I’ll continue next time.
0 Comments