The Fourth Commitment

Following my article about customer satisfaction as a third commitment, I read many articles and thought a little bit about this fixed-price thing. Actually it’s quite funny because the software development industry is about 30 years old at least, and it seems we are just starting to wonder why fixed-price projects don’t work with software the way it works in other industries. And I really think it all started with the Agile Methodology hype because now we’re trying to be pragmatic, we’re trying to embrace the constraints of software development instead of hiding them under the carpet. And one of those constraints is this damn iron triangle.

It’s funny to see how people hold on to it, including both customers and salespersons. It’s like they don’t dare to change it. It’s like they are afraid of changing this model. The problem is that each commitment in this triangle involves a substancial risk that no one is willing to take. But what I realized a few minutes ago after reading this very interesting article is that the reason why it’s really not working is because we’re definitely trying to force a cube into a triangle hole! There’s a commitment we’re constantly forgetting: quality! Whether you like it or not, quality is not something implicit, it’s not even related to the developers on the project. Every experienced developer knows that you can’t code with quality, you have to test it.

My father has been working in a car gearbox factory for over thirty years and I’ve worked there during a month as a summer job when I was a student. And my father is a gearbox tester: a box comes in, it’s set up on the bench, my father goes through first, second, third, fourth, fifth and back down, he listens to the noise that the gearbox is making, and if there’s a problem, it goes back to repair. He does that when the box is finished and the proportion of bad boxes is pretty low, because quality is enforced all through the production line by very careful processes that involve as less intelligence as possible. That’s one or the reasons why robots replace human beings in those factories. Because robots don’t think of their kids or dream of their wife. They just do what they were told to.

Do you really think that this kind of quality can be enforced on a software development project? Of course not! It’s far too intellectual and creative to allow such low-level considerations. And yet I’ve heard tens of times this stupid expression: “software process industrialization”. Come on!

The truth is that the only way to enforce quality on a software project is to test it permanently. To test it automatically, functionnally. To test robustness, scalability, reliability, security, performance. And of course you have to review a lot to ensure that the code remains readable, maintainable and flexible. Software quality can be all of that, and enforcing all those aspects is very time-consuming. It takes some time and some special resources as well. You can’t just forget about that.

So we’re left with four risks: scope, budget, resources… and quality, leading us to four commitments to force into our contracts, right? Wrong! Because there’s something that we’re forgetting: those 4 constraints are changing over time. So here we are, trying to force a irregular and mutating cube into a predetermined and unmodifiable triangle hole. And customers still wonder why it doesn’t work?

Leave a Reply