The problem are not in the bugs -- bugs are inevitable. What you can avoid is going in one direction for a time and then realizing that was not the right direction before delivering any value to the customer. This is the kind of rework that nobody wants to pay for, and that happens too often in some so-called agile teams -- specially the ones that try to agil'ize the first release.
| [reply] |
| [reply] |
| [reply] |
It may happen more often in agile teams, but then there's less to "throw away", as they make small steps, and detect they're wrong earlier. If you first spend 6 months designing, then 6 months implementing, and it turns there's a flaw in the design and it's back to the drawing boards. It may have taken you a year to get to a case that needs scrapping, but there's a huge cost for that one time.
But still, it's not the same as scrapping metal. If you have a production line producing expensive, complicated cuts, doing the last cut wrong is expensive. The metal has to be scrapped, and the time spend so far is completely wasted. But coding isn't the same - there's no "scrap" in the sense of a complete wasted effort. As Thomas Edison said "I have not failed. I have found 10000 ways that do not work". Taking a decision (whether it's in the design phase, or in the coding phase) that turns out to not work, does have value. You now know what doesn't work.
One may argue that a baby that keeps falling over is wasting effort: it should spend a few months studying how people walk, then walk on its first try. But babies don't. They try. They fail. They learn from failure. In the end, they walk.
| [reply] |
Except you are not considering the baby a "walk consultant" and you are not paying the baby to deliver a "walk method".
Again, the problem is not in the bugs, is not on the risks, but on the neglected requirement analisys of what the first release should be. I've seen too many so-called agile teams work the first release in "sprints" and have each of those sprints point to different directions because the initial requirement analisys for the first release was neglected, since it wouldn't fit the "two months"/"two weeks"/"whatever"
| [reply] |
(Blink!) Did you actually hear yourself? “Six months designing...” (Then...) “Six months implementing...”
Obvious question: Heavens to Betsy! Just how many “Six Months” does it take?” . . .
Inquiring Minds want to Know ...
Thomas Edison might quite-plausibly be excused; after all, no one had invented a Light Bulb before. But, let’s face it... “by now, we are supposed to know what-the-hell we are doing!”
I mean... even in the worst possible of conditions, our dear CMC Machine Shop does not have to tell Boeing, “so sorry, Boss, see you next year!”
“Jimminy Cricket ... we do need to deliver!” This is Engineering, after all ... isn’t it?
| [reply] |
