Fact: A majority of the software projects commissioned never go into production.

Software development fails to deliver, and fails to deliver value. The failure has huge economic and human impact. We need to find a new way to develop software. - Kent Beck.

The basic problem with software development is risk- a problem that must be solved if the software development process is to be as reliable and as cost effective as other processes like building a house that we can consider to be reliable.

Let us look at some of the risks involved:

Schedule Slips: When the delivery date comes, we have to tell the customer that the software isn't ready as yet and that it may take some more time.

Project Canceled: The customer decides that it would be better to cancel the project

• After numerous schedule slips, he loses confidence that the project can ever be completed.
  
• The Business process changes, which leaves the software incapable of solving the new business problems.

System Goes Sour: The system does go into production (so far so good), but the defect rate or the cost of making changes is so high that the customer looks for other alternatives.

False Feature Rich: The system has great features. Unfortunately these are not the features that the customer finds useful, rather these are the features that the programmer thinks are great features (usually something challenging to accomplish but without any great business value).

Programming For The Future: The system is developed to accommodate features that might be requested by the client at a later stage. Also when the client actually requests the feature (if at all) that we developed, technological changes may have made it cheaper to implement. This leads to greater initial costs.

Frustrated Programmers: Often software development schedules are fixed by the marketing persons in consultation with the client and the schedule is handed over to the programmers to get done. "Ok, guys get this project up and running, you have four weeks to accomplish this". The problem is not that the programmers were not consulted; the problem is that the estimate is not evenly remotely realistic. Often the estimate is as realistic as Clinton's truthfulness or Iraq's WMD. Being asked to meet such unrealistic schedules lead to frustrated programmers, and frustrated programmer don't write great code.

Staff Turnover: A few months after the system has gone into production, all the original programmers have left for other more interesting projects, or (worse still) left for other more interesting companies to work for.

Now that we have discussed some of the problems that plague the software development process, let us look at ways to reduce these risks.

Schedule Slips: We can have small release cycles - a large project is split into manageable small cycles. In each cycle something that is of value to the customer is implemented. The customer is allowed to decide which features are to be implemented first and which all are to be postponed to the end. Thus even if the project is getting late, the most important and valuable parts would be working.

Project Canceled: The customer must be involved in each release cycle. This way he would be bale to decide the way the project is headed - can change the direction of project id his business needs change. Also if the project gets late, he will have the most important parts working and so will be less inclined to cancel the project.

System Goes Sour: The only solution to this problem is to deliver better quality software. How to deliver better quality software would be discussed in the next article. (It's a topic big enough and important enough to merit an article to itself)

False Feature Rich: In each release cycle, the customer be allowed to pick features that are important to him - he will be picking features that are relevant to his business process and not the processes that are a programming challenge.

Programming For The Future: Keep it Simple. If a feature is not required now, don't implement it now, rather trust your ability to implement it when required. The advantages of this approach are:

• Lower initial costs, since you are implementing only what is required.
• If the client does not need a feature we don't have a dead investment.
• When the client does indeed ask for a feature and some technological advances have made it possible to implement that feature at a lower cost, we are in a position to leverage that technological advancement and deliver a more competitive solution.

Frustrated Programmers: The primary reason why programmers get frustrated with the project is that they are given an impossible schedule. The schedule can be fixed by the marketing people in consultation with the client and the programmers. The programmer must be allowed to say what he can do in a given interval, and how long will a feature take to implement. The client must be given these details and allowed to choose what he wants to be implemented first. Considering the fact that it is the programmer who has to develop the software and not the marketing guys, his estimate must be respected if schedule slips and poor quality software is to be avoided.

Staff Turnover: Staff turnover in itself is not a problem, so long as at least someone is familiar with the parts of the project that needs change. This means that if everyone on a project is familiar with all the aspects of the project, there is a better chance that when the need arises at least someone will be familiar with the parts that need change. Also, if the programmers are not dissatisfied with the project and work conditions, the chances that they will leave are lower.

If we accept the fact that these are the risks that we face in developing quality software and running a company that is in the business of developing good quality software, we must address these risks. We need to address a way of developing software that addresses these issues. We need to communicate this new way to developers, managers and customers. We need to change our work culture to reflect these changes.

Sajith Madhavan is on the Customer Fulfillment team at Stylus. He lives by the saying "Nothing is too small to know, and nothing too big to attempt."

If you are interested in learning more about our services and what we do, please check out the Services and Portfolio sections. Would you like to see if we identify your needs well? Click here to find out more.