Software commitments guarantee poor quality

You’ve heard of the iron triangle, right? Of course you have, I think they teach it in coder kindergarten now. Since I couldn’t find any freely-licensed images of it in less than a minute, I drew my own.

As a refresher, you can only pick two of the three points of this triangle. The third one is therefore chosen for you. Well, that’s how it’s supposed to work.

The first break with the reality of modern software development is that “how much you spend” is not really pickable. This is the “resources” section, i.e., how many people are working on your thing. In reality, you don’t get to a) hire more people when you think you need them and b) have new people instantly up to speed to help you out when they do show up (this is Brooks’s Law).

Acknowledging this, I believe, I sometimes see “how much you spend” dropped, and “how good it is”, i.e., quality, moves to its point of the triangle. My ultimate argument here can be illustrated with either scheme, but I’ll just stick with the one I already drew, because I don’t want to make another picture.

The second break with reality is that teams never think about trading off quality. Quality is always The Most Important Thing, of course! How could we ever decide to ship low-quality products? Customer satisfaction is our highest priority.

Well, the reason that triangle is made of iron and not rubber is that it cannot be bent, cannot be twisted. So, as long as you are adjusting for the other points on the triangle, you are adjusting all of them. It doesn’t matter if you are conscious of it or not, you’re picking. And that means that you are, fully, determining the quality of your product when you trade on “how long you take” (time) or “how much you build” (scope).

Now. A common malpractice of customer-facing manager types is to make commitments to those customers. I can understand that they may feel like they need to make some commitments in order to appear confident and reliable, especially when a customer is on the fence about committing themselves. But making a commitment is like taking a wrench to the iron triangle.

That’s because a commitment is:

  • “We will make such-and-such for you …” which is scope
  • “… by such-and-such a date” which is time

That’s it! In one sentence you’ve pinned two of the three corners of the triangle. Any control that the rest of the team / organization might have tried to exert over the plan is mooted. But that’s OK, right, because we can just throw in more resources … oh, wait … everyone is already working on other tasks and we can’t hire quickly enough.

And, since any commitment worth making will be ambitious in both scope and time, it’s just driven quality into the toilet. One fell swoop, any further software engineering practices are irrelevant.

You might be able to slip out by redirecting your existing resources to work on this commitment, provided they are both familiar with what needs to be done and also aren’t working on other past commitments you already made.

Or, you could crawl back to the customer and sheepishly ask for more time or to do less, and maybe, if they like you, they will grant you an extension, this time. When you do this, this is you strung up on the iron triangle and being dragged to the customer in order to move a point on the triangle. Still, this does mean that you care about quality – a redeeming trait. How long until you shed that, though? Practice makes habit.

So, what do you do instead? Here are my pie-in-the-sky, completely impractical recommendations.

  • Give the customer visibility into your development process and load up front. Treat them as a partner in solving their problems with your product.
  • Be honest about difficulties that you encounter along the way, because you will, because that’s software development. Regularly update the customer about them, so when you need to adjust your plans, they understand why.
  • Include the customer in working out a solution. They won’t mind taking more time to do something when it was their idea, and you want to get it right for them.
  • Customers usually don’t need X by Y anyway. Some internal delays on their end will keep them from even trying out X until Y + some arbitrary number of days or weeks. So, establish progress checkpoints instead to re-calibrate on urgency.
  • Customers usually don’t need X anyway. By the time you finish it, they really wanted something two steps away from X, and oh, they’ll need that by Y + delta. So, deliver tiny, incremental changes towards X over time, and re-aim based on their feedback.

The theme here is not trying to look like you’ve got everything completely under control with 100% assurance, because you know you don’t and they know you don’t, so let’s all just stop lying to each other and solve problems together. This is called humility. So, are you willing to swallow your pride in the pursuit of quality?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s