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 …

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

[Ken Hagan]

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

[smce]

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?

[Anonymous Coward]

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

[Steve Davies 3]

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.

[Anonymous Coward]

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

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

[Doctor Syntax]

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

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

[allthecoolshortnamesweretaken]

What took you so long?

[Trollslayer]

Happy customers

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

I must be unique according wossname.

[BongoJoe]

Re: Happy customers

I am unique in the same way as you then

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

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

[Doctor Syntax]

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.

[Ken Hagan]

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.

[glen waverley]

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.

[Red Bren]

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.

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

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

[Charles 9]

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.

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

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

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

[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!"

[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?

[Christian Berger]

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.

[Charles 9]

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?

[MonkeyCee]

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.

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

[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 :)

[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?

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

[Kevin McMurtrie]

<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?")

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

[Brian Allan 1]

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

[a_yank_lurker]

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.

[riparian zone]

just throwing it out there...

http://www.pretotyping.org/

[Anonymous Coward]

17% of 5,400

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

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