Software Craftsmanship Vs The Iron Triangle: Cut Scope, Not Quality

"You can have it fast, cheap, or good.  Pick two."

This phrase is all too familiar to anyone who's spent any amount of time in software development.  For those who might not have heard of this phrase, it's a layperson's way of talking about the Iron Triangle of project management, which describes the constraints that every project must operate under.  These constraints are scope, schedule and cost, where scope is the requested functionality and features the system should provide, and schedule and cost are time and money, which are obviously not unlimited.

The Iron Triangle

Creating balance between these three constraints can make or break any given project, and while literal reams of articles and books have been written on the subject not much has been said regarding how software craftsmanship fits in (hint: often poorly).  This is unfortunate because life in this modern age is increasingly dependent on technology and the software that is directing it. Making decisions which allow low-quality, defect-ridden code out into the wild will have an equally increasingly costly and dramatic effect on an increasingly large number of people.  It follows then that software craftsmanship will become increasingly important to insure that high-quality, defect-free code is released instead.

Having said this I believe it is important to reflect on where software craftsmanship fits into the Iron Triangle.  As a craftsman I don't believe that quality should be sacrificed simply for the sake of expediency.  I believe that if code is to be written it should be written well.  It should be well-tested (Test-Driven!), follow good design principles, and be maintainable among other things.

This stance is not unreasonable, it is in fact the only truly reasonable approach in an industry which can have such a tremendous impact on millions of lives.

To take it out of the terminology of software development and into construction, no one ever goes to the general contractor and says "I can't afford a well-built mansion.  How about you still build me the mansion and just use cheap materials and work overtime to get the job done?"  If they did they the contractor would discretely laugh at the would-be mansion owner and suggest that they instead build a smaller house.

Unfortunately, if you find yourself in a situation where craftsmanship is at odds with the (ever-shifting) constraints of scope, schedule and cost you'll quickly find that the organization's appreciation for well-crafted, maintainable and incrementally delivered code will often take a backseat to cost-cutting, corner-cutting and a "Just ship it!" approach.

Knowing how organizations react when confronted with the choice between supporting well-crafted code and the need to simply ship something we, as craftspeople, should strive to truly understand what the organizations goals and constraints for a project are, and be ready offer approaches which don't call on us to sacrifice the quality of the software.

Let's get back to the "fast, good, cheap" quote I first mentioned and see how craftsmanship fits into each of the scenarios.

Fast and Good

Under the right conditions craftsmanship can thrive in this category.  If the scope is reasonable and the organization has the budget to support a team of knowledgeable craftspeople then a lot can get done quickly.  Obviously there are a lot more factors involved in the success for any project, but a highly motivated and experienced team can crank through an amazing amount of features.

On the other hand, if the scope is outrageous (which, lets be honest, is the more common case) or the budget can't support a team of experienced developers then the level of craftsmanship on the project is at risk.  The business may be tempted to say "All that unit testing you're doing is taking too long, can't we just skip that?", or simple budgetary concerns may cause them to under-staff the project.  Countering these two possibilities from the craftsmanship angle may involve suggesting cutting scope to deliver value while staying within budget, and delivering incrementally to give them something to get their hands on early in the process. 

Fast and Cheap

This is is dangerous territory for a craftsperson.  If the organization wants it done now and they don't want to pay a lot for it then by default they're not really concerned with the quality of the software.  They're concerned with ramming through the project and delivering something. High cost doesn't necessarily equate to a high degree of craftsmanship, but they often go hand-in-hand.  Again, as craftspeople we shouldn't be willing to sacrifice quality just to ship something.  The play here is to cut scope again if possible, and if that doesn't work then you may need to consider walking away from the project (a difficult decision to make in many cases).

Cheap and Good

This is an odd scenario to be in, as it implies that the organization wants it done well and inexpensively, but that it's OK for the project to take longer.  The "taking longer" part doesn't normally equate to inexpensive, as the longer the project runs the more expensive it will be.  If the timeline is fixed (as most projects are), then this scenario implies that the organization can't afford a team of craftspeople to tackle the problem, which places us squarely back in "Fast and Cheap" category.  Again, cutting scope, not quality, and delivering incrementally should be explored as options.

---

Convincing the organization to accept a reduced scope on a realistic timeline with a realistic budget is hardly ever an easy sell.  Often organizations are unable to fathom why what they're asking for is nigh-impossible and will instead push to either rush the project or ask that it be done on a shoestring budget.  Nevertheless, it is up to craftspeople to offer alternative solutions and to refuse to sacrifice quality in the face of adversity.  To those craftspeople who are facing this dilemma I say this: Good luck and stand firm!