Well, haven't we all(by all I mean the software engineers and programmers and testers and anyone involved in the task of creating and selling software) suffered the effects of the nightmare called Project Estimation.
Don't we feel upset that we end up getting the short end of the stick. All is well and fine with the world, until a project is to be brought forth into this world. Then start all the procedures of requirement analysis, design, test cases, etc, etc. But not before the estimation both in terms of time as well as money is sent to the client.
Now we all should know that estimation is one of the most important tasks of not just software engineering but any project be it mechanical or civil or electrical. It is estimation that enables one to know how much resources (time, money, manpower) they will require to satisfy the customer with a quality product.
But that is the exact point which makes the software industry so different than others. With dynamically changing skill requirements and an attrition rate higher than any other industry, the software industry begins to differ from the others. The estimation procedures seem extremely flawed since most of the projects have never been previously executed. So an estimation ends up being more of a guess work than anything else.
The sad part is that the time frame seems highly improbable in most cases and is merely something as minimal as possible to bag the project. Later, when the schedule naturally starts slipping, the late stays and the software patches and the heated arguments start to flow. More people are added to the project completely ignoring the wise teachings of "The Mythical Man Month". I would recommend this book to all software professionals who are serious about creating quality software.
To be fair to the guys who do it, they have to do it to get the project as that is where they can compete with their competitors. Because the entire industry does it and now we have come to expect that a project will always have extremely tough deadlines and we need to deliver within that time frame.
Now the average programmer(which includes me) has nothing to do with this. His world consists of completing the task as needed. He take it as a challenge to dive into the difficult if not impossible tasks of building software castles in the air. But because of this he suffers not only physically but also mentally when the realization of the position he is in dawns upon him.
There are times when the impossible is achieved and the ecstasy that follows is immeasurable. But such situations and far and few. And while we muddle through nightmares to satisfy our conscience, we begin to feel that are we really software professionals or slaves of our own enthusiasm.
Guess this post is starting to get a bit long so I estimate to write some more in another post.