Developer

10 most damaging classic software development mistakes

In a survey of 500 software practitioners to determine the frequency and severity of common software development mistakes, 10 mistakes were reported to be the most damaging. Find out what they are.

In Steve McConnell's book Rapid Development: Taming Wild Software Schedules, he defines "classic mistakes" as mistakes that have been made so often, by so many people, that the consequences of making these mistakes should be predictable and the mistakes should be avoidable. McConnell is CEO and Chief Software Engineer at Construx Software.

To determine the frequency and severity of common software development mistakes, the authors of this Construx Software Builders white paper surveyed 500 software practitioners. Of the 42 classic software development mistakes identified, these 10 mistakes are reported to be the most damaging:

  1. Unrealistic expectations
  2. Overly optimistic schedules
  3. Shortchanged quality assurance
  4. Wishful thinking
  5. Confusing estimates with targets
  6. Excessive multi-tasking
  7. Feature creep
  8. Noisy, crowded offices
  9. Abandoning planning under pressure
  10. Insufficient risk management

Several of the other 32 classic mistakes identified are: switching development tools in the middle of a project, developer gold plating, and friction between developers and customers.

Read the paper about software development's classic mistakes to get more details about the survey results. Then, let us know how this list of 10 most damaging mistakes matches up with your work experience.

About

Mary Weilage is a Senior Editor for CBS Interactive. She has worked for TechRepublic since 1999.

23 comments
Chaz Chance#
Chaz Chance#

4 hours from shipping a product with 2M+ lines of code, I get asked to make a "minor" modification.

mikifinaz1
mikifinaz1

When code is written on the edge, where no one has gone before at the cutting edge it is hard to "see" the mistakes. In many instances saying to management "I don't know" won't cut it so you get all those tongue in cheek estimates like double the time you think, cut is by ten percent and the double it again etc. For the rote projects it is easy to find the "edges" and easier to see these mistakes.

Saurondor
Saurondor

Quite a lot of these top ten problems fall into what we could call "Sale driven development". A methodology in which a software product is sold before asking the experienced developers if it can be done on time or at all in the given time frame. By asking I mean throwing the question at them and actually listening to the response even if it includes words like: no, not possible, take longer etc etc etc. It is usually done under the assumption that enough developers will be found to address the problem and address it on time. It tends to evolve into what we could call "Bottom line driven development". The practice of hiring a large crew of cheap yet inexperienced developers to get the project done on time or at least within budget. Large can be replaced with "medium or small overworked" :)

jslarochelle
jslarochelle

2 (Overly optimistic schedules) and 4 (Wishful thinking) are still major killers. 7 (feature creep) is getting more and more under control. I would add: 11) Software-Development Fundamentals (lack of knowledge of) Inadequate upstream work product is a big problem. JS

Tony Hopkinson
Tony Hopkinson

Even more telling was the preponderance of respondents with technical hats on. And here's me thinking it was just my comments on what went wrong disappearing down the black hole that is management. Crowded office wouldn't hve been on my list, early convergence would easily make the top ten though. One day "we'll" make an effort to start getting some of this right.

Justin James
Justin James

Ever since I read "Code Complete", I've been a fan of his. :) J.Ja

Justin James
Justin James

I am all too familiar with that, I know exactly what you mean! And then, to cope with it, panic sets in, and some new "miracle pill" technology or management technique is tried every few weeks, the team gets reorganized every two months, and the whole thing just breaks down. J.Ja

apotheon
apotheon

7 (feature creep) is getting more and more under control. It is . . . ?

jslarochelle
jslarochelle

Code complete was the first one I bought and read. The second edition is even better (chapter 5 is gold). Rapid Development was the second one. It is my next favourite McConnell book. Not only does it contain great information but the presentation makes it a joy to read (I really dig the little Case Studies). I have read a couple of others but the last one I would mention is Software Estimation. This one has just enough theory and a good bunch of practical tips. Highly recommended. JS

apotheon
apotheon

I keep thinking I should get around to reading that -- but there are so many things I should get around to reading that I just never seem to get to it. Hell, I haven't even read most of The Mythical Man-Month yet.

Justin James
Justin James

Now, they call it "Agile." ;) All kidding aside, that's what I've heard from a lot of people I've spoken to, they basically now do a limited initial release in a somewhat traditional "requirements up front" fashion, then transition into an Agile variety (usually something resembling Scrum). By blasting out feature after feature, it is easier to turn down the really dumb requests (since the customer sees that the important stuff is actually happening), but at the same time, what used to be "feature creep" is now "incurring billable hours". From some of the Agile shops I've spoken too, one of their biggest challenges is really saying "no" and keeping the application focused. When you are in those rapid iteration cycles, it is easy to forget to take a breather, look at the project in a comprehensive manner, and ask if the requested changes really make sense. J.Ja

jslarochelle
jslarochelle

It has been a long road. But this one is finally getting under control for us. Of course everyone has to get involved and a lot remains to be done since some of the ultimate causes of feature creep are not totally gone (inadequate requirements analysis, ...). However, at least now there is a good process in place to regulate changes once a project is under way. Having seen first hand the effort required to get this under control I certainly agree that in general feature creep probably still is a major problem. JS

Tony Hopkinson
Tony Hopkinson

better disguised by management maybe. They've realised it really p1sses us off.

Justin James
Justin James

I've only read Code Complete 2nd Edition by him, and I hate to admit it, only partially through. It was my first and only experience with an "eBook". We had trial memberships to Safari, which experired when I was about 2/3rds through Code Complete. At the time, I was working 60 - 70 hours per week, Code Complete was my only releif during the work day (I would sneak in a chapter while eating lunch), and by the time I got out of there, I did not get a chance to pick it back up. But, in the 2/3rds that I read I learned more than I did in most years that I've been a professional, in terms of how to get things done, how to approach issues, and so on. But... keep your fingers crossed... I have a request to interview Mr. McConnell in the pipeline! I responded so enthusiastically to this whitepaper that Mary, my editor here, is trying to get me together with these folks to set it up. I think that this would be an especially nice thing to happen, not just for myself, but for the readers here too. Heck, just for the sake of it, I should see if I can get Paul Graham or Alan Kay or Charles Simonyi too. J.Ja

jslarochelle
jslarochelle

Where I work there has been a gradual change. I would be lying if I pretended that we are agile. Although we can use agile practices on all projects it is difficult to reconcile a total agile approach with all categories of software that we produce. We build mainly three categories of product: 1) One shot advanced interferometers (see for example IBUKI ) 2) Laboratory (chemical) 3) Online continuous analysis application. (see for example FTSW100 - the site is not quite up to date we've been shipping with XP for quite some time) In the case of #1 because such project is space born the process for those has traditionally been very close to pure waterfall. Agile practices can be used but some aspects of agile methods just cannot be applied (once the satellite is in space it is difficult to add feature or do another iteration on it). In all cases (#1, #2 and #3) regulation makes it difficult to be fully agile. For example CFR 21 PART 11 puts a number of constraints on documentation and methods. However, like I said we can use some agile practices. In the case of FTSW for example we now use smaller increments and use tight control over the feature set. We still have problems but things are improoving. JS

apotheon
apotheon

It's nice to hear that your organization is reducing the impact of the problem. It's too bad that doesn't seem to be the case in most organizations.

apotheon
apotheon

More information would be good.

Justin James
Justin James

Well, we'll see what happens. I am sure that not everyone I already asked will say yes, and as they turn me down, I'll move to the next group of people. It wasn't really in any particular order, I just started in Wikipedia under "computer pioneers" looking for the names of people I knew enough about and was interested in; once I get done with the current lists I have, if the response is favorable, I'll start working through the list of famous programmers. It's a tough line to walk though. Personally, I find these articles quite rewarding on a personal *and* professional level. But on the other hand, my interview type content rarely (Ian Hickson was a notable exception) gets much feedback from readers. Sure, it gives great credibility to this space, but unless the person says something really outrageously interesting (for Hickson, what got people riled up was the 2022 date for HTML 5 to be a "recommendation"), the response rate is poor. From there, it is hard to tell if it was silently appreciated by millions or people, or if it was simply ignored. I really wish I had access to the traffic numbers, to help me gauge interest in the various articles I do. J.Ja

apotheon
apotheon

I'm particularly interested in John McCarthy, Alan Kay, Paul Graham, Tim Berners-Lee, Gordon Bell, Larry Wall, and Yukihiro Matsumoto. Charles Simonyi and Martin Fowler don't do as much for me, Richard Stallman's out of touch with reality as far as I can tell, and I really don't want to read another of Bill Joy's neo-luddite rants, no matter how much I respect and appreciate his important contributions (vi and BSD Unix, among other things) to my favorite development environment.

Justin James
Justin James

Well, here's to hoping! I just reached out to: Charles Simonyi John McCarthy Alan Kay Paul Graham Tim Berners-Lee Bill Joy Gordon Bell Those were just the folks that immediately popped into my mind. Two others that came to mind are, unfortuately, deceased (Grace Hopper and Edsger Dijkstra). Some others that I think would be interesting: Larry Wall Yukihiro Matsumoto Martin Fowler Richard Stallman I'll wait to see how the first batch goes before asking others. I think that if I do one of these a month (or every other month), this list could last me for quite some time. J.Ja

Justin James
Justin James

... is that a lot of people do not understand that "personal development" makes you a better employee. They see a book which does not look like a language reference, and they assume that you are goofing off. Might as well have a comic book on your desk. Or worse, they see something that might help you become a better employee, and they assume it means that you are currently not qualified. Bleh. That's one reason why I prefer private or semi-private offices, I feel free to persue personal development on a linch break when possible (then again, how often do I get a "lunch break"?). J.Ja

jslarochelle
jslarochelle

I use the paper copy though because it gives my eyes a rest (sort of) and I can keep going while on the bus. An interview with Mr McConnell would be nice. JS

apotheon
apotheon

I'd like to see a Graham interview -- but, even more so, I'd really like to see an Alan Kay interview. Don't just focus on Smalltalk and OOP (though he always has fascinating stuff to say about the subject); get him to talk about what he's been doing lately.

Editor's Picks