The Standish Group is an organization that has been studying and reporting on software projects for many years. In 1995, it reported that only 16.2% of software projects succeeded. In large companies, the number was only 8%. That is, these projects were on time and on budget. In 2012, there is some improvement. The 2012 report discusses waterfall projects and agile projects. A summary of the success stats demonstrates that agile projects do improve things across the board. That’s not surprising given that the 1995 report cited lack of stakeholder involvement and incomplete requirements as the top two contributing factors. Agile principles address both of those.
The 2012 report is still fairly damning of the industry as a whole. It cites 12% success rate for waterfall projects and 42% success rates for agile projects. Firms like Headspring, with a 95% success rate, have embraced agile, of course, but there is still so much more to be desired by the track record of the industry. In 2012, 9% of agile projects still out-right fail, and 49% are “challenged”. i.e. they unacceptably ran over budget and/or over schedule – either can have significant impacts on the business.
The industry even pokes fun at itself in a famous Internet meme, “If cars were like software” where we see that we have much more reasonable expectations of our automobiles than we do of software and the people who make software. Somehow, the software vendors/programmers have set the expectations of paying customers (and executives) so low that they celebrate the smallest successes even in the face of massive budget overruns and late launches.
This is not acceptable! Software people don’t get it. Programmers have been writing mission-critical business systems for decades. The newness is gone. The trial period of “we’re figuring out how to do this” is well over. Now is the time when paying customers must demand more from programmers.
As an executive of a software engineering firm, I see the perspective of our clients. They have a business that is pushing forward in their industries. They have a really old information system that must be revamped in order to take advantage of changes in the industry. Or they need some automation for a brand new market offering. The success of the business initiative rides on many factors, software being one of them. They cannot afford to gamble with a failed $1M (or more) project. Besides the money, once the project calendar has come and gone, you can’t get those months back. Whether you hire a firm, do it in-house, or hire contractors in India, a failed project by any cause could mean the end of the career by the manager in charge of the product or initiative. And it doesn’t have to be this way.
Right now, across the industry, clients are forced to literally gamble with their capital investments and time. With less than 50% of projects (even the new and improved agile variety) succeeding, clients many times have no recourse but to gamble. The smooth-talking sales personnel do their bonding and rapport. Then comes the confidence building. Then the project plan and schedule – all works of fiction. And don’t forget the budget, which magically covers the time period the project plan lays out. Once the project gets started, the software engineers work for a while – hold meetings according to their agile process – track burn-downs, measure lots of agile numbers – then what comes out the other end is your 42% chance of succeeding.
In order to increase the pitiful industry track record, software engineers need to change. And when saying “software engineers”, I’m referring to any person responsible for delivering software. Some companies have a plethora of titles and segmentation of specialty, but it’s all software engineering (i.e. software engineering includes leadership). The bed of education and training currently in place does not produce the results that clients demand. I hope to elaborate more on this soon.
Yes, blame the programmers! It’s certainly not the failings of the executive who come up with utterly crazy ideas. It’s definitely not the sales guys who promise the moon. There’s no way we can blame a complete and utter lack of TRUE requirements which we really don’t have a budget to gather or analyze. Hey, the client said make it work on all current and future browers, mobile devices and O/Ses. Scope creep is never the issue. No, it all rests on the squarely on the shoulders of those darn programmers! They just aren’t edumacated enough. Well partner, maybe, just maybe we will be able to take Headspring training courses and reach a 95% success rate too! Or if our dumb ole developers can’t get it, let’s just hire headspring!!!
+1 with a little “Marketing” thrown in on top of the execs.
Hey Blake,
First, a full disclosure: I’m a Headspring employee.
With that said, I understand your frustration with this issue. I get really frustrated myself. From what you wrote it’s clear that you already thought a lot about the lack of success in our industry and tried to identify the causes and possible solutions.
I agree with a lot of the problems you mentioned: sales over-promising lack of good requirements, budget constraints, unreal expectations. The part that I don’t agree is that Jeffrey was trying to “blame the programmers”. What I got from his post is that the entire software industry is to blame – not programmers exclusively, and it’s on us, software people, to fix it.
I also understand that you saw Jeffrey’s post as a pitch to sell more training seats. But, honestly, I don’t see the post that way nor I believe that was Jeffrey’s intention. Yes, Headspring has a 95% success rate. But that’s not only because Headspring has great programmers. There are lots of awesome, really smart programmers on our industry. I don’t believe lack of proper developer training is the root cause of our problems.
Going back to the issues that you mentioned, while some of those problems are just the reality of doing business, e.g. budget constraints, most of the other issues can be mitigated by transparency, setting expectations upfront and avoiding surprises. And this is what we have been doing at Headspring and what I believe Jeffrey will later elaborate on. Avoiding surprises and constantly setting realistic expectations with customers is what lead us to the success rate we got.
Best, Pedro Reys
Wow, what a condesending self promoting reply this is.
I feel the term “Software engineers” has been intentionally vaguely defined as “any person responsible for delivering software” to spur controvesy amongst the readers in an attempt to promote a future article*.
By any common defintion “Software engineers” refers to developers and analysts and testers. It does not include Marketing, Sales and Management.
As also Alexander points out, then biggest problem is overpromising (and understating complexity, which is very closely related) and the unwillingnes to state the actual cost of something in advance. The fear is that if you do tell the truth, you are considered too expensive and you will not get the bid.
None of this is the “engineers” task or fault or should be considered ‘part of the business’.
(*) which is a really a dirty trick:
“I blame you and maybe in the future I will explain why, please keep comming back to see if I felt like it.”
The part “Now is the time when paying customers must demand more from programmers. ” is explicit enough that the author blames the programmers and not the software industry.
I agree! it is black on white rigth there
so I’m also amon the ones who dont think they got it wrong 
“I feel the term “Software engineers” has been intentionally vaguely defined as “any person responsible for delivering software” ”
it is to justify employing more than probably 50% of Headspring employees.
I think the biggest problem of our industry is overpromising. It took me a long time to realize it’s better to be clear about how the dev process works, and that you simply don’t KNOW whether something is possible yet without research into it, than saying “I think I can do it” and run into problems later.
I personally always try help the people that ask me as good as I can, both as support technician and programmer, and my biggest downfall was that I tried promising things I couldn’t make true in the end, or with a big chunk of extra time needed. Managers and sales guys can be really annoying; understandably, they have to tell THEIR employers what’s up in the development process and where we are. But if you give in and avoid disappointing them now, you will only disappoing them more later.
I’ll agree with you on the over promising. I have yet to meet a salesman who lets reality cloud his mind in pursuit of his commission. If the project fails, it had nothing to do with him. I’ve had software estimates cut to nothing because they were invisible compared to the hardware that was being sold. “We’ll make it up in volume” for one shot projects.
Addressing the original article, we do NOT know how to program computers yet. I had an accountant ask me once why software took so long and was prone to errors. Hadn’t all the problems been solved yet? I asked him “Who programmed cellphones before they existed?” As I said that I realized his industry has been with us since the dawn of civilization, accounting of grain bins may have been a driving force in the creation of writing. I pointed out that we have been building bridges for thousands of years and we still get it wrong. Programming is barely fifty years old.
Philosophical rant: The problem with computers and humans is that they’re computers and humans. Humans think in error-prone, subjective, nonprecise, nonlinear ways, and computers do the exact opposite. A computer works best if you supply it with a linear binary that only leads to one objective conclusion based on one objective input, whereafter the execution ends, or restarts. and giving it the same input would give the same answers, unlike with humans, that may have changed ‘their views’ on things. File systems with folder structures and logically named files; input devices that map a set of keys to a set of numbers (i.e keyboards, mice, etc); pluggable user-replacable hardware components; they’re all just parts to cope with how humans are different than computers. Hell, if we’d live a computer controlled world, we’d probably immediately stop existing because there’s no motivation, no bigger servable goal, that would set a computer to come up with an answer to reach that goal.
Computers are problem solvers, Humans are idea makers. “IT Staff” (be it programmers, engineers, or otherwise) are the part that clicks those together so they understand eachother.
>>In order to increase the pitiful industry track record, software engineers need to change.
Thanks for calling us out. Possibly is it that leadership needs to change? You are missing all of the times that non technical people have put together project plans with minimal input from the people building it (those software engineers who need to change). I think what needs to change is that business people need to recognize that they don’t get anything done without software these days, and as such should include from the very beginning the software architects/engineers/developers and also should think about what it means to run a piece of software in production.
As a guy who is an executive of a software engineering firm, I am surprised you would throw out a bomb like that!
Now, don’t get me wrong, there are plenty of times that a software engineer needs to change so they become a more productive member of a team, but come on, your statement at the end makes it sound like all of the planning up front has been perfect and that it is the technical team that consistently fails the project plan.
Is this your first “Big Play” after getting that Jack Welch MBA?
Say hi to your buddy Jimmy Bogard for me.
Thanks for the comment. I’m not attempting to focus on technical people at all. It’s a team effort to deliver software, and as a group, as an industry, we have a track record that leaves a lot to be desired. I do plan on sharing what I believe, are the key reasons we’ve been able to do better than the industry. Not to sell, but to share.
Jeff,
I don’t mind if you are selling things, I would expect it. Headspring is a business after all. It is the singling out of software engineers in your post that is the disappointing part. If your comment to my comment…
>>It’s a team effort to deliver software, and as a group, as an industry, we >>have a track record that leaves a lot to be desired
Is really what you think, then I believe you should edit your post to reflect that.
-Ben
Any metaphor that is related to manufacturing is wrong or bad. It´s more about people than anything else.
Think of it as an artist´s interpretation to solving a problem, particular to that group or company.
A software developer has a bunch of tools at his/her disposal just like a painter has brushes and ink. The output is always different, because it´s unique, custom, depending on so many variables. It´s empirical, the work changes during it´s making. The initial elaborations mean less and less as it goes to completion…
Then you realize custom software is never done. So you stop, release, and keep improving.
Want cheaper, repeatable, never changing? Buy a picture, copy it thousands of times.
Jeff,
I agree with Ben’s comments, but would like to add that there really is no one place that projects “Fail”. If the production team (developers) fail, then it’s likely due to poor or mis management. If a developer is doing a poor job, management should recognize that and replace that person. Problems also come from lack of analysis, vague instructions (requirements), and lack of structure within the project. Your post doesn’t delve into the fact that everyone on the team is responsible for making their part succeed. Retraining developers as a solution? I hardly think that’s even near the top of the list of problems that make projects fail. Coordination of the cats (ala herding cats) is often the source of failure, which is probably why your company has a high “success” rate. It seems in your case that your company is good at management, given the stated numbers
I too think you should edit your post. No one group can be singled out to solve the problem. Rather ensuring that everyone understands their roles and expectations is important, including stakeholders, project managers, business owners, and yes, production staff (analysts, developers, etc.). But if developers aren’t making the decisions, they can hardly be held solely accountable.
Still, you fail to understand one simple thing: we’re all in the same bucket. You may do things right at your company, but will still be confronted with unrealistic expectations, because the vast majority of software development does not create realistic expectations on the customer side. And this happens in most cases due to people having nothing in common with software. Yet your article is aimed at software people. Could it be that you’re barking at the wrong tree?
Hi Ben,
Full disclosure: I too am a Headspring employee.
I understand your frustrations with incompetent project managers, questionable decisions made by leadership, and lack of inclusion of the technical staff. In the past I too have gotten frustrated over these exact issues you’ve pointed out. I can remember thinking not too long ago, “If only I had a project manager who’s actually written code outside of college, life would be better. Software would be planned perfectly, no more death marches, and scope creep would be a thing of the past”
Working at Headspring has been a blessing for me. Before I worked here I used to think that the key to delivering great working software rested solely in my hard technical skills. The surprising thing I’ve learned since working at Headspring is that, while yes technical skill matter, the difference maker is the soft skills of client interaction, setting proper expectations and having open and honest comunication with your customers that is key to a successful project.
so do you communicate with customers and how often?
Pip, to quickly answer your question, it depends on the client. For some it’s daily, others it’s weekly. Do you mind if I ask, what frequency do you communicate with your customers and would you rather it be more or less?
absolutely less, especially if we get close to a deadline.
then they become un-bearable, want all the major changes at the end 
unless I’m contractor/consultant, do not see why i should be involved in indulging customers itches (aka flirting).
u cant honestly expect me to believe you are developer, yet you are buried in communication with clients every day.
either you are developer or not! once you have a clear understanding of you client needs and expectation it is your job to design and deliver.
following a very simple principle (from other industries too):
I can deliver:
cheap
fast
good-quality
pick 2 of these!
your customer is not a sick person you attend every day and you should not be a moron to call him everyday to ask question, bby some time you should have a very clear picture (big picture) in your head.
so along TDD and keep client involed, are things I do not believe in the hype machine Agile. considering the fact most of the principles involved are in sharp contrast of what an agile means.
what I have seen in the past few years is that the quality of soft-production is dramatically degraded. WHY? because developers are turned into clerks and the lack of any leadership from management/PM who are convinced by the Agile Cult that somehow because the do that .. everything will be OK. bottom line, no one pays attention to the code!
Agile is not th e first and not the last methodology which will hype-off in couple of years, replaced by yet bigger non-sense, where the truth is one:
there is huge difference in the level of competence among developers and is not correlated to education or industry experience.
giving a job to 1 skillful dev for 1 year is better than giving it to 5 for 3 moths !
When I say “software people”, and “software engineers”, I’m referring to all of the people who work to provide software. Some companies have just coders. Some have layers of project managers. Regardless, the software people, whose job it is to provide software, don’t have a good track record. And, no, we actually don’t provide any training classes geared toward making your own projects more successful – we only sell technical training at the moment (which is not one of the reasons Standish cites in its report).
Technical skills are so far from this discussion. The root of this is leadership.
Then say leadership. What you are doing is trying to stir up a hornets nest. Say leadership, not in the comments but in the article. Also, leadership and management are not software engineers. Nice try. I will never recommend or use your company after this article. I don’t really like dishonesty.
I think the majority of us are in agreement. It is people like you who are the problem.
The last paragraph of the article:
“In order to increase the pitiful industry track record, software engineers need to change. And when saying “software engineers”, I’m referring to any person responsible for delivering software. Some companies have a plethora of titles and segmentation of specialty, but it’s all software engineering (i.e. software engineering includes leadership). The bed of education and training currently in place does not produce the results that clients demand. I hope to elaborate more on this soon.”
“In order to increase the pitiful industry track record, software engineers need to change.”
To me, this statement at the end implies that software engineers are the biggest factor for the pitiful industry track record.
As a software engineer, I recognize my bias, however will the track record be greatly improved just by retraining software developers? I think not.
This article is not very useful. You’re attacking software engineers, when most projects I’ve been involved with fail due to management, and even then it’s for different reasons. To paraphrase Tolstoy, “Successful projects are all alike, every failed project fails in it’s own way.”
I’d be more interested in your experiences of massive project failures. I’m not talking an overrun of a month, I’m talking the Massive Death March failure where 2 years of work by 200 individuals is thrown out because it doesn’t work. What happened, and why did it go wrong?
And I wonder what would be the answer from those manager, upon whom you are blaming the failure.
Yes, we should never blame managers for project failures. It’s always the guys doing the work, not the guys in charge of scope, schedule and strategy.
Guys, don’t take it serious, after all it just another
marketing post. It is not any research output.
+1 Blake
He does start out by citing reports and figures in an attempt to give his opinions in the second part any weight.
That’s what all marketers/salespeople do – they know people don’t believe what they’re saying, so they try to convince you with other people’s words.
Well Jeffrey, you’ve stirred up a nice S*** Storm.
Everyone has already jumped on you for saying “Software People” don’t get it, assuming that meant “Software Engineers” (a term i hate…we’re not engineers!) which I guess isn’t really what you meant. So even though I’m a Software Developer and Manager, I won’t add to that chorus and give you the benefit of the doubt.
Still to me its not that the “Software People” don’t get it. Its the “Business People” whether thats an internal or external client. They want fixed budget, fixed timeline and fixed scope. They ALL want that and understandably so. We all want predictability, especially when our money/business is on the line. You used the metaphor of the car. Well, that is a terrible metaphor. We’re not building cars. We’re DESIGNING them. Software is actually an R&D project, not a construction or manufacturing project. For years we’ve labored under these faulty metaphors of construction, architecting, engineering, building, etc. None of these really work for software. What we need to do is get businesses to understand that when they undertake to have custom software built, what they are really asking for is not a construction project, but an R&D project. How long and how much money did Honda spend to create their most recent 2012 Accord model? Was that fixed bid? Could they predict ahead of time, how much they were going to spend on that R&D project, how much time it would take and what new features the 2012 honda accord would have? I would bet not. If you compare and R&D project like designing a new Honda or a new iPhone and compare it to the time and costs of a software R&D project (i.e. ALL CUSTOM SOFTWARE projects are R&D) software is a GREAT deal. And mistakes don’t require a recall, just a deployment.
Unfortunately, explaining this to clients is nearly impossible, partly because of the faulty advertising and bad metaphors of the software industry itself, partly because of who we are selling our services to. Clients sell widgets, they sell their widgets for X dollars every time and thats it. If they themselves are in a non-predictable business or industry, which includes lawyers, doctors, artists, etc they charge hourly for their services and make no guarantees of success. Take it or leave it. Yet we’re supposed to guarantee success even though they do not. Even a plumber or an electrical engineer gives an estimate for fixing or adding something to your house, not a guarantee.
I’m skeptical of your 95% success rate. I have no doubt you do good work. I have taken one of your classes and I have a lot of respect for you and your company. However, I suspect that while you mentioned Time and Budget, you left the 3rd line of the iron triangle vague on purpose. I suspect that when time and budget start slipping, which they inevitably do since developers are terrible at estimating, you renegotiate on scope. That too is the agile way. Its great if you can find awesome clients like Dell that will buy into the agile way, but many of us out in the real world still have clients (again, whether internal or external) that want fixed bid, time and scope. Agile can improve things, but I have found that for most businesses, no matter how much you communicate that requirements need to be flexible, that you charge hourly for time spent, that adding things increases time and costs, at the end of the day they still expect to be billed exactly X dollars after X months for their exact scope, even if that scope exists entirely in their own minds.
Uh…not that i’m bitter.
I’d like to add, that I do agree that we as “Software People” have a lot of improvements to make, but I think there are some things that just make this industry inherently difficult and hard to explain to those outsiders.
Agreed that the car metaphor is a really bad one. I can’t go to a car manufacturer and order a car based on my requirements let alone having them commit to a specific budget and deadline. Yet in programming we’re asked to do exactly this: build brand new custom software with blurry requirements and within a solid timeframe/budget.
for Christ. they still ship these 4wheel cants with CD-audio on board with no USB! costing 50K$
What a joke! If truly there were a bit of innovation in car manufacturing:
1) we wouldn’t run on medieval oil engines
2) commute to the Moon on daily basis
then I can consider car manufacturing any close~!
fregas, excellent reply. thank you. Palermo is seriously delusional. I’ve been a part of successful projects, and also failed projects. Both outcomes were dependent on the quality of management and/or realistic client demands, and not the competency or efforts of the developers.
I don’t think he’s being delusional, and I DO think the competency and efforts of the developers plays a role. I have met a lot of really bad developers and I’m sure you have too. We have a lot to improve upon in our industry (education in patterns, solid principles, db techniques, soft skills, requirements gathering) so I agree with him there. But I think there are hard realities that can’t be ignored. His message seems to be “We at Headspring KNOW how to do it right…the rest of you don’t.” Its not that simple.
IMO/IME a good manager (one with a lot of hands-on coding experience) can deliver a good product (deliver a feature-complete product within time and budget, that is) with any team except a bunch of monkeys, provided the estimates he provides aren’t modified by salespeople or higher-ranking managers.
You adapt your choice and usage of technology to the people you have. Skills in our business are like tools in other businesses – our basic tool is our brain, not the IDE, framework, library or whatever. If you don’t have some skills required for a certain setup of the project, you go with something you have the skills (= tools) for. Of course, this can mean a changed schedule or budget. But that’s exactly the kind of juggling I’d expect a skillful manager to be able to do, and to get right.
Absolutely!
A bad/weak programmer is one thing! Relying on him for decision making is another. Unless all the teams are bad, you can pro-activly react on the situation in order to compensate for it. However, in case your PM is the weak-link ?
BTW whether a software project is successful is not necessary correlated with how good devs are but in fact how bad they are in many cases.
Case Study: I used to work for a company, which was making about 3x more money from supporting crappy projects they have built for 1x at the first place. That’s what happens when none of the stakeholders is anything close to technically literate.
Actually, the business people want a fixed budget and schedule, and an infinitely variable (upward) scope.
ha yes, thats often the case as well!
Absolutely rubbish, link-bait article. The number one reason for the failure of software projects is poor management, be it through over-ambitious goals, feature creep, or (most likely), under-investment.
And the idea that the software world is a mature one with all the problems worked out and solved is rubbish. Programming languages, tools, hardware and design patterns are changing all the time. We’ve haven’t figured it all out yet because it’s a moving target. Look at recent re-focus on mobile computing, the concurrency debate, the radically expanding scope of graphics hardware, the AppStore(s), opensource, changes in, the rise of declarative languages, the web, social media etc etc.
This industry is changing all the time. It’s completely wrong to compare it to car manufacture or the building industry or to place the blame on software developers managed by people who are still laboring under old-world product concepts.
I run a successful software company. We have many software engineers. In fact from sales through to development we have all been software people or had software training at some point. This really helps as every step of the chain understands software related issues which helps educate our clients. I think this post damages the industry. It’s the process that fails. It’s people ignoring the process and making unrealistic demands, this can be the client or an exec who “doesn’t get it” and wants to make a quick buck. A successful software project desperately depends on a two way trust based relationship with all parties. Wagging fingers and making demands makes the whole process fall down.
I couldn’t agree more. There is no one solution to the problem, but perhaps part of the problem is how success is measured. If you come up with numbers, timeframes, and such before one even knows the difficulties (ala spreadsheet example above) how can you hold that a project is unsuccessful if some unforseen problem (Murphy) pops up adding to the timeline. Is it the fault of the developer that the person creating the timeline didn’t put in buffer for such things? Is it the fault of the developer if the person creating the budget doesn’t know about DDE? We developers run up against unforseen difficulties all the time. It’s inherent in creation that you’ll run up against something unknown.
To my mind one solution may be to change the definition of success such that it allows for all parties to agree to changes in the success conditions when necessary to accommodate Murphy. (Not to promote scope creep.) I just think you can’t always fully define success up-front unless you define a way to be successful in the face of issues that cannot be accommodated within the original plan.
For the record, I have never worked on a project where the time and budget estimates of the engineers were accepted by the client. Typically the project would come in close to the technical estimates, but significantly outside the limits imposed by the client before they would give the project the go-ahead. So: failure to deliver, or failure to accept the cost of software?
more like uptake. Some really good softwares hit the ‘take the money and run’ scenario- ie. Numera Visual Cad- got developed to the point of 3D SDK and sold to Corel-nowsemi-stuck in a marketing engine. Same with a lot of proprietary stuff- small companies bought up to gain market share- ie Mitek buying Tee-Lok and shelving LayoutOne (fully parametric object modele 3D) for Sapphire development (peiced together to maintain data streams from business modeling to jig setups- semiparametric 2D work/3D veiw modeling). Sapphre reporting capabilities being far more developed. The target industry connector plates for engineered trusses- the price of steel in connector plates and lumber supply chains. Much better solid modeling engine basically lost in the shuffle.
to live with Peachtree instead is not a hard decision to make business wise?
> “we’re figuring out how to do this” is well over
Unfortunately it’s not true for the 90% of programmers. They are stupid! Young and old, educated and self-educated, they came to IT industry for money. They think too tide and blind that DECADES must pass to study ‘em “how it had to be done properly”. Mediocres – that is key for all your sh*** systems. Never hire stupids to organise architecture! Double, triple check architecture before you implement it. Once you greedy on that analysis, prepare to throw away all your code.
software and IT hardware are unique in many respects (or certainly part of a small subset of human endeavours that are highly complex, rapidly evolving / birfurcating technology and the ability for an individual or small group to disrupt an industry)
However, most of the issues that software projects face are the same as any other project in any field of human activity and they fail all the time. They fail to meet budget, they fail to meet schedule, they fail to meet quality ,usability and often fail to be relevant.
The usual culprits are politics, ego, lack of management ability, unrealistic expectations, crazy marketing plans and lack of understanding of peoples needs. Sometimes, somebody, somewhere else makes your work redundant before its complete.
Given this propensity for project failure combined with the difficulties in the field its astounding that anything succeeds in our field. Its probably due to the outstanding efforts, creativity and inquisitiveness of designers/ developers and engineers. There is no other industry where you get so many hours of so much brian power poured into projects.
Now if we could just put all that effort toward a few worthwhile projects, use some standards, really engineer products … and tell the hardware vendors, marketing, managers and egos to go shove it … what a wonderful world it would be …
damn I forgot the accountants .. .I knew somebody would stop me.
You couldn’t be more wrong.
My Grandfather was a distinguished geologist, a F.R.S in fact. During his adult life the corpus of geological knowledge grew steadily, but quite slowly, so over his career he was able to absorb and master his field of knowledge far faster than it grew, which is how he early on in his career became master of his game. I am a software engineer of some 35 years experience and the field of knowledge I am attempting to absorb is constantly changing and growing rapidly, the tools I have to work with (my pick and shovel) are constantly being replaced with ones that work diferently, and I can also say that I am almost always trying to solve some problem I have never solved before.
The thing that needs to change is for software engineers to truly master their field. For this utopia to arrive, the rate of change has to slow considerably. Until then those who claim that software engineers are to blame simply display their ignorance of the problem.
And, even while the field of knowledge is changing faster, companies are less willing to provide any training on these new languages/tools/frameworks/methodologies. The prevailing management attitude today seems to be any competent software engineer should be able to master anything in 15 minutes by looking it up on Google …
You make some good points but what do you do to change things to get to close to 100%. Don’t just tell a problem lots of people know give solutions people can use.
fregas: …assuming that meant “Software Engineers” (a term i hate…we’re not engineers!)…
Well you should be. Engineering is a discipline, it embodies a certain approach to the work whatever the field. If more software developers were engineers too there would be less sloppy code, more and better outcomes, and perhaps fewer articles like this one venting frustration at the profession.
I agree on the discipline part but prefer the term “Software Craftsman” to engineer. Engineers deal with hard limitations based on physics and science. Software developers do not. Its mostly a matter of empathy for the developer after you, readability, simplicity, DRY, etc.
Reply To Neil Haughton’s: “If more software developers were engineers too there would be less sloppy code, more and better outcomes…” Ha! Ha! In all my years as a “Software Engineer”, the worst programming offenders were actually Engineers. And by Engineers I mean, electrical, mechanical, etc. In my opinion, it is not their fault, as these people are place by management to do something that is generally outside of their scope. After all these people are applied physicist and not software crafters.
You obviously have no idea about what software developers go through. We’re not simply doing the same thing over and over again, enabling us to be experts. We’re not working with the same technologies all the time. We’re constantly faced with problems that we’ve never dealt with before.
A customer would say, I want an application that’s going to monitor an Excel spreadsheet, then place an order on the stock market. That’s pretty simple he’d think, it’s should take no more than a day or two. Except the data in the spreadsheet is updated using DDE, which doesn’t trigger the cell changed event. How do I get the the data? Create a timer and loop through looking for changes? How do I validate the data? The client can’t give me definitive rules. What about this scenario or that?
Stuff like this happens all the time, and then the developer is blamed. If it was as black and white as you think it is, then you’d be a developer.
I appreciate the comment. I am a software developer, and that’s what frustrates me about our industry. I agree with all the reasons why there are problems, and I have experienced every problem for myself. As an industry, though, we must figure out how to improve the track record. And we can’t expect our customers to change, really.
Steve is right! It takes a team including customer, marketing, executives, management, and engineering to tune in to reality. Software design and development is a human event. It is a very complicated and dynamic environment. It is the team that makes success. Not some special tool or hero. Certainly the correct tools help and talented individuals are required, the team to deal with the successes and failures to reach goals is very important.
It is a fallacy to think that the business world is fixed, mature and precise and software folks just can’t seem to get with the program. Truth is, businesses are still trying to figure out the Information Age and evolve accordingly. Two rapidly changing platforms that outdated notions and assumptions will not effectively manage. Stating that ‘agile projects’ have a higher success rate because they are more often done on time and under budget is about all the typical executive needs to hear to think the solution is just to make his software folks ‘do agile’ and neglect the business transformations that need to occur as well.
Mr. Palermo,
I assume you know how to put together a jigsaw puzzle, for nearly any 3 year old can put together the most basic ones.
So let me ask you a question. If I went out and bought 5 jigsaw puzzles, each with say 2,500 interlocking pieces, how long would it take you to put together anyone of them?
Can you tell me within 25% of the actual time how long it will take you? After all, you DO know how to put together a puzzle, right? And it you can do that, can you tell me what day you’ll have all 5 of them finished?
I want to know! And can you have your reply ready for me by 3pm today?
Cheers,
Karl
Excellent reply! Makes the point clearly.
I’ve been in search of an analogy like this for some time now. My search is over! Thank you Karl.
and software is far more complicated then a jigsaw puzzle.
“Hey Jeff… thaaaanks for getting me that estimate on man hours. Look… you know I’m not a bad guy, but things are tight right now. The timeline to full complete just isn’t going to work for the stakeholders, and two are really really heavy hitters, so tell you what. Let’s say you can get it done in two days instead of 5, and we’ll touch base tomorrow and you can give me an update on your progress. There’s a bonus in it for me if you can do it, and a poor performance review for you if you can’t! Also, will the project I gave you yesterday be done by tonight?”
This is by far the best comparison to software development in the case of time estimation I’ve ever heard, I’m gonna use this one if you don’t mind!
And also, I’d like those pieces that contain red to be painted blue. I’m sure it won’t affect your estimate. And no, I’m not sure how many contain red. Oh, and while you’re at it, can you find a way to recreate the missing pieces and give me a report about that? Tomorrow would be fine.
Your article is ludicrous. My father built cars, I build software. The way in which these things are built are nothing alike. Software success depends upon talented, highly skilled developers. Builiding a car on an assembly line requires neither talent nor highly developed skills. Also, when a new model car is manufactured, the a car factory will often shut down and re-tool before launching the new models. Once re-tooling is done, you can’t stop midway and decide that you want to build pickup trucks instead of sedans, which is often the case in software development. The reason so many software projects fail is because ultimately the client doesn’t really understand their own business well enough to have it translated into code. I can’t tell you how many projects that I’ve done where I had to define the business processes for the client and they decided to accept my suggested processes.
I’ve had bugs about slow performing queries, I analyse the queries, figure out what is causing the slowness, get a query that produces the same answer in 5% of the original time. Then fail in code review because I didn’t use a new table, that doesn’t have the information I need to provide the information needed and wasn’t mentioned at all before code review. I get released because I refuse to use a table that doesn’t provide the information I need. Yea, politics has nothing to do with delivering software.
Software is more like finding Easter eggs than a picture puzzle. Quick tell me how long it will take to find all the Easter eggs! How many eggs are there? No clue. How well are they hidden. No clue! Let’s confine the problem, how many states are the eggs hidden in? I don’t know, you’re the technical guy. Bugs are Easter eggs. HOW LONG WILL IT TAKE? How long does it take to invent some undefined number of new things? The problem isn’t programmers, it is inane management pulling a schedule and budget out of, well let’s keep it clean and say thin air, and thereafter treating them as gospel. Either keep to a schedule that I’ve imagined, or YOU fail. My own schedule and budget don’t stink, your programming is horrible.
I feel very sorry for the engineers that work in your company. You obviously are clueless about software development. It may be one of the most complex thought processes humans attempt to make. I have worked on multiple projects that have more than a million lines of code. That code probably has hundreds of millions of possible code paths. Companies push developers for speed and get poorly designed, unfinished and poorly tested code. That is because their priority is time. They get time and bad code. That is failure in my book. Programmers are rarely given time to go back an cleanup and fix problems. Patches are what they are allowed to do. Pretty soon you have brittle code that is all patches and kludges. Now we have to start over, oh and I want it done in 3 months. Good luck mister!!!
Ridiculous. Cars are the reliable products they are today because underneath the hood, they’re all the same, and we’ve had a lot of time to perfect that particular process.
If cars were like software, you’d have diesel, gasoline, nuclear-powered, gerbil-powered, cloud-hoisted, swedish-bikini-team-carried… the variety would be endless. Would they all run the same? If a customer came to a automotive firm and said “I want a car with doughnuts for wheels, that runs on rum and has twenty television screens” do you really thing that firm could provide an accurate estimate of how long that would take, or that it could even succeed?
Computer Science has made good strides in narrowing the gap between expectation and reality, but in a field where every product is custom, it remains a very challenging problem.
if employers would give their job candidates the activity vector analysis (ava) by a reputable and qualified person/company; they wouldn’t have any problems. stupid is stupid does.
This whole conversation comes with a rather large and important underlying
assumption, what does it mean for a software project to fail? Not coming in on
time and on budget is one way to look at it. Another way to look at it is, does
the value derived to the business outstrip the investment in resources required
to create it? This is how I prefer to look at it, and at the end of the day is
how most businesses look at it in the long term. The difficulty is that most
businesses want to know the cost up front to green light the project in the
first place; a standard and prudent practice. This means estimating.
Let’s take a look at some of the structural realities of estimating,
regardless of industry. An estimate is exactly that, an estimate. The only time
the true cost can be calculated is when the project has been completed. Before
that there is a cone of uncertainty. The further out from completion you are,
the wider the cone of uncertainty is. This is true of every project that is
done. What does differ between projects of different types is the angle of the
cone itself. Projects that have relatively well known requirements with
repeatable processes have relatively narrow cones, regardless of how far out
you are. That is, the angle of the cone is directly associated with the
uncertainty/risk in the project. The greater the risk and uncertainty of the
project, the wider the angle of the cone of uncertainty.
So what does this cone look like for custom software development projects?
New projects usually involve changing existing business processes, many of
which have not been mapped out yet. So from that perspective the uncertainty is
high. New technologies are usually in play so from that perspective the risk is
high. New integrations are usually also occurring, further increasing the risk.
At the end of the day for a variety of reasons the cone of uncertainty in software
development will have a very steep angle resulting in high uncertainty the
further out you are from completion. Since waterfall projects tend to be
estimated further out from the date of completion than the smaller iterative
estimates associated with Agile, they waterfall projects have a much wider cone
of uncertainty at the time of estimation.
One possible solution to this is to just max out the estimate to try and
match the cone’s upper bound. There is certainly some great benefit to the
philosophy of under promise and over deliver. Having said that, the real costs
that are estimated usually come in much lower in the cone and there are very
good reasons for that that have nothing to do with the estimate itself. They
have everything to do with business management acknowledgement that the value
of the project is more likely to outstrip the actual cost and how that
intersects with how software projects need to be sold and green lighted.
So yes, one way to look at success is if the estimates are close to
reality. But I argue that is missing the point of why the software projects are
implemented in the first place. I’d argue what is being looked for is: does the
business value outstrip the actual investment. Let’s face it; if the real
success factor of software projects was based on the accuracy of the estimates
then we would have been out of business a long time ago because we are in an
industry that structurally makes accurate estimation difficult at best. Yet
companies continue to invest in software knowing the estimates are likely to be
inaccurate. If you ask yourself why that is, you will probably get a better
indication of what people who make the green light decisions really are
interested in as a success factor.
What is that company you mentioned that is so good at this stuff?
“Headspring” right?
Isn’t that the domain of this blog?
Your argument is B.S. Jeff. We do get it. and we’ve gotten it for many years. Most of us have read Frederic Brook’s seminal paper “No Silver Bullet”
http://en.wikipedia.org/wiki/No_Silver_Bullet
It’s a famous analysis from the 1970s
(i doubt that your piece will be remembered beyond next week”)
If a car was a failed project you wouldn’t ever hear about it unless it was the over-budget kind of failure, which plenty do.
The universe needs to change. I can quote you lots of interesting statistics saying it needs to change. But if I cannot offer you a solid way to implement those changes then my saying it needs to change is a waste of hot air and bandwidth, which is pretty much what this article is. It’s about as useful as Romney’s “trust me” math.
I’ve been a programmer, tech lead or tech manager for 35+ years and the only times any project I have been associated with have failed it has been due to management deciding to ignore the advice of their programmers and put people on death marches for schedules that were impossible to achieve and then required ungodly amounts of crunch leaving software engineers more prone to mistakes rather than less.
If management wants better software development, management needs to start listening to its software engineers! Of course, that is much less fun than complaining about your software engineers. I hope your elaboration includes a list of what can be done to change this trend.
As soon as I read “as an executive of a software engineering firm” I tuned out… seriously, most of the large projects that I have seen fail did so because of poor management decisions, many at the executive level, not because the developers couldn’t do the work.
The fundamental difference between software engineering and most other types of engineering is that you are always creating something new. If you aren’t, then you should simply be installing the existing piece, and not be doing any software development at all.
If you can’t see how creating new designs and new implementations is fundamentally different from mass producing cars, then your projects will always be late.
Software engineers need to be managed like creative artists, and not like worker drones.
if we stick to the formula (estimate x pi) it will be all fine.
Big difference with the car industry is that the time from design to market for a feature is around six months for a car part, whereas it is more like one month for a software feature.
How many times our price quotations including tests and code reviews have been turned down by customers pretending we were exagerating our prices ? That we “only had to transform the data”, without taking into account transaction / guaranteed delivery / logs / error management / performance / security / etc. These are the same customers that complain about the lack of robustness a few years later…
In IT just like in the car industry, it all falls back to one very simple rule : you get what you pay for. And most customers do not realize the value of software, because it is not tangible.
ive been writing and implementing successful bespoke soultions for 30+yrs (really!!) and the problem is that quite often the customer doesnt know what they want and when they see what u can do for them the goalposts change and they want more than u originally planned or budgeted for. its impossible to give an accurate price on an as yet unknown. ive tried working strictly to a spec done in advance, & it doesnt work as the devil is often in the detail that the customer did not relay. the only realistic way IMHO is to make the customer understand that the project needs to stay dynamic, you will work alongside them while they continually test and evaluate, and that any budget can be a guideline only. Its too easy to blame us at the sharp end when quite often its lazy minded customers expect u to know what they have in mind and expect u to know everything about how their business works. – just my tuppence worth !!
“That is, these projects were on time and on budget.” is by no mean the ultimate criteria for FAIL state. In fact I can point you to branch of those on time on schedule projects, which were simply rushed and failed utterly in the eyes of its end-user customers. Example, Blizzard Entertainment, with its infamous titles Starcraft/Warcraft was shipping with few years after initial deadline with apparently overblown budget, however bottom line, they delivered epic titles which returned back more than ‘estimated’ bot in fame and cash.
It is indeed frightening that in 2012, according to the study You’ve made, less than 50% of in-house software fails. Compare this number to the number of FOSS projects failing! You must agree that the number is > 70% !
So regardless of what god-blessed methodology you use, managing software process seems less productive than leaving developers self-managed!
Is it finally a rime that people like you! management, take the blame and not developers alone!
whats the point of having anyone on top of developers (as hierarchy or roles) in an organization when they don’t even take responsibility? really?
just because they’ve read a couple of scrum,TDD whatever books?
Changing ideas is nothing to be ashamed of; having no ideas to change at all is what’s bad. I’ve been in this field for 26+ years and I’m absolutely willing to do software engineering “the right way”, having assumed after reading your article that I’ve been doing it wrong all along. So, could your next article be about how to do it the right way? Do you have any ideas on that?
Come on … this hast been similar in each and all development projects for the last 200 years. I got to know people from the engine development division of Audi a few years ago … guess how they described the project to develop a new engine for the Audi A6? Or I have been told about design projects for new gearboxes in the automotive industry – similar experiences. The same has been true for the design of locomotives for the last 150 years up to this day.
Developing new technical designs (mechanical, electrical, software, electronic, chemical) is always an enterprise: The engineers, the customers, management on both sides and other stakeholders want two opposing things: (a) the most advanced solution to their problem that is currently possible (where “advanced” in itself contains a plethora of aspects: cost of development, cost of production, usability, reliability, maintainability, etc.etc.) (b) the lowest risk that the project will fail.
And our job (“our” = of developers/engineers, managers, quality engineers …) remains interesting because it is our duty to commonly find compromises that yield an acceptable trade-off between the value rankings of the various stakeholders.
This is by no means a “pitiful industry”. Each project in any engineering discipline is a standard human undertaking, with all the pitfalls that have been known for centuries. Open your horizon and learn more about all other engineering disciplines and their history, then you will see that software engineering is in no way special.
You made some decent points there. I looked on the internet for the issue and found most individuals will go along with with your website.
The main disadvantage is that they have a really old information system that must be revamped in order to take advantage of changes in the industry.