Triangle of trauma

I’ve been thinking about “the triangle of trauma” a lot lately. Most organisations like ours constantly feel the pinch of budgets, headcount culls, redundancy programmes and the like — all that stuff happens with tedious regularity in spite of how well (or not) the organisation is actually performing. So, when these things kick in, you have to get tough to save your sanity. Hence…

The Triangle of Trauma.

The “triangle of trauma” is a great term (which I found in Charles Miller’s weblog comments) to describe that unholy trinity in software development: time vs. quality vs. cost. The triangle outlines how you can’t have great full-featured software by yesterday for pennies. Something has to give, and the triangle is all about that trade-off.

Now, here’s the rub: have you had any success in getting this across in your workplace? If so, how the hell did you do it?


  1. Simple…

    1. Only deliver what they ask for.
    2. Don't write any documentation.Colin Williams#
  2. Colin is 100% correct, of course.

    Another method involves building the triangle into any time/cost indicative estimates you give out (remembering that 'indicatives estimates' become 'hard and fast quotes' by the time they emerge from the e-mail system):

    1. Cost: think of a really big number and double it.
    2. Time: estimate based on 1 person doing the whole thing at 50% utilisation - this allows you to put more people on it using your 'doubled budget' from item 1 (greater than 50% utilsation never happens, so can be safely ignored).
    3. Quality: keep this entirely secret - any problems down the track can be convincingly blamed on the inevitable scope creep and the fact that no-one but you has actually read the spec.

    Ah, the life of a developer … ;-)

  3. This is one of the tenets I live by all the time as a developer:

    Cheap, Fast, Good…..Pick any 2!

    If you want it Cheap and Fast, it's not going to be Good.
    If you want it Cheap and Good, it's not going to be Fast.
    If you want it Fast and Good, it's not going to be Cheap.

    I have yet to find a situation where this doesn't ring true.

    Sean---Sean Burgess#
  4. With regards to getting it across in the workplace, I actually had a seasoned project manager tell me, "you CAN have all three." Of course, that is totally unrealistic.

    I meet my deadlines, barring circumstances beyond the developer's control. Some executives don't care about circumstances, again, totally unrealistic.

    With regards to sizing, a multiplier of 4 is better than 2.

    Bottom line, I think, is about building trust, and setting expectations.Neill Laney#
  5. The multiplier is Pi.Volker Weber#
  6. I think a quadrangle is a better metaphor. Features-Quality-Time- Cost. I should work up a post on it.

    -richRichard Schwartz#

Comments on this post are now closed.


I’m a software architect / developer / general IT wrangler specialising in web, mobile web and middleware using things like node.js, Java, C#, PHP, HTML5 and more.

Best described as a simpleton, but kindly. You can read more here.