In our cartoon for today, you can see that a bug has gone skateboarding on Boehm’s Curve.
What does Boehm’s Curve tell us? The principle message behind the Boehm Curve is that bugs are always more expensive to fix later on in the process. It follows to logic in Boehm’s Curve that the same bugs would be much cheaper to fix earlier on in the curve.
Boehm’s Curve essentially states that you should go ahead and fix as many bugs as possible during the requirements and testing phases of a project as after deployment these bugs grow massively in expenditure involved.
Boehm’s Curve is explained well on the Software Carpentry site as well as on Stack Overflow.
Join 60,000+ Subscribers
For latest blogs, industry updates and exclusive tips.
*Your email is safe with us, we also hate spam
Watch now
It’s pretty amazing that so much software is being developed and deployed in a way that exposes Boehm’s Curve as being a very weak heuristic, yet it still seems to get treated as some kind of Law of Nature.
I wrote a blog post about this several years ago. http://www.developsense.com/blog/2009/08/tyranny-of-always/ For a really thorough treatment of the issue, see Laurent Bossavit’s splendid book, <em>The Leprechauns of Software Engineering</em>. You can find it <a href=”https://leanpub.com/leprechauns” rel=”nofollow”>here</a>.
Instead of claiming that “bugs are always more expensive to fix later on in the process” (which is demonstrably untrue), why not try a little nuance: bugs <em>may</em> be more expensive to fix later in the process. We testers need to question software development myths, not swallow them whole.
—Michael B.
Actually, given that the heuristic was created in the MAINFRAME days, it actually was quite true and carried through to the LATE 1990’s when object oriented development became more pervasive.
At this time, it MAY be true or MAY not be true depending on the organization. IF an organization has a SOLID development methodology which it ADHERES to, and a vigorous TESTING strategy with automated regression testing THEN – and ONLY THEN IMHO – would this NOT be true.
In addition, YES, I have been around a while, and I have run BOTH mainframe projects AND object oriented projects (You know the diff I hope). I have seen companies that are good at is, and others that should never have turned off their big machine.
CULTURE, Discipline, and strong coding reviews are principles in making this NOT true. Keeps many of us employed by the FACT that many companies STILL have none of this.
Hi there.
I love this graph and would like to use it in my presentation next week. Is that Ok with you?
Thanks
Sure Bede, go ahead!