[rpwilcox]

> Price, Quality, Time

Please don't use those terms. There are better ones: Price, Scope (size) and Time.

The problem with the phrasing "Price, Quality, Time" is that nobody wants to sacrifice on quality. Everyone wants a app that doesn't crash -- the client, the end users, and the developer. Yes, yes, technical debt is a quality concern, but as long as the app runs the client doesn't care in the moment that there's copy/pasted code everywhere and future changes will be "interesting". It's hard to sell "but if I take an extra half day to make this change future improvements will be easier", at least not in tight projects.

But Scope, scope can start negotiation with clients. "Ok, you do know this new control you want will probably take something like 10 hours to write, do you really want it or can you make do with a default one?"

If a client drops a fixed bid project on me with a dictated time deadline, sure as anything I'm going to take control of the scope side of the project triangle.

[ScottWhigham]

Good post. The only quibble I could have is that almost everyone understands what "Quality" is yet it requires education and experience to understand "Scope". Maybe that's a conversation/education you have with prospective clients though.

[rpwilcox]

> The only quibble I could have is that almost everyone understands what "Quality" is yet it requires education and experience to understand "Scope"

I would say that's a feature, not a bug ;)

Everyone "knows" what quality is so nobody wants to cut it. The client expects a deliverable with a (mostly) bug free deliverable, and the developer expects to be able to try to create a codebase with as little technical debt as possible.

There are certainly situations where quality is cut (technical debt that you might avoid if you had more time, the customer deciding to skip beta testing), but as a developer I can't say, "You want this cheap and tomorrow, so we as a team are going to ship a buggy app". Because the first thing the client does when they give the app like that a spin? Come back to the developer with a bug list a mile long and say the current quality is unacceptable.

So then it's not the project management triangle of, "You take two sides, I'll take one". ;)

But if, as a developer, I say, "You want this cheap, and tomorrow, which means this thing needs to have two of these things you want, not all 10. Help me choose the most important things here." Which is a hard conversation (nobody wants to kill their darlings) but you can quantify scope (estimate and prioritize the work).

We certainly know a lot about quality from Deming, Juran, and Pirsig, but the margin is too small, and the night too short, to put this conversation in that scope.

[grobertson]

I've always dumbed this down to "Fast, right, or cheap."

[nsxwolf]

I really don't get this. Can I really pick cheap and right, and just expect it to take longer?