Better, Faster, and Cheaper

  • I ponder on these things every day, WYPIWYG (what you pay is what you get), ROI, TCO.....and far too often the cheap option is the first option. Cutting corners to make things "work" rather than Do It Once (and never again). A good speck laptop for $800 may sound good but how long will it last?

    Thanks Andy for bringing up the subject.

    😎

  • Jeff Moden (5/5/2014)


    Heh... I don't bother trying to explain the triangle to people that don't know what a straight line is. I just tell them "If you want it real bad, that's the way you'll get it".

    There is no "cheap". If you do it wrong, the rework costs will kill you.

    There is no "fast" unless you get damned lucky and actually took the time to define the problem. Heh... think about that paradox for a minute.:-P

    The only thing left to do is do it right because neither cheap or fast is possible without doing it right. And, as Tom Thompson said on a similar thread, if you do it right, both cheap and fast are much more likely to happen. πŸ™‚

    Truer words were never spoken. I worked on a massive project for a prior employer which was micromanaged down to the smallest detail and the schedules were ludicrously short not, as it turned out, because the management was trying to squeeze blood from a turnip (so to speak) but because they had no grasp of simple algebra and had completely botched the overhead calculations (they had implemented a "quality assurance" program which added 40-50% overhead to the work -- insurance against the risks of such a large undertaking -- but didn't understand how to modify the schedules to account for it). Virtually every task in the project was late and overbudget -- some massively so -- and the end product was a framework of bugs which took a long time to tame. I reasoned that we probably could have gotten the whole thing done months earlier and with much higher quality if we had just been given sensible schedules to begin with. People took every shortcut in the book to try to come in on schedule and most of them backfired (as one might expect) requiring a lot of the work to be done over in even more haste.

    - Les

  • I'm pretty sure the triangle analogy relates to software development projects and not mass produced hardware.

    There's a good reason for that analogy and I think you missed the whole point of it.

    Managing customer expectation regarding cost and ETA is one of the more evasive and challenging things about software development.

  • If someone says "I want this project better, faster and cheaper" then if you are able to do that the implications are that you had a really inefficient system with obvious defects. Probably some form of government system.

    If someone says "I want you to build a system or process that will allow future projects to be accomplished better, faster and cheaper" then that is a requirement and in fact the whole reason for the existence of IT.

    I think you can only build for the future not for the current.

    I'm 2 years off entering my 4th decade in IT and what I have noticed is that software development doesn't appear to be any faster than it ever has been. In some cases it appears to be slower. I think this boils down to people having a "job" in IT rather than a vocational calling.

    I've also noticed that there are umpty millionty billionty frameworks to enable IT development to go faster. Once they are installed they do but every minute saved by using them seems to be lost by installing and configuring them....and in the case of some ORM implementations lost twice over by dealing with the consequences of using them.

  • KFC; It's Fast food. It's finger lickin' good. It's cheep...

    I don't think the triangle can be beaten so easily as some think...

    superstar programmers: you either spend thousands recruiting them (not cheap) or you take them off other projects (impacts someone else's 'fast' or maybe even loose money from customers(not cheap either))

    code reuse: this can be a major win giving us faster and cheaper implementations of good (already proven) code but can it really be considered fast and cheap when we have already invested x years developing our code base on projects that weren't fast and cheap?

    Ben

    ^ Thats me!

    ----------------------------------------
    01010111011010000110000101110100 01100001 0110001101101111011011010111000001101100011001010111010001100101 01110100011010010110110101100101 011101110110000101110011011101000110010101110010
    ----------------------------------------

  • I think that the triangle is most appropriate, and most often used, when someone is attempting to alter an existing plan. Their stated aims are usually to get more features, reduce costs or speed up completion. In this case there is a baseline to compare against.

    In short, this triangle is not about defining work but showing the constraints of redefining work.

    Gaz

    -- Stop your grinnin' and drop your linen...they're everywhere!!!

  • Tresiqus, I wasn't writing for the MBA's and I'm not trying to, I suspect most of them don't browse here. And I really don't disagree with much of what you (or Jeff, or others) have said, we all get that in the real world there are constraints and challenges, and yes, even bad management sometimes. I can't fix bad managers (well, sometimes maybe) and that isn't the goal, what I wanted was to see what the thinking was about the topic and get you thinking about the topic, because it's easy to learn something in year one or year five that is interesting and true, but in year 10 or year 15 might become a little more nuanced if you revisit it.

    The one place we might disagree is on dealing with management. It's their job to push. Not stupidly and not blindly, but there is a natural tension between us (the good guys!) that want to do it well and do it right and that sometimes want to be conservative and sometimes want to be bleeding edge just because. Tension is good, it can challenge both sides to (just like the editorial, hopefully) revisit their stance and framing and all the rest to see what really is possible.

    Appreciate the comments!

  • For all those pondering "the triangle", I previously stated that a lot of managers can't figure out "the straight line", never mind "the triangle". πŸ™‚

    To wit, I respectfully submit a video of a "first contact" meeting between some managers of a company with a need, the managers of the selected consulting company, and a Developer that "gets it" but can't overcome insistent managers and changing scope. It even covers "ballooning costs". :hehe: Who amongst you has not been in such a meeting? If you're drinking your favorite beverage while viewing this video, make sure you have a liquid-proof keyboard and monitor because you will lose it during this video. πŸ˜›

    The task is simple... draw 7 red lines. 😎

    http://failblog.cheezburger.com/share/59643393

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • I've seen it, but it's always worth another viewing.

    It's funny but/because it's aneurism-inducingly close to reality.

  • Andy, it might seem like I'm laying it in for you, but I'm really not. Seriously, I'm joking about my RAEG.

    But managers don't push to advance the state of the art or create tension or any of that. Managers know that pushing gets them a bonus. So push that habitrail of nerds TO THE MAX. They should enjoy it, right? They're nerds after all. And we all know nerds aren't people.

    And like I said, this is a misapplication/misunderstanding of the triangle, which is why it seems the triangle doesn't apply. I think what you're looking for is some variant of Moore's Law in this case, NOT the triangle.

    But if your neighbor could have even bought that new hotsy-totsy specced laptop a decade ago, how much do you think it would have cost him/her at that time?

    It would have been crezzzy expensive wouldn't it?

    Could you even buy a multicore, 64bit laptop in 2004? Geez, I don't even remember what was available then. Did we even have laptops that could address 8GB of memory like are available today(usually at a discount)?

    (I've mined my own REAL life experiences for my depictions of the situations. No names here, but like Dragnet, events were true.)

  • I'm sure Andy misapplied the triangle analogy.

    The triangle analogy could have been applied to how long it took to get to 2014 and the kind of computers available these days..

    I think it's fair to estimate that the start date for the laptop that Andy mentioned was around 1950 or so.

    Andy we're you born then? Anyway, it's definitely evolved and improved, at someone's great expense.

    So I think it has taken about 64 years to finally arrive at the point where we can by a better faster cheaper laptop.

  • I think you can poke a hole in almost any rule if you try hard enough, except in the hard sciences probably. Especially these kind of rules, but I think that it generally holds up in most cases so there is value in it as a guiding principle. It acknowledges the reality that we live in a world of finite resources and that tough and mutually exclusive decisions are sometimes necessary.

  • bedmett 9 (5/6/2014)


    I'm sure Andy misapplied the triangle analogy.

    The triangle analogy could have been applied to how long it took to get to 2014 and the kind of computers available these days..

    I think it's fair to estimate that the start date for the laptop that Andy mentioned was around 1950 or so.

    Andy we're you born then? Anyway, it's definitely evolved and improved, at someone's great expense.

    So I think it has taken about 64 years to finally arrive at the point where we can by a better faster cheaper laptop.

    The requirements of people and businesses are not the same, they have grown. One could argue that in simplified terms such as using a primitive Pythagorean triple ( a2 + b2 = c2 ), its the c!

    Hence, you can go faster but you have to go further!

    😎

  • Saying that there are exceptions to a general rule only implies that the general rule really is true most of the time.

    A software developer often has to manage customer expectations.

    If your customer expects you to develop something that is good and cheap and can be developed quickly then you already have a customer expectation problem. I think it’s probably a mistake to just assure a customer that you can deliver on his expectations.

    I think the triangle analogy is a good tool. You need to think of a nice way to tell the customer (or the boss), β€œThere is good, fast and cheap. Pick two”.

  • As a number of people have said, the article applies the triangle to a process for which it was never intended. The triangle is about research and development processes, not about the manufacturing process for a known product with a working production line.

    So the cost measurement is the wrong one: for a laptop (which is the example used in the article) the cost that is involved in the triangle is the cost of designing the product, working out how to manufacture it, and setting up the production line. It's already been pointed out pretty clearly that "fast" doesn't refer to the end product but to the development, validation, and mandufacturing setup process. The cost of the final product and its speed of operation are both part of "good", not the "cheap" and "fast" of the triangle.

    The cause of the triangle is quite straightforward. There are various ways of doing research, development, and manufacturing setup. Some of these ways are "right" in the sense that they work well. Othere are wrong in that they don't work well, indeed don't really work at all. For any given project with a given set of aims, doing it right is essential. If that implies unacceptable timescale or unacceptable development cost or both, there are two options: (i) scrap the project and (ii) relax the requirements on the end product. Doing it wrong in an attempt to reduce costs and/or timescale is a fools game, the effect will be to increase both timescale and cost (or lead to the project being scrapped after a lot of effort has been wasted on it). Of course it may be possible to make trades between cost and timescale, but this tends to be more difficult than people expect (although people know that nine-fold bigamy doesn't deliver the 1-month baby they don't believe that that applies to their required miracle); more than 40 years ago the famous "you want it when?" poster was all over the place and clearly indicated that most of the technical community actually understood that management tred to ignore reality and deny the alidity of the triangle, so it's shocking to see today an article that gets it so wrong.

    Tom

Viewing 15 posts - 31 through 45 (of 46 total)

You must be logged in to reply to this topic. Login to reply