But not a "hack" job. I've got a mere 7 years experience in the software world stemming from a traditional engineering background and I've seen projects that were "on time" and projects that failed miserably. The problem is EXACTLY the same as any other engineering problem if you choose to look at it that way.
OK, I'm going to dive into the classic analogy to traditional engineering: the bridge project. Nobody ever answers the question "How long will it take to build a bridge?" right off the bat. Every aspect of the project is scrutinized and estimated separately. In other words, to build a bridge we need to do A., B., C.,...etc. Each task is then estimated along with the dependencies on other tasks and how an overtime task affects other tasks (Pert and Gant charts are dreamy for this). In the end you come up with damn accurate estimate of how long it's going to take along with heuristics that describe what external can make a difference and how big that difference will be.
Now, back to the software arena. There is a big difference between a software developer and a software engineer. Software developers "hack" or piece together code that works, but there's been no real analysis done to support it (my definition - feel free to argue). Software developers are comparable to general construction contractors. For example, a contractor may build a deck without much analysis (i.e. how will it behave in an earthquake; what is it's failure temperature, etc.), but a major structure (like a bridge) requires an in depth analysis.
A software engineer, on the other hand, follows a much more rigorous analysis and design technique that can be used to estimate the overall time a project can take. To do this, one doesn't estimate how long it's going to take to build the entire project. Rather, one should divide the task into sub-tasks and continue to do that until one ends up with tasks that are estimatible with a defined region of uncertainty.
To do this, a certain amount of design needs to occur. Admittedly, the estimate for the design can sometimes be a shot in the dark. But, a good design can give not only a good estimate of the time required to complete a project, heuristics about the end product can be determined from the design. IMHO, the coding becomes an afterthought, a footnote to a good design.
It seems to me that this whole situation is just like any other utility that has an interupt in service. If the phone lines to my house go down due to a wind storm, I don't expect a refund. I expect that the phone company to fix it promptly, but I don't expect a refund. Any thoughts?
Slashdot Mirror
But not a "hack" job. I've got a mere 7 years experience in the software world stemming from a traditional engineering background and I've seen projects that were "on time" and projects that failed miserably. The problem is EXACTLY the same as any other engineering problem if you choose to look at it that way.
...etc. Each task is then estimated along with the dependencies on other tasks and how an overtime task affects other tasks (Pert and Gant charts are dreamy for this). In the end you come up with damn accurate estimate of how long it's going to take along with heuristics that describe what external can make a difference and how big that difference will be.
OK, I'm going to dive into the classic analogy to traditional engineering: the bridge project. Nobody ever answers the question "How long will it take to build a bridge?" right off the bat. Every aspect of the project is scrutinized and estimated separately. In other words, to build a bridge we need to do A., B., C.,
Now, back to the software arena. There is a big difference between a software developer and a software engineer. Software developers "hack" or piece together code that works, but there's been no real analysis done to support it (my definition - feel free to argue). Software developers are comparable to general construction contractors. For example, a contractor may build a deck without much analysis (i.e. how will it behave in an earthquake; what is it's failure temperature, etc.), but a major structure (like a bridge) requires an in depth analysis.
A software engineer, on the other hand, follows a much more rigorous analysis and design technique that can be used to estimate the overall time a project can take. To do this, one doesn't estimate how long it's going to take to build the entire project. Rather, one should divide the task into sub-tasks and continue to do that until one ends up with tasks that are estimatible with a defined region of uncertainty.
To do this, a certain amount of design needs to occur. Admittedly, the estimate for the design can sometimes be a shot in the dark. But, a good design can give not only a good estimate of the time required to complete a project, heuristics about the end product can be determined from the design. IMHO, the coding becomes an afterthought, a footnote to a good design.
OK, I'm done ranting. Start the flames.
It seems to me that this whole situation is just like any other utility that has an interupt in service. If the phone lines to my house go down due to a wind storm, I don't expect a refund. I expect that the phone company to fix it promptly, but I don't expect a refund. Any thoughts?