| 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 | |
On to the next issue: We trust in the “others”. Way too much.
Have you ever considered how much of the code we actually write makes of the whole application?
I mean, let’s start with hardware. Computers, wires, antennas, satellites. We use them as part of our solution, and they are not even code. Then there’s servers and routers. There are runtimes and libraries. There’s open (remember heartburn?) and closed code. There’s code that’s been running for fifteen years that nobody can read, but works in production. And then there’s our code that integrates with all of them.
Oh, our code doesn’t really run. There are the compilers that turn into into runnable bits.
So how much of that whole thing does our code weigh?
Let’s be generous and say 5%. Yeah, the “others” are not what runs between our pieces of our code. Our code IS really the “others”. And we don’t only trust everything out there, we don’t even think about those things and how they work.
Until they don’t, but then, once we upgrade/reintegrate/replace them, we usually forget and move on to the new trendy framework that must be better than the old one because… trust?
Our view of testing is limited too, because of our optimistic assumptions that “these things work”. Bugs come out of the cracks and they surprise us every time, because we didn’t even get a flashlight.
Our concept of building software should be a skeptic and cynical. The idea of standing on the shoulders of giants is a good one, as long as the giants are stable.
We’re a pretty optimistic bunch. And optimism gets us every time.
When were you last surprised (in a bad way?)
0 Comments