Let’s imagine that I run a roulette table with a one-dollar minimum bet. According to http://wizardofodds.com/games/roulette/ the odds are one in thirty-seven on a single-zero wheel that your number will come up. Vegas would pay back accordingly, so if you bet $1.00 on 18 and the little ball lands on 18, the dealer hands you a cool $35. But let’s say that on your $1.00 bet on 18, I’ll pay you $1,000,000. That would be a popular table in any casino, with a one in thirty-seven chance of winning a one to a million payout with only a $1.00 investment.
But if in order to win the million dollars you had to get the exact number a hundred times in a row, you might be a little more reluctant to play, especially if you had to bet all $100 up front. If I said you had to win ten thousand times in a row, and put all $10,000 on the table before the first spin, I doubt anyone would try.
Even the most casual Vegas gambler is doing some version of a cost-benefit analysis on any particular game. If I drop a nickel in a slot machine there’s a very tiny chance I could win, say, $500—or 10,000 times my bet—but the worst that’s going to happen is I’m out five cents. No big deal. But if I have to be willing to risk $100,000 on Blackjack in a weekend if I want to go home with a million bucks, or only ten times my bet, that’s a much bigger risk.
Next time you’re in Vegas count up the number of Blackjack tables, then see how long it takes you to double, triple, quadruple (and so on) that number as you start counting the number of slot machines—and the number of people playing them.
Developing software is that way too, we take calculated risks. We either want the odds to be in our favor, or the potential loss to be negligible. In Waterfall software development where we integrate and test at the end of a long development cycle, we get neither. When we put off integration, it’s as if we’re playing roulette where we have to win a hundred times in a row in order to succeed. If anything doesn’t work, if one spin of the roulette wheel goes against us, nothing works.
That’s a very dangerous, risky casino we’re playing in.
One mistake in the way even a single line of code was written and a program won’t compile, or if it can compile it crashes when you run it. And even once the bug reveals itself it’s usually too late to do anything about it. By batching up features into long release cycles we’re building up more and more risk, which is only mitigated when the software we’re writing is integrated and tested at the very end of development.
Would you write code blindfolded with one hand tied behind your back? Probably not consciously, but we routinely do something similar in most development shops. We write code and compile it but often don’t see how it interacts with the rest of the system until right before we ship. This is when we find out about the nastiest bugs, when it’s too late to do much about it, but try to patch it as best we can.
That’s the real danger of building in a Waterfall environment. We lie to ourselves along the way, sure everything will be fine and the QA team will be able to deal with any little issues quickly and efficiently when it gets to them. But there’s no validation or verification till the very end of the process when it’s usually too late to do much about. It’s amazingly dangerous.
If anything doesn’t work, if one spin of the roulette wheel goes against us, nothing works.
Even a decade and a half into the Agile “revolution” and far too many of us are still playing in the Waterfall casino where we build software in large batches and put off integration until right before release. That’s a very dangerous, risky casino we’re playing in.
Previous Post: « Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software is Here!
Next Post: Build Once Then Enhance »