Software Development

10 more classic mistakes that can wreck a software development project

It turns out there are more dev project mistakes than one 10 Things post can hold. Justin James revisits the topic with input from TR members.

Recently, I wrote about 10 classic mistakes that plague software development projects -- and I received a pile of great comments from readers on it. Today, I will look at 10 more of these mistakes... compiled from reader feedback.

1: Not saying "NO"

Ole88 commented, "If a PM or team manager can't say no, scope creep comes into play too often. You have to know when to say 'Yes' and when to say 'No, that will wait for the next version or update.'" And he's right! Scope creep can kill a project quicker than you can imagine. It is not just the added work that is the problem. It's the fact that the original design never took the new features and requirements into account. It is okay to expand requirements, but the time to implement is often far, far more than it would have been if the requirements had been known up front. This was the top-rated comment on the article, and with good reason!

2: Trying to boil the ocean

A close cousin of scope creep is the "kitchen sink spec" for a project. doug.duke summed it up quite well in the first comment on the original article:

"Many projects are just too big, covering too much scope. In many cases, it is better to move forward incrementally -- even within a larger scope of work. Concentrate on getting a well-defined, easier-to-manage set of tasks delivered and bedding down before moving forward with the next. In many cases, massive 'big-bang' data migrations fail due to their complexity or end-users simply cannot absorb enough simultaneous change to support successful project completion."

3: Locking people out of the loop

SpiritualMadMan said, "I just left a software development project after having been told I was not a programmer and [getting] locked out of the loop. Even though my project will be distributed, they will have to rewrite a lot of it because I was not privy to their discussions. And, therefore, it's not compliant to their standards."

What a mess! There are often good reasons to not invite ever project member to meetings: It may not be relevant to them, there is always the "too many cooks" issues, and so on. But at the end of the day, everyone in the project should at least be aware of what decisions are being made. I've been in similar situations where things were being discussed and I had no idea, and the result was a product that did not meet the secret requirements.

4: Favoring form over function

Long time TechRepublic reader Tony Hopkinson points out that projects often get bogged down in things that are not relevant, and he's right. For example, unless "make a dashboard" is the project itself, wait until the actual functionality of the application is squared away before you start working on a dashboard. It is easy to get tied up in the minutia of a project when the meat and potatoes aren't finished.

5: Ignoring those who actually know what's wrong

neilson brought up this gem: "Failure of management to listen to 'the trenches.' This is your classic Dilbert storyline, where management punishes messengers who try to get help for problems that the developers are encountering. An infrastructure to hide bad news from management develops."

If you think about it for even a moment, you can see how dysfunctional this is. Yet it is one of the most common things to see. Sadly, this is not confined to software development projects, but it is particularly bad on them, given that you are in a situation where mistakes are so costly.

6: Falling prey to responsibility creep

When I wrote the original article, I had a good number of other items that I just did not have room for -- and most of those are in this article, after being brought up by readers. But one I had not thought of was mentioned by RMSx32767: responsibility creep. As he put it, "I've also seen 'responsibility creep,' i.e., a new hire is brought in to work on a specific task then diverted, for whatever reason, onto completely unrelated projects. Needless to say it likely spells DOOM for the original project and its schedule." Too true!

7: Promising before planning

In an email, Allan P. Clapp reminded me of one of my worst nightmares: the salesperson who says "Yes" to a customer before talking to the developers. This is all too often a path to misery, pain, frustration, and disappointment for both the vendor and the customer. Projects quickly slip behind, as the developers attempt to live up to unrealistic deadlines.

8: Relying on cutting-edge tech

Michael Graziano also sent in a number of suggestions through email. One of them is the habit of developers to use new, unproven technologies on projects, and I have to say that I agree. Programming is a balancing act with this stuff. Do the new technologies convey overwhelming advantages? Will you be adopting a technology right before it drops off the face of the planet? It is an art to pick the right tech, but you can make it easier by not adopting a library that put its first beta on SourceForge last week.

9: Rolling your own

Another point from Michael was the habit of many developers to design and write their own frameworks and libraries instead of buying off the shelf. While there are often advantages to self-made libraries and frameworks, the disadvantages are many. You should really evaluate how important it is for a library to be "just so" before taking on the task of designing, developing, and then testing your own frameworks and libraries.

10: Writing wrong prototypes

A final item from Michael is about prototypes. He related the story of a development team that wrote a prototype of an application in an entirely different system from the actual project. Now, don't get this wrong, prototypes are good. And in some cases, you can write a prototype in a language or system designed for it, learn some lessons, and throw it away when you are ready to work. The danger is when you put too much time into a prototype but learn lessons that can't be applied to the actual product you are building.

For example, if you whip up the prototype in Ruby on Rails, learn a lot about database access in Rails, then build the product in ASP.NET, you wasted a lot of time. But if you did the prototype in Rails with minimal backend work, got feedback from users, then put together the real thing in ASP.NET, that makes sense.

About

Justin James is the Lead Architect for Conigent.

20 comments
TsarNikky
TsarNikky

Let us not forget those wanting the new system to not have any clear idea of just what they want. How can IT develop a system, when what the new system is supposed to do hasn't or can't be defined?

eruiz
eruiz

It seems that the error list is related to the system engineers's point of view. I agree with that if i punt on the shoes of the people who have to make the software. But if you think from the point of view of the user, then you should take into acount that he will became into a "customer". An all the marketing, bussiness, etc. theoretic guys agreed that "the customer is always right". So you have to think as a user (customer) and realize that the "system" have to adapt to you, and not that you have to adapt to the system. If the system doesn't fill the user needs, then it is simply wrong and therefore does not serve, that is it. Of course, I agree with you that the user always is changing his requirements, or that the user doesn??t know exactly what he want, but since the beginning of system engineering it had been like that, isn't it? And in order to deal with it appears amazing theories for requirement's capture, complex systems designs, rational unified approach, the newest agile methods, and so on. So it would be nice if the software engineers realize that many of the mistakes listed are consequence of an inappropiate requirements capture... and therefore known what to do Regards, Elias

christinekristy
christinekristy

It is easier to say No when you are working as an independent developer. The difficulty however sets in when the company you work for asks for the development. saying no to your boss may make you seem arrogant or hiding your incompetence

anil_g
anil_g

Oh, I worked for a couple of months under a project that was heavily defined by #7. #6 also applied. The project died.

anil_g
anil_g

4 and 5 collide. The guy who keeps wasting time in meetings nit picking about the colour or the shape while everyone rolls their eyes may have useful input but he needs to learn how to filter it. He might get excluded. Strict rules about gathering requirements may help. 8 and 9 sometimes contend as well. You don't like what's available but no-one has got anything better. Can your team do a better job?

sysop-dr
sysop-dr

You make a prototype for the typical purpose of a prototype, that is showing to our internal users to get feedback and learn stuff to actually build the real thing. But then someone above you sells the prototype to a customer. Yeah the prototype can handle 3 or 4 users at once and can give a reasonable demo and the user interface looks done but they then try to get their whole company using it and well it's a prototype. And the version number at the bottom of every screen even says "Version 0.1a." Yeah this is going to be a _fun_ year.

lelandhamilton
lelandhamilton

Re: 7: Promising before planning In an email, Allan P. Clapp reminded me of one of my worst nightmares: the salesperson who says Yes to a customer before talking to the developers. Not only do they say "Yes", they also promise a delivery date before even telling the development team about the "feature". If the developers say 2 months, the sales person or management says they have to have it in half or less time and schedule it accordingly. When it is not delivered "on time" but actually takes the time that the developers stated, the developers are blamed for delivering it "late".

minstrelmike
minstrelmike

I generally prototype with basic html. It shows the users all the buttons/functionality we'll have to talk about and usually having a screen will prompt them to ask questions and provide more ideas for functions. Get it all out on the table up front and then we can discard and have the original printouts with buttons/functions marked off for phase II or later. I'll even mock up a dashboard to ensure the developers are paying attention to the right chokepoints. Of course, I also verify that the backend functions _can_ work but usually that's as simple as doing hello world stuff for myself if it is some new technology.

jharvey6
jharvey6

PS. Also critical share with all, the "10 commandments of Ego-less programming".This one really works

jharvey6
jharvey6

These are all good points, including tooblessedtofail's. I have run into each and everyone of them over the last 10 years. But what is the solution???? Strict adherence to a SDLC/Design methodology? The last quality "system" to come down the pipeline. Usually a repackaged/renamed iteration of some quality system from a bygone era and sold as a panacea to all our IT project woes. Then only to become part of the problem. It comes back to one everlasting tenet. Leadership!!! Despite all the tools, methods, gimmicks, systems, programming languages, new technology, legacy success it's the kind of leadership, collectively and individually, that follows clear definition in design and manages expectations for that design. Maintain the vision, direction and sharing that with all in the circle of development. You can wrap whatever "system" around it you want. But stick to the goal and vision and then share the design.....my 2 cents...borne of all the same frustrations.

tooblessedtofail
tooblessedtofail

Lovely write up here! In fact I think I could relate to at least 6 out of 10! Especially the first one. In my own experience I found that there are users who are just plain biased and have a dislike for your application/solution before you even penned one line of code! So when it is deployed, there is a seemingly endless comparison of the old system and the new that will always end in..."I can't work if the application does not work like the old one!" They have a change aversion. They do not like new things! Secondly, when you have clients, end users and stake holders that cannot agree on how the software should function, you can have a software project that is easily stalled and delayed unnecessarily. This is my take on this!

Justin James
Justin James

"What happens with the fact: "the customer is always right"?" At my very first job, our training had a quote that's stuck with me my whole life: "The customer is not always right, but a customer is always a customer." The customer is NOT always right. If they knew everything they needed to a T, and they knew it *accurately*, then software projects would have a much lower failure rate. But, just as importantly, the customer has major gaps in their knowledge that limit their ability to be right. For example, a customer may have an ideal process for handling a piece of paperwork, and they demand that the program 100% replicate the paperwork. That's almost always a provably poor approach. It usually WORKS, but it loses most of the "point" of turning it into software in the first place. For example, replacing the long list of checkboxes with a long radio button option group may be a 1-to-1 translation, but a combo box + autocomplete is much more likely to make it easy for the users. The trick is to act with the customer's best interests in mind, and there is a way to show them what can/will work better without being rude or nasty about it. J.Ja

Tony Hopkinson
Tony Hopkinson

Looked more like a PM's point of view to me. Aside from inconsistent requirements, there's nothing a software engineer can do with an invalid one. They don't even know it is invalid. They are engineering to the requirement they were given. A software engineers view of why projects fail. Change is a given In order to successfully and efficiently cope with change quality engineering is a must. In business quality = good enough. Well it wasn't was it! Again... HtHs

Tony Hopkinson
Tony Hopkinson

If you are doing front end, don't do a back. If a back, don't do a front. Aside from stopping fools selling it, the effort that goes into one should be targetted at it's pupose. If it's really a version 0, then it's not a prototype. I got bit once now I deliberately and obviously cripple them in the name of efficiency.

RMSx32767
RMSx32767

Fine if all your code has a user-interface. The IT world is much broader (and deeper) than some believe.

anil_g
anil_g

I think I agree that there's always got to be someone who is driving the quality and they have to have comprehensive oversight and influence on decision making to make it work; but Agile is a clear step forward over waterfall. I'm not talking about some highly specific definition of Agile but just the whole idea of minimal viable product with iterative review and release.

Tony Hopkinson
Tony Hopkinson

These guys use the stuff to do their jobs, it can help or it can hinder. They rarely get any real say in the end product, usually designed by managers and beancounter ffs. Go talk to them, get some concrete problems. That's when you find out that your new form (the only bit they care about), has the fields on it in the wrong order, or inhouse jargon is stuffed up. Things that only people on the job know, and that really matter to them, and would probably take about ten minutes to fix and make them really happy. Do some heuristics or cognitive walk throughs and then validate them. If you wrote something they don't like, that's your (or possibly management's) error not theirs The other thing to bear in mind, is the guys right at the bottom of the food chain entering data into systems, need to get something out of them. Put your sales hat on tell them why they should like it. Do not even mention some new shiny kit or tech, or other arcane crap. Instead of navigating through 15 different menus, click this button, that's what they want to hear.

anil_g
anil_g

The customer is (effectively) paying the developers to do work. That work (should) include analysis and design. If you can get that right it should be just a matter of expressing the customer's requirements correctly, so that the developers can do the design. If the customer starts designing the software, including the interface design, then why does he need to pay the developers to do it? This indicates weak preparation from sales.

Tony Hopkinson
Tony Hopkinson

Sometimes it won't be, though that will be rare. There are other methodologies than those two though, and they'll fit some projects far better. My biggest problem with Agile, is a bunch of panacea merchants running around saying this is new (it isn't), this is radical (it isn't) this is THE answer (not just no but hell no) Do yourself a favour and qualify your statements, otherwise some might think you are as competent as they are...

Tony Hopkinson
Tony Hopkinson

No matter what analysis is done at the start of any non-trivial project, it will be wrong / incomplete at the end of it. If you can get analysis and design right. You can't. Even if a developer and customer had the resources to do so. In any non-trivial project, they will change. Even discounting any external factors (e.g. OS and back office changes), and given that there were no misunderstandings or omissions, and that your people (and possobly theirs) didn't have a learning curve, and that resources stayed available and their environment was static, the mere existence of the new software will change the perception of requirement once it gets seen. That doesn't even consider the basic business process of not spending significant effort investigating the needs so they can be costed, with no expectation of actually getting the job! The situation you are describing has only ever existed in the classroom, never happened in real life, probably never will. It's perpetuating the fallacy that it could is the most significant aspect of project failure. Wrong expectation from Day Zero...

Editor's Picks