Developer

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!

Editor's Picks