Key to successful Software Development

One fine day when I was quite bored with my regular work, I went across to my colleague - Niraj Khatmode’s desk and was discussing about the paper that he was going to present in one of the conferences, later I was distracted by a book that he was reading on his PC before I got there. I asked what this book is all about and as he explained it fascinated me to read it. The book was "Extreme programming explained" authored by Kent Beck. As a programmer its title really impressed me.
I am a programmer since 7 years now and all these years I have been evolving as a software developer; in this evolution I have gone through some good, bad and worse phases of a software development life cycle. All these experiences have thought me certain elements about software development life cycle (SDLC). A chapter from the book “Four variables” talks about those elements.
The elements are very straight forward and are very much dependent on each other. Right dose of each of these elements will lead to successful and satisfied software development.

• Cost
• Time
• Quality
• Scope

When I retrospect and relate these elements with my past projects, I can imagine the reasons behind the good, bad and worse situation that have happened. Software development is a collaborative work between the customer, manager and the executing team and usually the customer and the manager are the forces that manipulate the above elements; however it’s difficult to control all the four elements together because if one increases or decreases the other element has an adverse effect, which means customers, managers get to control any three of the elements while the development team will have to deal with the resultant value of the fourth element. To prove this, let’s consider customer, manager try to control all the four elements by deciding that "you are going to get all these requirements done by the first of next month with exactly this team with a quality that is up to the usual standard”. When this happens, quality always goes down since nobody does good work under too much stress. Also likely to go out of control is time. At the end what you get is crappy software late.
The solution is to make these four elements visible to everyone (customer, manager, and team). This way all can decide and can consciously choose which three elements to control. If they don't like the result implied for the fourth element, they can always change the combination of these elements.
There is not a simple relationship between the four elements. For example, you can't just get software faster by spending more money. As the saying goes, "Nine women cannot make a baby in one month." and on the contrary, eighteen women still can't make a baby in one month.
In many ways, cost is the most constrained variable. You can't just spend your way to quality, or scope, or short release cycles. In fact, at the beginning of a project, you can't spend much at all. The investment has to start small and grow over time. After a while, you can productively spend more and more money. The time element is often out of the hands of the project manager and in the hands of the customer. Quality is another strange element. Often, by insisting on better quality you can get projects done sooner, or you can get more done in a given amount of time. There is a human effect from quality. Everybody wants to do a good job, and they work much better if they feel they are doing good work.
Now I have started believing that the one element that drives the control over cost, time and quality is the scope. As a software developer, I should give more importance to the scope element because If I change/eliminate/manage the scope the managers and customers will get better control over cost, quality and time. It has been fairly observed that developers complain about the requirement not been clear and there is a discrepancy between what we gave them and what they actually wanted, this is an absolute truth of software development. On the contrary as a software developer if you start thinking from the side of a customer you would agree that development of a piece of software, changes its own requirements, as when the customers see the first release they learn what they want in the second release or what they wanted in the first. It’s a learning curve and it’s a valuable learning because it couldn't have possibly taken place based on speculation. It is learning that can only come from experience. But customers can't get there alone. They need people, who can program, not as guides, but as companions
What if as a software developer I see the "softness" of requirements as an opportunity, not a problem?  Then I can choose to see scope as the easiest of the four elements to control because, I can shape it, a little this way, a little that way. If time gets tight toward a release date, there is always something that can be deferred to the next release.
All these controlling elements would make up-to great software and I believe all this can be possible through the agile way of development.