Related Post

Spread the word

Digg this post

Bookmark to delicious

Stumble the post

DZone This Post

DotNetKick This Post

Add to your technorati favourite

Subscribes to this post

This website uses IntenseDebate comments, but they are not currently loaded because either your browser doesn't support JavaScript, or they didn't load fast enough.

31 users responded to this post

www.uploaded.tv said in November 3rd, 2006 at 5:03 pm    

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

Bashmohandes said in November 11th, 2006 at 3:04 pm    

Top 30 Mistakes in Software Development

Don’t do this unless you want to get out of business.

DotNetKicks.com said in November 11th, 2006 at 3:16 pm    

Software Development Top 30 Mistakes

You’ve been kicked (a good thing) – Trackback from DotNetKicks.com

Bashmohandes said in November 11th, 2006 at 3:17 pm    

Top 30 Mistakes in Software Development

Don’t do this unless you want to get out of business.

GoodShit said in November 14th, 2006 at 9:22 am    

http://goodshit.phlap.net/2006/11/post_8677.html

Software Development in the Real World: Software Development Top 30 Mistakes…

Top Ten Lists said in November 19th, 2006 at 2:24 am    

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

Интересни връзки 5

Интересна класификация на видовете програмисти: The Fourteen Types of Programmers.
Levels of Web Development…

a dutch developer said in November 23rd, 2006 at 1:36 am    

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 said in February 27th, 2007 at 7:21 pm    

Funny, unfortunately I can an relate to this!

Peter Bell said in August 25th, 2007 at 11:28 am    

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 said in August 25th, 2007 at 12:23 pm    

Thanks for all your comments!

Jason said in August 25th, 2007 at 1:05 pm    

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 said in August 25th, 2007 at 1:17 pm    

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

Miguel

arjan said in August 25th, 2007 at 2:28 pm    

>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 said in August 26th, 2007 at 10:21 am    

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 said in August 26th, 2007 at 11:02 pm    

I’m a sinner.

I always break the rule #3….

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

:p

lol

Sandro said in August 27th, 2007 at 12:59 am    

I see them everyday!

woohooo said in August 29th, 2007 at 8:16 am    

#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 said in December 17th, 2007 at 4:11 am    

Thanks for all your comments!

Software Development said in April 26th, 2008 at 12:58 pm    

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 said in May 11th, 2008 at 3:52 am    

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”.
http://www.jebshouse.com/wordletter.php?l=D

Sanket said in October 23rd, 2008 at 2:38 pm    

A couple of more points I would like to add are,

1. Not creating enough and/or timely documentation
2. Finger pointing amongst teams, like between Dev and Test team
3. Lack of confidence in the managers

DemoGeek said in June 4th, 2009 at 5:29 pm    

Planning is good but not overplanning. I've seen big 5 companies spend a whole lot of (almost 70%) time on planning and coming up with fancy documents for every step of the software development process. Then when it comes to execution they miserable fail big time.

Too much planning is not good for a product in my books.

TheAL said in March 16th, 2010 at 3:19 am    

Global variables, no comments, and using the "hot new thing" even if an older, simpler thing can be done are all things that bug the crap out of me when I look at open source or inherited code, especially PHP scripts for web sites.

Hiren said in April 29th, 2010 at 8:40 am    

Yes you are right. but in my experiance of 12 years in software devlopement i have seen that the first and foremost need is motivating team. because if can't do the desirable work then they are just confusing their minds and going very deep into stage of sleeping. so motivating is neccesary

supra shoes said in May 13th, 2010 at 2:18 pm    

helpful info…great article..thanks for the share

christian louboutin said in June 1st, 2010 at 8:16 am    

good post,i like it

Louis vuitton said in June 5th, 2010 at 3:15 am    

I’m very interested in your article,

louboutin outlet said in June 12th, 2010 at 7:52 am    

Yes you are right. but in my experiance of 12 years in software devlopement i have seen that the first and foremost need is motivating team.

christian louboutin said in June 30th, 2010 at 9:19 am    

This is such a great resource you are providing. I enjoy seeing sites that understand the value of providing a prime resource for free. I really loved reading your post. Thanks!

discount ed hardy said in June 30th, 2010 at 9:20 am    

Really trustworthy blog. Please keep updating with great posts like this one. I have booked marked your site and am about to email it to a few friends of mine that I know would enjoy reading..

1 Pingback & Trackback On This Post
Leave Your Comments Below