back to article Most developers have never seen a successful project

Most software professionals have never seen a successful software development project, continuous delivery evangelist Dave Farley said, and have “built careers on doing the wrong thing”. Farley, kicking off the Continuous Lifecycle conference in Mannheim, said study after study had shown that a small minority of software …

Page:

  1. Gordon 10
    FAIL

    Bollocks - Right stat wrong conclusion

    Most of us know what good looks like, just that most of us lack the clout and the opportunity to stop a project going off the rails, so spend the majority of our time doing damage control or just saying 'on your head be it'

    Fact is once the amount of meetings, power points, consultants, project managers and ba's reach a certain critical mass - nothing can save a failed project.

    Delivery methodology whilst it can be helpful is just one of a multitude of factors.

    1. LucreLout

      Re: Bollocks - Right stat wrong conclusion

      Fact is once the amount of meetings, power points, consultants, project managers and ba's reach a certain critical mass - nothing can save a failed project.

      Agreed completely. In my experience that tipping point comes no later than when you're spending 50% of your budget talking about building something and less than half your effort actually building it. Every large project I've seen that goes beyond that overruns or doesn't deliver at all.

      El Reg - #BBW, you know it makes sense.

      1. Anonymous Coward
        Anonymous Coward

        Re: Bollocks - Right stat wrong conclusion

        Also fixing things.

        50% of the cost should be development, except certain massive applications.

        Also, the system should be as simple as possible. Complexity kills projects.

        Frameworks are to be used only if needed: using spring, etc is only good if you need it. If it makes things more compley, why use it? because it autobuilds things? you WILL find bugs/quirks and lose more time than gained, unless you have an experienced team.

        So, for me is: KISS and expend money on devs.

        One last thing: update the damn tech you are using, right now we are just finishing a big project... using java EE 1.4. Just the time the devs lost boxing/unboxing, and doing things we did not remember well (no @bean, etc), or having to go arround bugs that got fixed 7 years ago (but Java 1.4 does not support) is amazing.

        We could have ported the damn thing to java 1.7 or 1.8.

    2. silent_count

      Re: Bollocks - Right stat wrong conclusion

      "Bollocks"

      From a guy described as 'an evangelist'. Nobody could have seen that coming.

      1. Potemkine Silver badge

        Re: Bollocks - Right stat wrong conclusion

        Nobody expects the Evangelist Cursing!

        Ok, never mind...

        1. Destroy All Monsters Silver badge
          Trollface

          Re: Bollocks - Right stat wrong conclusion

          Our PMO knows EXACTLY where we are on a perfectly blank surface with moving hills

    3. Hollerith 1

      Re: Bollocks - Right stat wrong conclusion

      We know what we're involved in ISN'T a well-run project, we sort if know how it should be being done, but we can't do anything about it. Most project managers can't put A, B and C in the right order, so when a project is handed to them, isn't a fail from the start. But mostly the project fails before that point, because the goal, the purpose, etc is so fuzzy that the project could take a hundred different tracks and still appear to be right.

  2. AndyS

    What is this article on about?

    There is so much missing from here that I'm not sure what to think.

    So because 17% are catastrophic, nobody's ever seen a good one?

    What is this fellow actually advocating?

    What is he saying is wrong with how things are currently done?

    Is this really just a recycled press release selling something for someone who wants it sold?

    As it stands now, all he appears to be doing is throwing noise at a problem, hoping to make a name (and some money) for himself. Perhaps by becoming a Development Management Training Consultant or similar. Which might, in some people's view (like Gordon above) actually make him more of the problem than the solution?

    1. Anonymous Coward
      Anonymous Coward

      Re: What is this article on about?

      It's the shortcut reporting of the speaker saying studies have shown few projects completely successful, [some have been partially successful] and some (17%) have been really bad.

      If there's a small number - and what was that number? - of completely successful ones, what are the chances it's the same subset contributing to those reported successes. Or does every developer occasionally get lucky once?

      1. Robert Helpmann??
        Headmaster

        Re: What is this article on about?

        Or does every developer occasionally get lucky once?

        If they were occasionally lucky, it happened more than once. The answer to your question is "No."

        1. Anonymous Coward
          Anonymous Coward

          Re: What is this article on about?

          "Or does every developer occasionally get lucky once?"

          Are we talking about honeytraps again?

        2. a pressbutton

          Re: The future...

          Or does every developer occasionally get lucky once?

          Stop raising the hope of the readership.

      2. joeldillon

        Re: What is this article on about?

        'Most developers have never seen a 100% succesful project' and 'most developers have never seen a succesful project at all' are /wildly/, misleadingly different statements. We live in the real world and most projects have issues of one sort or another that mean they didn't come out 100% according to plan, but for most of us 99% is good enough.

        1. Anonymous Coward
          Anonymous Coward

          Re: What is this article on about?

          Actually I think it's that 99% is good enough to be implemented, but still annoying that a bit got missed.

          The way I interpret it, is that IT professionals are rarely satisfied with the results because they don't like having to make the natural compromises.

    2. Deltics

      Re: What is this article on about?

      You need to be careful to distinguish between a badly written article and the subject matter that the article is covering.

      17% is the only statistic reported in the article, but this was only those projects which were so catastrophically bad that they risked the very existence of the companies involved. There is a vast spectrum of failure between "sank the business" and "didn't go as well as expected or required".

      The article does not report what % of the 5,400 projects studied were successful, but it is not 100 - 17%.

      And why shouldn't this guy seek to make a name for himself off the back of some good ideas, IF the ideas are indeed good. Just because those ideas come in part from the past doesn't necessarily make them bad ideas. Some of the best material on software project management was written in the 70's and is ignored by subsequent generations of developers simply because of that fact, to their cost imho.

      (ftr - I was only born in 1971. My assessement of the state of the art in the 1970s is with the benefit of hindsight and observing how those practices could have saved the bacon of any number of projects in the 90's and beyond that were run according to "modern methodologies and principles").

      e.g. note the emphasis in the Winston Royce paper on the importance of documentation. And note that Agile preaches that documentation is the least important aspect of any project. Every tenet of the Agile manifesto directly or indirectly devalues and dismisses the relevance or importance of documentation (even the three that don't mention documentation directly: 1) processes = documentation, 3) contracts = documentation, 4) a plan = documentation)

      The manifesto sounds very "efficient" in principle by seeming to emphasise delivery. The mistake is the naive belief that documentation is not important to successful delivery. Think about all the projects you had to work with where immediate problems were caused by insufficient documentation to be able to understand what the system was doing, how and why and where the inevitable conclusion was that to get that understanding you were going to have to start over, sometimes even before that original project had been completely delivered.

      True, Agile does not dictate NO documentation, but the High Priests of Agile in an Agile project will use their church to brand anyone suggesting that more documentation is needed as a heathen and a philistine to be cast into the desert to contemplate their sins.

      1. Vic

        Re: What is this article on about?

        And note that Agile preaches that documentation is the least important aspect of any project

        It most certainly does not.

        You can find the Agile Manifesto here. Note that the only thing stated to be more important than comprehensive documentation is working software. That doesn't make it the "least important aspect"; it is merely secondary to getting the code working. Nothing else is mentioned as being more important.

        the High Priests of Agile in an Agile project will use their church to brand anyone suggesting that more documentation is needed as a heathen and a philistine to be cast into the desert to contemplate their sins.

        And there's your real problem - people taking on that role with no understanding whatsoever of what Agile actually is. If you've been on a project that makes such claims - it wasn't an Agile project. IME, the vast majority of self-proclaimed Agile organisations are no such thing...

        Vic.

    3. big_D Silver badge

      Re: What is this article on about?

      I've worked on dozens of successful projects over the years... :-S

      Guess I must be "one of the lucky few" then, according to the author of the report.

  3. Anonymous Coward
    Unhappy

    Needs just a tweak.

    Most software professionals have never seen a successful software development project.

    to

    Most professionals have never seen a successful project.

    Fixed

    1. Anonymous Coward
      Anonymous Coward

      Re: Needs just a tweak.

      Depends.

      On civil construction / arquitecture, normally, the project is sucessful when the building stands the test of time (aka doesn't fall due to structural flaws).

      Perhaps software needs to learn a page or two from other industries.

      1. kmac499

        Re: Needs just a tweak.

        I agree totally;

        I believe the major differences between physical and software engineering are twofold

        Firstly the physical builders repeatedly use the same tools techniques and materials which makes estimating the duration and cost of a build more likely to be 'accurate' This repetition means when you've been laying bricks for ten years, you know how long it takes to lay a thousand to fill a gap. We software developers cannot accurately say how many lines of code will be needed to fill a gap, let alone how long to write them.

        Secondly the physical builders have accurate blueprints which precisely limit the scope of a project the client can see them and sign off on them freezing the design. Software systems are rarely if ever described in an unambiguous closed manner, so the clients expectation are always at odds with the developers hence the project is constantly at risk of change.

        A final point; how come it's always the project that goes over budget and never the budget that was undersized? Maybe we need to improve the estimation skills.

        1. ciaran
          Go

          Nuclear Power Stations

          There are project fails in the realm of civil engineering too. From bridges being built before the road that never appears to cost overruns and leaks on chemical or nuclear plants. The ITER project is currently exceeding its budget, the US F35 is a laughing stock, etc.. The software industry shouldn't be singled out.

          1. Anonymous Coward
            Anonymous Coward

            Re: Nuclear Power Stations

            Those are the rule rather than the exception. It is the other way around in software engineering.

            Even the abject failure that is the F35 is much better than the typical software project. They actually took the time to determine all the needs and design a solution that met them all. The fact they tried meet everyone's needs in a single plane is the reason for its failure of course - the software equivalent would be trying to build a word processor that is also a web browser and an AV solution.

            The problem in software projects is the requirements phase. Everyone knows this, but no one knows a solution for it, which is why the "let's just skip that phase" type solutions like Agile have become popular. No one knows what they want out of a software project or even what they need ahead of time. I've always thought it would probably be more efficient to do a very quick requirements phase, build a rushed solution and don't bother much with fixing bugs, and finally try to graft on some quick and dirty functionality that meets the needs and desires that everyone forgot about during the requirements phase. Then you start over from scratch and do it right now that you actually have a pretty good idea what it is you are trying to build.

            Imagine trying to build a car when you haven't decided how many passengers it needs to carry or how much cargo, so you try to switch from building a coupe to a minivan after you've built 80% of it. That's the typical software project.

            1. Vic
              Joke

              Re: Nuclear Power Stations

              the software equivalent would be trying to build a word processor that is also a web browser and an AV solution.

              Emacs?

              Vic.

            2. allthecoolshortnamesweretaken

              Re: "The problem in software projects is the requirements phase."

              That's the problem for any project. (Not the only one, but the best opportunity to doom any project to failure right from the start.)

        2. Anonymous Coward
          Anonymous Coward

          Re: Needs just a tweak.

          Maybe we need to improve the estimation skills.

          Capt'n, I'll take me at least three weeks to fix the warp core!!

        3. Deltics

          Re: Needs just a tweak.

          And more to the point, if bricks were laid using the same principles involved in software projects, we would dismiss the techniques used to successfully lay bricks in the past simply because those are old techniques.

          Every few years there would be a new Brick Laying Methodology Better Than The Last.

          The kids coming out of Brick Laying School would be convinced that their forebears didn't know what they were doing and start "inventing" bricks made of straw and held together by pig sh*t because these old fashioned fired clay and mortar techniques are just sooooo yesterday.

        4. allthecoolshortnamesweretaken

          Re: Needs just a tweak.

          You've never built a house...

      2. Tom 38

        Re: Needs just a tweak.

        On civil construction / arquitecture, normally, the project is sucessful when the building stands the test of time (aka doesn't fall due to structural flaws).

        Perhaps software needs to learn a page or two from other industries.

        I notice very few buildings go up in an Agile manner. They all seem to plan ahead on what is required, and seem to get agreement from all parties on what will be built before they even start anything.

        Ah, we can dream.

        1. a pressbutton

          Re: Needs just a tweak.

          No.

          People shape themselves around the building as built.

          One good example is bristol Southmeads PFI hospital. On commissioning iirc

          - the x ray room did not have any lead in the right walls (so it was not used)

          - one of the operating theatres had the wrong aircon so was not sterile

          (i think fixed now)

          - there is no staff car park and staff pay 0.6% of salary for parking...

          (still not fixed)

          I recommend "How Buildings Learn: What Happens After They’re Built " by stuart brand.

          Having said that people shape themselves around the provided software too.

          1. cynic56

            Re: Needs just a tweak.

            - there is no staff car park and staff pay 0.6% of salary for parking...(still not fixed)

            I believe you are mistaken on this. Based on every hospital I have seen in the past 5 years, this is a mandatory requirement - not a fault. Raking salary back in the form of car park payments is now standard practice for hospitals and a guaranteed revenue stream.

        2. Deltics

          Re: Needs just a tweak.

          The buildings, yes. The floors and rooms of those buildings on the other hand are very agile.

          When you build a new apartment block you need a rigidly specified, highly engineered structure.

          But when the occupant of the penthouse suite moves in they can decorate however they like and can even remodel interior walls if they wish (within the limits of maintaining structural integrity of any load bearing structures).

          The mistake is to think that just because that the way interior design works it is also the right way to go about constructing the entire building.

        3. Unlimited
          Mushroom

          Re: Needs just a tweak.

          "get agreement from all parties on what will be built before they even start anything"

          Spoken like someone who has never worked on any construction ever.

          - The client changes their mind all the time.

          - Depending on who is off sick at the time, the authorities change/reverse/reverse again what they will sign off.

          - The architect floats around with vaguely scribbled ideas.

          - Components arrive built wrong and you either adapt to them, adapt them, or accept delay of getting them re-done

      3. Grikath

        Re: Needs just a tweak.

        "On civil construction / arquitecture, normally, the project is sucessful when the building stands the test of time (aka doesn't fall due to structural flaws).

        Perhaps software needs to learn a page or two from other industries"

        Yeah, but in civil construction the stuff you build on isn't quicksand, the materials do not deteriorate within 5 years, with no hope of replacing them, and the basic concept of the building is generally not based on the latest fad in Unicorn Poo.

        1. Naselus

          Re: Needs just a tweak.

          "the basic concept of the building is generally not based on the latest fad in Unicorn Poo."

          Clearly, you've never worked with architects.

      4. albaleo

        Re: Needs just a tweak.

        "Perhaps software needs to learn a page or two from other industries."

        Yes, but perhaps gardening rather than heavy engineering industries.

      5. Doctor Syntax Silver badge

        Re: Needs just a tweak.

        "On civil construction / arquitecture[sic], normally, the project is sucessful when the building stands the test of time (aka doesn't fall due to structural flaws)."

        The ratio of design/physical construction phases are very different.

        The civil engineer/architect team draws up a design & then hands it over to the construction contractor who in turn hands over to the direct labour to the brickies, sparkies, plumbers etc. but a good deal of the detailed design to the host of manufacturing companies who make the bricks, the cement, the screws etc. (and good old nature which has been in the wood making business for millions of years).

        In software the physical construction is trivial. The design team is responsible for a much higher proportion of the work. Where pre-built components (libraries) are available the effort needed by the design team in understanding their interfaces is much greater (how complex is the interface of the common house brick?).

        There is also a difference in the regulative environment. The building client can't decide that proper lintels, electrical insulation and ventilation aren't needed but nobody will stop the software client deciding to forego proper encryption or sanity checks between the web front-end and the database.

        1. allthecoolshortnamesweretaken

          Re: Needs just a tweak.

          You've never built a house either...

      6. PatientOne

        Re: Needs just a tweak.

        You didn't... no, you did... oh, boy...

        *puts on Civil Engineer's hat* (this is a very simple overview, btw).

        You start with a specification. You build to that specification. End of project.

        *puts IT developer's hat on* (yes, I really do have both)

        You start with a specification. You develop the core components and impliment them. Now start the cycle of refinement.

        You can develop with agile methodology - do the core, plus as many extras as you can fit in, but you can always add more later, as and when you're ready, with little to no disruption or performance hits. You get the benefits from the initial development and expand on this as required. This is the normal approach to software development.

        You can build in a modular approach, but doing so needs advanced planning and expanding will involve distruption and will probably affect business performance. You may not see any real benefit until all the work is done, either. It is also not always possible to work this way, or desirable, hence why most Civils projects involve getting as much done during the initial build as possible - minimise latter disruption and keep costs down in the process.

        So yes, there are similarities, but due to the technical aspects, the methodologies have to vary hence they're not really the same. Interesting comparing them, though - I never thought I'd get to use both my qualifications in one post... thanks :)

  4. yoganmahew

    Aguably?

    Or indeed, just as or even more disastrous once there's any complexity in the environment.

    Ad hoc management, the idea that resources are interchangable, poor planning, the wrong sort of feedback loops, no maintenance budgets, denigration of experience, absence of functional (customer/business) training... and many many more!

  5. Anonymous Coward
    Anonymous Coward

    Did Farley actually cite some concrete examples of successful projects? Any why couldn't they be mimicked?

  6. Anonymous Coward
    Anonymous Coward

    Unless only lifelong EDS employees were surveyed, this article is bollocks.

  7. 1Rafayal

    Wow, this means the companies I have worked for over the last decade have been really lucky.

    Either that or the books author is trying to do an Iraq War on clueless pm's by telling them the "truth" about development projects...

  8. Steve Davies 3 Silver badge

    Continuious Development

    Means that the work is never done so how do you know if it was a good'un then?

    MBA claptrap if you ask me. does he have a book or a training couse to flog?

    Yes I have worked on many successful projects in the last 40+ years. This includes one for [Large UK City Gov Department] that came in on time and underbudget.

    Naturally there were some lemons as well.

    There were aqlso the ones that viewed from the outside you could see that it was a disaster waiting to happen. The savvy amongst us kept our heads down and tried to avoid being dragged into the mire.

    1. Paul Crawford Silver badge

      Re: Continuious Development

      Here, hear!

      In my simplistic view, you have two major factors:

      1) having a clear, fixed and agreed idea of exactly what is needed.

      2) having the resources (i.e. people, tools) to deliver #1

      Most failures I have seen come down to at least one of these aspects. I have pulled out of work requests that I could see was a train wreak coming because foolish decisions had been made already due to not understanding #1, and then they were needing me for #2 when it was already an impossible task.

      1. Anonymous Coward
        Anonymous Coward

        Re: Continuious Development

        Time, cost, quality. Pick 2, or 1 in a lot of cases.

    2. Naselus

      Re: Continuious Development

      "Yes I have worked on many successful projects in the last 40+ years. This includes one for [Large UK City Gov Department] that came in on time and underbudget."

      Do you mean it was on time and under budget according to the estimates from the start of the project, or at the end? Because if it's the former, then I don't believe you. No UK gov IT contract has EVER been cheaper and faster than was quoted at the investigative stage.

  9. Individual #6/42

    Some project managers

    Non story. I recall one manager who could honestly state that after 10 years of his job he had never completed a project, let alone been able to claim one as a success. If a project is key to the survival of a company then screwing it up will always affect the company's long term viability. So what?

  10. Anonymous Coward
    Anonymous Coward

    Define "success". Looking back over 50 years what was delivered was what the customer requirement specified. That the customer occasionally decided to abandon it was their business/management decision. That didn't happen very often.

    What was not uncommon was that it took longer and cost more to produce a system than was originally estimated by the planners. Small experienced teams often hit the target - while the proverbial Chinese Army just racked up the costs deciding what shape table was needed for their meetings.

    1. David Knapman

      Yes, the definition of success is the tricky one to nail down. If it's "Did we deliver what the customer needed?", it's very different to "Did we deliver what the customer asked for?".

      1. Mark Honman

        To me, "success" is when the system is in use for 5+ years, "really good" is when it is successfully adapted to changing requirements during the maintenance phase.

        And what's really nice is to hear via the grapevine that when the system is eventually replaced that it was due to changing fashions in technology and that the end-users want it back.

        Projects that were delivered but could not be deployed due to business reasons (re-orgs, Marketing Menopause etc.) also count as successful.

Page:

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like