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

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

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!

#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)

I always break the rule #3….

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

:p

lol

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.

Miguel

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.

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

Besides that, great article..

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