Software Development Top 30 Mistakes

I have been developing software and web applications for nearly 11 years now.  Software development has come a long way since the days of Binary, Cobol, etc.  What still fascinates me about software development is the same mistakes made before, are still made today.  Below are the top 30 Mistakes that are made within the software development process.  It's amazing to see that none of these have anything to do with the language itself.

 

1. Not understanding the user's needs. Lack of user input, or not even asking.
2. Underestimating the size of the project.
3. Rushing through the planning stage, or avoiding the planning all together.  Code first, plan later! BAD!
4. Not testing early enough, often, or at all!  Make it a habit!
5. Choosing the "Cool" methodology at the time, vs. one that has worked in the past. Which leads into my next point...
6. Not using a methodology.
7. Letting a software developer run the software development project.
8. Bored, unmotivated team!  You have to motivate your developers!  If you can't motivate, don't bother trying to lead.  Your team will fall asleep, literally.
9. Planning on catching up later.  You won't... don't even think it!
10. Non Source Control!  Ouch.. not good people... and no, just installing a software package is not it...
11. Deciding to switch your development tools when you’re already into the project.
12. Allowing feature creep.  Just say NO!  Everyone will be happier in the end.
13. Omitting necessary tasks to shorten the project plan.  Really, what's the point of doing this?
14. Insufficient management controls in the development project.
15. Lack of high level business sponsorship.
16. Adding people at the end of the project to "speed things up".  You will only slow things down...
17. No unit testing.  Heck if you can do it, use Visual Studio Team Foundation Server and set up some automated testing nightly.
18. Stressed out software developers.  If you have managed to perform even one or two of these software development mistakes, you will have a stressed out bunch of programmers to deal with!
19. Lack of error handling.
20. "Off by one" errors.  These happen a lot during the software development process.. *sigh*.
21. Typos...  Just use option strict and explicit please..  during one software development project, which I was on as a consultant, they were getting ridiculous amounts of errors everywhere... turned out the developer couldn't spell and would declare variables with incorrect spelling.. no big deal, until you use the correct spelling when you're assigning a value to it...  and  you had option explicit off.  Ouch to them...
22. No understand the deployment or hardware the software is to be installed on.  Ohhhh it's for a Macintosh... lol.  Well hopefully not that bad, but you get the point.
23. No naming style or code conventions.  Honestly it doesn't matter what you use... as long as you are consistent with the rest of the team, and hopefully at least yourself.
24. Using global variables everywhere.  These are NOT your friend and hog memory like nothing you have ever seen before!
25. Not asking for help at all during the software development process.  If you’re stuck, don't fight with it for hours on end!  Ask for help!
26. Not commenting your code.
27. Hogging all information to yourself.  You think you're more valuable this way?  You're actually not and there is a plan brewing to get you kicked off the development project, and possibly out of the company.  You might want to brush up your sign "Will code for pizza!". 
28. Performing database operations at the application layer instead of the database layer. Not only is this putting the processing juice on your application instead of your server, but you have put your database at risk of data integrity issues, and getting bad data!  Some of my hipster cool friends are always saying "It's alllll good", well, if your database can be caught saying this... and If everything looks good to your database, then you should be worried.  It is NOT all good!
29. Not validating your data! Yikes...  Yes.. let’s just assume all the data is perfect! NOT!
30. No load testing.  What.. This is supposed to run on 1,000 user's machines through Citrix?  Interesting... Shouldn't be an issue! lol... NOT.

Software development is tricky enough!  Make it easier on yourself by ensuring you do not make any of these mistakes.  Although it seems like a simple list of things not to do, it can make your life so much easier! By the way, while you're here, check out our competition to win a free iPod, we are trying to get a software development blog as the number 1 site on Technorati!  All you have to do is add this blog as a favorite, and we will pick a winner as soon as we are number 1! Wouldn't it be cool if the number 1 Technorati Blog was a software development blog with real content instead of "Boing Boing", or "How To Make Money Online"?  Help me out!

Comments

[www.uploaded.tv]

Be on TV! go to www.uploaded.tv and upload yoruself to TV~

[Top Ten Lists]

[...]Software Development Top 30 Mistakes[...]

[a dutch developer]

Nice list! Certainly the part about testing, but did you spellcheck your article? ;)

For example, I see at least three times the use of "your" where you meant to say "you're"..

Besides that, great article..

[Jason]

Funny, unfortunately I can an relate to this!

[Peter Bell]

Lots of great points. However:

12 - feature creep - unfortunately, if you don't allow this you end up building what the client thought they wanted six months ago rather than what they actually need today. I'm often stuck with fixed bid/fixed scope projects, but the clients are better off with an Agile approach if at all possible.

26 - Not commenting code - But then there is also the "comments are an antipattern" school of thought. I provide class, method and argument comments but usually when I need to comment my code it means I need to write another well named method to solve the problem. These days I don't comment as much, but I find my code easier to read.

28 - You're right, but I don't like it. I'm an app developer and hate the fact that capturing good cross-database error messages in a parsable manner is a pain. So much easier to write the constraints in the app layer, but I'll admit it isn't the right wa to go.

[Miguel Carrasco]

Thanks for all your comments!

[Jason]

From the quality of your writing style, I can only assume you give as little thought to the quality of your code. Please save the chat-room slang and ellipses for conversations where you need to exhibit no authority or experience.

[Miguel Carrasco]

Hi Jason, sorry you don't like the writing style of this post.

Miguel

[arjan]

>12 - feature creep - unfortunately, if you don't
>allow this you end up building what the client
>thought they wanted six months ago rather than what
>they actually need today.

True, but you need to balance things here. Yes, requirements change during development and both your process and your design needs to be prepared for that.
But, you often NEED to resist feature creep which is a whole other beast really. Feature creep is adding more and more little things during the project, which causes the whole to become an incoherent whole.

Suppose you're designing a DB and during development people ask if you can just add a spreadsheet ability (tables and spreadsheets look like each other right?) and when you did that, they also want to add word processing abilities (for cases where you need to edit large amounts of text in a cell), and after you implemented that they think you should add a game of Pacman to it (since DB operations might be slow, and the DB admin could become borred).

All of sudden you'll find you have not created a DB anymore, but some strange combination of multiple types of software.

Ok, this is an exaggerated example, but I hope you understand the point.

[Antonio]

You forgot to add the top mistake while testing an application. Testers using a develop environment to run the tests, while developers are changing things here and there. During system testing, it's more than common. And it's impossible to rely on test results while you are running tests on an environment that is changing day after day. You need a stable build and a closed environment (where developers can't stick their noses) to run the tests.

[John Prado]

I'm a sinner.

I always break the rule #3....

So what??? Don't we, all developers, going to hell anyway???

:p

lol

[Sandro]

I see them everyday!

[woohooo]

#21, #23 and #24: use sensible languages/platforms that support strict typing and casing, do not need "strict"/"explicit" (or similar) and don't support "global" variables (i.e. without namespaces) in the first place...

#28: build software in (more) layers with clean interfaces between them *and* use (more) abstraction layers:
most reasonably good language coders suck at DB-design/SQL and vice versa - so decouple your layers in a way that splits responsibilities between specialized developer roles for the different layers in the first place (I'm talking enterprise apps here, you can certainly fill all roles in your small home-brewed apps for managing your DVD-collection... ;o)

[Narasimha Chennupati]

Thanks for all your comments!

[Software Development]

hey,

I liked this part:

Hogging all information to yourself. You think you're more valuable this way? You're actually not and there is a plan brewing to get you kicked off the development project, and possibly out of the company. You might want to brush up your sign "Will code for pizza!".

Regards!

[Esenthal Prave]

I'm not sure what the hold-up is... maybe they have re-thought their stance on how this is going to actually make the company any money. Or perhaps their lawyers pointed out the liability of providing agents a platform to stick their feet in their mouth. Whatever it is, it's hardly something I'd claim as being "Well done".
www.jebshouse.com/wordletter.php?l=D