Who takes the accountabilty

I find that the user is held accountable for all software deliveries. The requirement artifacts that are produced are expected to be signed off by the user of the software, if there is any misunderstanding or ambiguity or incompleteness, once the sign off is done the noose is on the users neck. After the software is built, it is again the users responsibility to do a user acceptance test and if any test conditions are missed out or defects not detected in the acceptance test, it again is the users responsibility that it was missed out.

Requirements can any one get them right

We have all been struggling in eliciting requirements that stay invariant from users and if not in all in most cases, we have had a variety of mechaisms from DFDs to Use Cases for the user to verify that the requirements have been captured accurately and completely. However, there is always a gap is what is in the users mind and what is put on paper. We expect the user to sign off hundreds of pages requirements and carve them in stone. IMHO getting requirements down is like writing an instruction manual on how to swim or bicycle or walk. We know how to do it but we cannot describe it so that a person by following the description will be able to swim, ride a bicycle or walk. A user makes a decision, after experience, during a business process automatically, he does not refer to a procedure manual which tells him the exact way a decision is to be made with a long nested if then else. If the user is unaware on how to make a decision as a new situation has come, he just asks a more experienced person who is around. I think we have unreasonable expectations that the user should be able to speak out all the possible permutations and combinations which is required to create a system and hold a Change Request against his head.

We need to accept that getting 100 percent of requirements down to the minutest detail is not paossible and stop holding Cahnge Requests on the Users Temple

Should we pay for all the bells and whistles

Do software makers give features to end users of the system because they need it to do their job easier or is it done to give an intellectual programming challenge to the developers and architects of the software. If we look at the bells and whistles provided by the Microsoft Office family, does anyone really know or use all of them. Finding out a feature itself is no simple task. Unfortunately software prices include all the bells and whistles which people really do not use. All documents need not be shiny, for example documents for internal circulation.

Software vendors should have a minimum of two versions one which gives the essential features at a low price and the one will all the shiny bells and whistles at a higher price.

How similar are Software Engineering and Engineering

The principles that apply to Engineering have been extended to Software Engineering. Is this really the right thing to do? The principles of Engineering have made Engineering products reliable, their delivery times reliable and of consistent quality. However Software products have yet to reach that level. Engineering products are made with human and machine effort, a larger part being machine effort while in software the greater effort is from the human side. Machines are predictable in nature and two identical machines will perform very similarly, while humans are very unpredictable even twins will not give the same output. The same human being's output itself is inconsistent the same task done by the same human being may give different results on two different occasions. Is it really right to apply the principles of machines to human beings or we need to create a new model?

Is the complexity of software development becoming more

As we have moved from 3rd generation procedural languages to the an object oriented world and larger language sets I find that the amount of complexity has increased and the time to get the software out of the door has increased. Due to the largeness of the newer languages, it is difficult to master or even be aware of the available constructs. Both these I think have a role to play in the unreliability of software.