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 …

  1. Gordon 10 Silver badge
    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 Silver badge

      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?? Silver badge
        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. DougS Silver badge

            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 Silver badge

              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 Silver badge

          Re: Needs just a tweak.

          You've never built a house...

      2. Tom 38 Silver badge

        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 Silver badge

        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 Silver badge

          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. disgustedoftunbridgewells Silver badge

    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.

        1. Naselus

          "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."

          Dude, I have end-users who wanted to go back to Windows 2000 after we migrated them to XP. If users are used to something, they will ALWAYS want to go back to it, no matter how much better the replacement is; they would complain that they don't want 'not-syphilis' and everyone was perfectly happy back when they just had syphilis and lived with it.

    2. Ken Hagan Gold badge

      From a purely commercial viewpoint, break-even is where you make enough money to pay the development costs (and the rest of the company overheads over the period) so it isn't *too* far fetched to say that "success" is the 83% of projects that are not "so catastrophically bad they had threatened the very existence of the company".

      That's especially true if the company learned something along the way. What doesn't kill you makes you stronger and all that...

  11. smce
    Alien

    Looks like there a few leprechauns about. Both the claim on Royce's paper and general software failure rates are covered in Laurent Bossavit book: https://leanpub.com/leprechauns

    Perhaps the study is new. Have you checked to make sure it isn't flawed or generally nonsense?

  12. Anonymous Coward
    Anonymous Coward

    I've worked on Vista and I work on Windows 10, so I definitely know success when I see it: Linux.

    1. Steve Davies 3 Silver badge

      But... Linux isn't finished yet

      so how can you judge if it is a succes or not?

      so far it looks pretty good even if a lot of people hate Gnome-3 and systemd.

      just being a tad pedantic though becaise IMHO it is more finished than Windows 10 but my opinion isn't worth a fly swat.

      1. Anonymous Coward
        Anonymous Coward

        Re: But... Linux isn't finished yet

        Nor is any software. And Windows 10 isn't even on solids.

      2. Doctor Syntax Silver badge

        Re: But... Linux isn't finished yet

        Software development is the process of launching a product into the maintenance phase.

    2. allthecoolshortnamesweretaken Silver badge

      What took you so long?

  13. Trollslayer Silver badge

    Happy customers

    Had quite a few of those, that is a success.

    I must be unique according wossname.

    1. BongoJoe

      Re: Happy customers

      I am unique in the same way as you then

  14. Anonymous Coward
    Anonymous Coward

    Success is whatever you define it to be

    My company defines project success as not over budget and delivered on time. So every project is called a success, despite the utter, utter, shite that it delivered.

    The 10 releases after the official go live date to actually make it work without the user wanting to kill someone, are irrelevant. The project is over, wrapped up, and the PMs are busy in slapping each other on the back while drinking the champagne bought by the leftover budget.

    1. Anonymous Coward
      Anonymous Coward

      Re: Success is whatever you define it to be

      Ah yes, the "Deliver on time and fix in the next version" approach...

      It works better with a sloppy requirements spec. You deliver what the customer asked for, but that's not usually the same as what the customer wanted.

      1. Doctor Syntax Silver badge

        Re: Success is whatever you define it to be

        "You deliver what the customer asked for, but that's not usually the same as what the customer wanted."

        Which in turn isn't what they eventually discover they needed.

        1. Ken Hagan Gold badge

          Re: Success is whatever you define it to be

          "Which in turn isn't what they eventually discover they needed."

          But don't fret, because by the time they've worked this out, they need something else and they don't know that (yet) either. Rinse and repeat.

    2. glen waverley
      Facepalm

      Re: Success is whatever you define it to be

      I used to work in a very large organisation that did all its IT in-house. It was widely understood that the celebrations for getting a new product or an "enhancement" deployed *had* to be held about 9 am on release day.

      Because by morning tea time, the phones would be going crazy with fault reports and all the real workers on the dev team would be working on fixes. And all the project managers would be writing briefing papers on why productivity in the wider organisation was approaching zero.

    3. Red Bren
      FAIL

      Re: Success is whatever you define it to be

      Luxury!!! I've had employers who would redefine success as delivering half the requirements in twice the time originally estimated after spending multiples of the original budget, because the business sponsor was far too senior to have a "failure" on his CV.

  15. GeezaGaz

    Shiny new object/methodology syndrome

    As @kmac499 says its all about building something to a rigid fixed set of requirements.

    I've seen software development in 30 years go from waterfall, to DSDM/RAD (iterative prototyping) to now Agile (make it up as you go along).

    The bottom line is these methodologies lean more to the user than the developer, i.e. more and more freedom to start from a 'I've not a frickin clue what I want this system to do' standpoint which makes a nice easy life for the user and a pain in the arse for the developer.

    You start off with a sales person who says yes to everything (because they don't have the balls to tell the customer otherwise).

    To a project manager who says yes to everything (because they don't have the balls to tell the customer otherwise).

    To the devs who have to wear the shit and fit more in within the same time frame.

    1. FlossyThePig

      Re: Shiny new object/methodology syndrome

      If the project is High Profile, has "challenging" timescales and uses something new (hardware or software) it will fail.

    2. Charles 9 Silver badge

      Re: Shiny new object/methodology syndrome

      In other words, everyone wants everything yesterday and if you can't promise AND deliver that, they'll find someone else to chuck their money.

  16. Anonymous Coward
    Anonymous Coward

    Contractor's view

    I've been contracting as a software developer for the last decade plus and I hope I see more than my fair share of lemons (I think they were all lemons and I hope this isn't normal!). I think this is because anything that needs contract resources to implement it is already beyond the ken of the client or at least their permanent staff and thus already doomed before they even called me in. Or it could be me. Sorry about that.

    1. Anonymous Coward
      Anonymous Coward

      Re: Contractor's view

      I'm afraid it's you. Sorry to be the bearer of bad news, but your apology, albeit very late for some of us, is appreciated.

    2. Naselus

      Re: Contractor's view

      Yeah; it's you.

      Adding contractors late in the day increases costs and generally reduces the quality of the end result - not because you're crap at your job, but because while the other (also not-crap-at-their-jobs) developers were struggling to understand and deliver the customer's barely-legible request in 6 months, you have to digest it in 6 weeks AND learn an entirely unfamiliar, complex existing code structure in the same time period.

  17. Anonymous Coward
    Anonymous Coward

    Escher Waterfall

    Farley traced the sorry state of software development practices to a fundamental misreading of the 1970 Winston Royce paper (PDF) considered as a defining the waterfall method that has shaped traditional software development practices.

    “This paper was a description of what not to do,” said Farley.

    Ah... Farley is talking out of his anti-cakehole. I just read Royce's paper, and it says at the end :

    "Figure 10 summarizes the five steps that I feel necessary to transform a risky development process into one that will provide the desired product. I would emphasize that each item costs some additional sum of money. If the relatively simpler process without the five complexities described here would work successfully, then of course the additional money is not well spent. In, my experience, however, the simpler method has never worked on large software development efforts and the costs to recover far exceeded those required to finance the five-step process listed. ",

    it does not say "April Fool!"

  18. Mutton Jeff

    Isn't the world full of "successful" software projects? How else could I buy a gourmet plowman's from the Pret sarnie store across the way from my orifice?

  19. Christian Berger Silver badge

    Again I don't think it's methology

    The main problem is that most developers have not learned how to look at a problem, skin it down to its core and then implement that core in a way you need as little code as possible. Then you have a prototype you can test, modify or downright abandon and start all over again. Even if you abandon it you won't have lost much, as making such a prototype costs very little time, usually much less than trying to fudge around a badly designed system. Then if you have a core that works, you start hanging new features onto it. Often you will find that this gets much easier than your original proposal of having the feature in there in the first place.

    The most important aim in software development has to be the reduction of complexity. Try to keep your code as simple as possible, try to keep interfaces as clean and elegant as possible. Don't try to optimize unless it actually makes sense.

    1. Charles 9 Silver badge

      Re: Again I don't think it's methology

      Problem is, real world projects tend to carry the burden of necessary complexity. Suppose you have a project that has to to A which depends on B which depends on both C and D which both depend on E that in turn depends on A. You pretty much get caught in an all-or-nothing situation because of these interrelations, not to mention the increased demand for software security means you MUST take a look at the entire codebase due to the problem of "gestalt" security holes (as in greater than the sum of the parts) that only appear when all the pieces come together. Then you find the bug that requires a change to one piece that cascades onto all the rest.

      It's like my challenge to the UNIX program philosophy. How can you "Do One Thing And Do It Well" when your one thing depends on so many other things: not all of which you can expect to cooperate with you?

  20. MonkeyCee Silver badge

    Requirements engineering

    The oft quoted comparisons between physical and software projects, and what project planning/management tools can be used on them, and their efficacy is a fascinating area of study.

    The most common error (IMHO) is the utter shambles that is the requirements part of the project (for both types). It seems that a lot of people want to put a broad meaning but specific sounding terms in requirements, but will not commit to factual values. So saying "the system should respond to queries swiftly" versus "query processing should not take longer than x minutes". Then there are the "implicit" requirements that are expected but not actually expressed ("but shurly you knew that we must have solid gold toilets.....").

    That's assuming that the client has some idea of what they need. Or what they want. I wouldn't assume they would know how to solve it, but at least having a clear idea of what result you want in the end is good.

    The ever expanding project is another bugbear, usually political where project A has been approved, project B hasn't, so now A gets all of B's requirements added to it.

    I've had one project where I managed to get it broken down into five separate projects, and an overall "mesh them all together" project. Managed to get three of the sub projects done successfully (+20% budget, +30% time, delivered what the customer needed) the other two where completed to some level of success (+60-90% budget, +40% time, did what was asked, and some of what was needed). I then left, since the "mesh together" project had the end goal of reducing headcount from the various departments. That was still going 5+ years later.

    So remember, getting things to work that help people with their job, it's possible. Building something to put them out of a job, then you'll get blocked at every turn.

    1. Anonymous Coward
      Anonymous Coward

      Re: Requirements engineering

      I once worked on a large project, to parameterise, and standardise our products. Make them modular so new ones could be constructed out of the parts in a few hours to respond quickly to the markets.

      The original pilot was on one small part of the business, and I was in charge of the followup to extend it and roll it out everywhere else afterwards. I spent most of my time sat in on the pilot designs telling them not to make everything so specific to the business area they were targeting, because I'd have to rip it all out again and rebuild it from scratch if they did.

      The requirements are one part, but common sense is also needed, and can be surprisingly uncommon.

  21. ultimate_noobie

    I've spent most of the last ten years testing/verifying code and requirements and have to say that comparing physical to software is apples to oranges. The best programs understand what they A) need vs B) what they can do in X time frame and design requirements to which they can afford (usually B). I can pretty much tell you that if I hear the phrases "We reversed the requirements from the code" or "They're deferring the req issue" then it's a fail that didn't bother with A or B and has been coded like crap, to do something that at least 1 dev believed was what was supposed to be done because the others had no idea at all. Those always come in well over budget, probably on time for the last possible deadline due to throwing bodies and hope at the problem, and are counted as successes since the end customer accepted everything without a lawsuit. The best programs with the best chances have had strong requirements--don't misread that as "Great" or "spot-on", they always have at least a problem or ten--and managers who understand that getting a third person to actually just look everything over to ask "does this even make sense?" is actually a need for anything larger than a few hundred lines. So like 5% of everything I've ever worked on so that puts me outside the articles average :)

  22. Anonymous Coward
    Anonymous Coward

    I've been involved in several successful projects.

    Of course, they were projects where I was the designer, developer, and primary tester, and I had no external deadline or TPS reports to worry about.

    Maybe that's just a coincidence?

  23. Anonymous Coward
    Anonymous Coward

    Procurement

    Try using agile in major procurement when they want a full project plan, including their own testing. Even if they actually use agile the procurement team don't understand the benefits.

    On the opposite side business that promote agile often don't realise that the 'day 1' release is not the end of the project.

  24. Kevin McMurtrie Silver badge

    <ding> <dong> Do you have a monent?

    It's only a matter of time before Agile evangelists start going door to door to pass out literature in support of their local scrum master and Tuesday morning standup. They're preaching the same doom, gloom, and salvation story as traditional profiteers of religion. This abuse is a shame because Agile is useful when applied in moderation to the right kinds of projects. Absolute, unquestioning faith in any process is a sure way to go out of business. ("Can Jesus make a rock so big he can not lift it?" == "Can a company be so Agile that it can not adapt to new methodologies?")

  25. psmocko

    I don't know what planet this guy is from???

    I am sorry but almost all projects I have been involved in have been on time and successful. Even way before Agile was invented. Maybe due to the fact that I make sure it is successful due to good habits developed early on (and a good mentor) and just having the get it done attitude.

  26. Brian Allan 1

    Never had a project go totally titsup... But never had one come in on budget! Does this count!?

  27. a_yank_lurker Silver badge

    Buzzword Bingo

    Failure of software projects is very rarely due to the code wranglers being incompetent. The incompetence is much further up the food chain with very stupid PHB decisions compounded by horrible specs that are impossible to decipher being the primary culprits. There is no good methodology that stops stupid.

    I know of a current project where a PHB decided to use a completely proprietary language. My comment was that was disaster waiting to happen because there will be virtually no developers who know the language on the street.

  28. riparian zone

    just throwing it out there...

    http://www.pretotyping.org/

  29. Anonymous Coward
    Anonymous Coward

    17% of 5,400

    Makes sense. That's about the number of projects I've been involved on.

  30. erhumdm

    Has anyone seen ...

    A functional requirements spec that stood the test of time ... i.e. that which is described actually met the long terms needs of the business? The real challenge is that most business managers want certainty ... yet they expect those developing software to a) be telepathic, b) omnipresent and c) able to predict the future accurately. If you said to an airplane engineer that you wanted to upt a full length swimming pool in a plane and have it takeoff, fly and land ... he/she would tell you it's impossible. Yet with sw, we'd start wittering on about resources and time and money.

    These are typically "wicked" problems. Everything evolves - the perception of the problem to be solved, the approaches to solving it, the end result (if there is such a thing) ... all of these evolve throughout virtually every sw project I have seen. And we all know there is no such thing as a small change in software. Yet we continue to delude ourselves and the businesses that we work for that we're 95% done.

    But don't get me started on started on McK's self-serving surveys. They're all designed with one thing in mind - selling their consulting services. You can drive a bus through them when you look hard (assuming you can find the actual reports rather than the multiple references to them). Like 90% of all stats, they're made up on the spot.

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

Biting the hand that feeds IT © 1998–2019