Review: Five Easy way to Fail

What could go wrong in a software project? I am sure everyone has their fair share of experience. I think based on some kind of statistic I read before, more than 50% of software project would eventually fail (or at least, the customer would not be happy). Based on the article from “How Hard Could It Be?: Five Easy Ways to Fail” by Joel Spolsky, here it goes:

Good People
It is said good programmer is 10 times more productive than bad ones, and 2.5 times as productive as the good one. Besides, there are certain “miracles” only the very best are capable of creating. But I still doubt the No. 1 cause of failure is because the development team sucks, or at least, I never been in a team which sucks so much (who gather this team anyway).

Estimation
I do agree it is always hard to make estimation based on a few pages of documents. The devil is in the detail, and we don’t have the detail in hand (the detail only comes on after we dig it during the requirement gathering and system analysis stage, if we do get the project) when we are required to do the estimation (to determine the man days and pricing). With little information in hand, I always mark-up the effort by 50%. One more thing, programmer could be quite optimistic in estimation, so beware!

Deadline
Customer always wants the product to be delivered yesterday, and the developer is always behind schedule and rushing. “Add more people to it”, they say. “Pregnancy take 9 months, no matter how many women you add to it”, says The Mythical Man Month. Something just cannot be rush, or at least it get worse when rushed. You want something lousy (or don’t work) and fast, or something good but being delivered slower? If the product is your baby, I am sure you know the answer. So don’t set unreasonable deadline just for the fun of it, unless it’s absolutely necessary (which is not necessary 90% of the time).

You Don’t Assign Task Equally
This is very true. Everyone work at different speed with different kind of productivity, and they are good at different things. Don’t divide the work into 5 equal pieces and give to 5 developers, as the slow eater will slow down the progress while the fast eater is wasting time on popurls.com.

Work till midnight
I am not an advocate on programmer should always work late. When this always happen, there must be something gone wrong somewhere. Either someone screw up the schedule estimation, or give in to customer’s unreasonable deadline, or project management fucked up, or the programmer just suck big time. Working over 9:00 PM every night is really like a “Death March”, where the morale is dip lower and people are going to leave the job very soon. Occasional project dash is alright, but it is not supposed to be a habit or culture.

What else?
Of cause there are other issues which come to mind, such as

• No proper tools and libraries to fasten development. No existing framework or architecture as foundation to built upon. No standard practices within the organisation to ensure consistency for maintenance sake.
• Fail to understand the requirement of the Customer. Some people just don’t have good listening skill.
• Specification changes rapidly as the project goes. This is not unusual, and the situation is very delicate. This arrangement basically screws up all your estimation, budget and task allocation. Why do we agree to it in the first place? Because we need to deliver yesterday? Deliver what yesterday? Don’t ever agree to this, because it is a death trap. Unless the customer is really paying a lot of money for this, perhaps 500% more than your initial vague estimation.
• Don’t keep changing people or switching task when the project is running at full steam. You are basically slicing your own productivity and risking your schedule.
• Manage your Change Request professional and skillfully. Everything must be documented, and indicate whether this change shall have impact on the timeline and cost.
  

I never quite participated in a very successful project (which I feel like bragging about), unless it’s my freelance project. What does this mean? Maybe I am at the wrong place all these while.