The worst software failures are successes

The worst software failures are successes

Summary: There is, I think, an inherent parallelism between the rigidity of the development process and the effect the application will have in use: i.e. the tighter the controls imposed during development, the more of a strangulation effect a successful release will have on downstream organizational flexibility and productivity.

SHARE:
TOPICS: Software
24

In the movies you know what's coming when the team leader suggests the group separate and some red shirt gets sent off to investigate a dark cellar by herself - and oddly enough IT project failure reviews are often exactly like going to that kind of movie.

Basically what happens as you go through the files and talk to the people is that the standard markers of doom - things like methodologists in controlling roles; strong separation between designers, developers, and users; or simply too many people pushing too many agendas - give you the same sense of impending doom you get from watching the pretty girl march down those steps by herself.

You'd think experienced IT people would know better, and many do - but if you're a developer or project manager just yelling "don't go there" when these warning signs pop up is a lot like yelling it in the movie theatre: you get in trouble with everyone else around, but nothing changes.

In response I generally try to get non IT management to learn from the on-going disaster so that they'll understand what they're seeing the next time something suicidely stupid, like separating the players in the interests of saving time, shows up in someone's IT project management strategy.

Unfortunately role separation is as basic to data processing as the waterfall model - and telling people that their entire methodological focus for project delivery is at the root of their failure to deliver projects usually produces a lot of hostility and the rather huffy assertion that most of their projects succeed just fine, thank you very much.

Unfortunately, I don't think it's true: on the contrary I believe that essentially all significant projects developed using rigid phase, and therefore role, separation fail the business - but in saying that claim that there are two very different kinds of failures. There are the obvious hard failures in which the project is cancelled, abandoned, or declared hugely successfull but never heard from again - and then there the really expensive ones: soft failures in which the project becomes an albatross hanging on user necks to impede them.

In other words, I'm prepared to argue that the worst software project failures from a business perspective are often considered successes by IT.

In this view, the worst of the worst are the ones that succeed at brilliantly doing the wrong thing.

Alberta Health, for example, went through at least three separate attempts to redevelop their original claims and registration systems, finally producing an outstanding success in the mid ninties - and locking the entire organization into an eighties style management structure that I'm guessing now costs the taxpayer well over a billion a year.

All of which leads me to propose a fundamental observation about software development: specifically, that there's an inherent parallelism between the rigidity of the development process and the effect the application will have in use: i.e. the tighter the controls imposed during development, the more of a strangulation effect a successful release will have on downstream organizational flexibility and productivity.

Topic: Software

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

24 comments
Log in or register to join the discussion
  • Isnt this was "agile" is all about avoiding?

    Another common cause of problems that you dont mention: The spec was right at the time it was captured, but the business has moved on by the time the system is delivered. Too many development teams think they are chisling a sculture from granite - in fact they're herding cats.

    I'm not a fan a methodologists too much either, but having a strategy or plan is essential. And a key part of any good plan is not only how you'll react to change, but also how you will find out about it.

    You need to get the level of inertia just right - too much and the project will be quickly irrelavant. Too little inertia, and you'll never finish.
    TheTruthisOutThere@...
    • re: your comment - yes, some truth in there

      Or, actually, quite a lot - and yes agile development methods (aka prototyping) address these problems.

      Note that agile coding by itself does not - but is applicable in situations other than normal business apps where role separation actually makes sense.
      murph_z
      • all I do is runtime environment and firmware.

        I toasted and closed one hundred and forty <.dll's>and<.inf's> most were ready for an apron using RFC and I/O based applications that have not yet been made available; or made offer to purchase.

        It hurts me too; cuz they are gone away in their little Sarcauphigus.
        rtirman37@...
      • There's more to agile than prototyping.

        Indeed there are are agile coding practices, and agile project management methodoligies, and I was more refering to the later.

        But all these methods suffer from the same problem: They are invented to address a specific problem, heralded as The One True Way, and over-applied by people who don't want to think for themselves or too inexperienced to know better.

        This is another manifestation of "MCSE-Syndrome". (Something else that suffers beyond breaking point from "MSCE-Syndrome" - UML)
        TheTruthisOutThere@...
        • Prototyping isn't really agile

          Many (most? all?) Agile methodologies call for very frequent production releases. When you release a piece of software for production use it is no longer a prototype.

          Calling it a prototype is a common excercise in self-delusion.
          Erik Engbrecht
          • Sure it is

            But bear in mind that I'm thinking of business apps - from what you write I suspect you're more likely thinking in terms of embedded and/or foundation (i.e. os/tools) apps.

            In a bus app - order entry for example - you release the prototype to production and treat production as the current prototype. Nothing's ever finished...
            murph_z
          • Then it's not a prototype anymore

            And embedded and systems software are ever finished?

            Hah!

            But yes, the validation and verification process for such software is sometimes much higher, because "release it and see what happens" is rarely a viable strategy.

            However, I'm making a semantic argument. I disagree with your usage of the work "prototype." You may do as you say with the software, but it is no longer a prototype. Calling it a prototype is playing word games.
            Erik Engbrecht
          • I guess it depends on what you mean by prototyping.

            We use agile methods, and use the word prototyping to describe (at least) the following activities.

            1) UI design, where screenshots are mocked-up in Photoshop (then printed and scrawled all over).

            2) Bits of code that are developed in isolation to solve a particular problem in various ways, prior to selecing one and then re-implementing in the main code base.

            3) Hand written code that forms one or more examples of planned output from a custom code generator.

            Prototyping is completely compatible with agile methods, so long as you focus on prototyping only those aspects of the system that will benefit from it.
            TheTruthisOutThere@...
          • Depends on your definition of Agile as well...

            I agree that your three points are prototyping, and are consistent with what I'll call "Agile values."

            I also agree that they can have tremendous value.

            But I've encountered "Agile" folks who are very much set on making releaseable software.

            Paul uses prototyping to mean something much broader. He basically labels any rapidly changing software as a prototype.
            Erik Engbrecht
          • Agreed.

            Words very often carry over into execution. If you call your software a prototype, people are going to slack off a bit - maybe the exception handling won't be complete, maybe corner cases not covered, or unit tests a bit thin.

            Make sure everyone knows what they're doing is for production, and you'll see a small but significant improvement in quality.

            I once worked somewhere with a really smarmy arrogant git employed as test lead. No-one wanted to give him the satisfaction of finding a bug, and code quality was way up!

            I would suggest avoiding hiring a gorgeous flirty blond as a tester (though in this industry, chance would be a fine thing)
            TheTruthisOutThere@...
        • Agreed (NT)

          :)
          murph_z
  • RE: The worst software failures are successes

    Especially if they have the Windows logo on the package.
    Userama
  • Brilliantly washing the feet of the Chairman and sending her or him away.

    For paper football season to begin and change out the vending machines for Yahoo's and Red Vines. Only wishing the Wagon Wheel Chuck Box from Circle Drive won't get caught on the assistant CIO's legend for this session. I hope it last longer than ten days; like the last one doing Administrative Tools for nothing/000000/mySQL.
    rtirman37@...
  • Never 100% SUCCESS (enforced).

    What I learned while running ITIL Problem Management actions was this - Legacy systems are NEVER improved. The second part of "Fire and Forget" keeps systems from ever evolving into something better. This of course goes against Dr. Demming's continual process improvement - which is proven to have cleaned the US auto companies clocks.

    ALL system shortcomings are handled by system admins. They have some latitude to change things, but usually not enough to make a 50 percent-er into a 99.9 percent-er. This of course adds to costs and validates the 90% of all projects costs are in the maintenance phase.

    This is where I believe that UNIX sysadmins shine. They can take crap and make it into gold. Typical MSCEs are stumped while projects grind to a halt.

    I guess in summary, I believe that a project can only achieve 50% success (max) from the planning to implementation stage. It takes re-engineering and great people to up the percentage in the maintenance phase.
    Roger Ramjet
    • Disagree

      While there are a lot of systems that sit out their without any official improvements after the initial development effort, there are also a lot that are continually improved.
      Erik Engbrecht
    • Make an app work

      My observation is limited to apps that connect to a database and is a generalization. There are exceptions to every rule.

      A developer's role should be limited to developing software; not desigining databases, stored procedures, etc.

      The first step in desigining a solution is to define and design the database. If the design is well thought out it will be scalable. It is fairly easy to create an app to a well designed database.
      High Plains
      • Yes - with one proviso

        What I find is that schemas rarely reflect reality the first couple of times out - so in a prototyping environment (where you sit with users and draw working screens accessing real data) you're forever having to adapt the schema.
        murph_z
    • Mostly agree

      and not that my software engineers are lazy. But the development style does affect the level of detail in the procedure documentation. If you don't set minimum standards, you get what you deserve, undocumented code.
      3dguru
  • ... during development?

    In these statements (quoting):

    ... and then there the really expensive ones: soft failures in which the project becomes an albatross hanging on user necks to impede them.

    ... the tighter the controls imposed during development, the more of a strangulation effect a successful release will have on downstream organizational flexibility and productivity.

    [End quote.]

    ... I think you're conflating the process of developing the software and the administrative structure or procedures inherent in how the software must be used.

    Isn't it possible the software can be developed as (what?) loosely as you like, but that the result can still be constricting?

    And if you are discussing the requirements made by the software, then isn't the time when the error is made well before anyone becomes concerned about code or what specifically the software produces?
    Anton Philidor
    • Yes - in part

      When you say:
      --
      Isn't it possible the software can be developed as (what?) loosely as you like, but that the result can still be constricting?
      --
      My answer is "yes" - but so what? my proposed lemma only applies to the constricted development case.

      If you want to think about causation in this process consider that getting users to sign off on requirements years before they get the software constrains them to avoid change both before and after delivery.
      murph_z