Maybe projects should be defined in the number of parameters necessary to define it.
If you have a bridge or buiding, the CAD diagram should give you a good estimate of the number involved.
Now consider a small SW project. the number of parameter is a measured by the number of variables. The complexity could be measured by the number of branches. The coupling factor is the extent to which functionality can be broken down to reusable modules.
Basically, my point is that designing a software program should be weighted based on the difficult involved. Most bridge designers would refuse to give you a quote unless he were to spend a good deal of up front time to figure it out, unless he has access data of the same exact conditions. Yet, programmers are expect to come up with estimates in a couple of days, in a world where technology changes faster than Italian fashion. (Consider that in less than a decade, Unix has just given way to Windows, GUI's and event-driven programming popped up, Object-oriented programming has taken off, the internet has become a platform to support, C gave way to C++, gave way to Java, and might be replaced by C#.) That's like assuming that designing a bridge from wood 100 years ago is identical to designing one from steel and concrete now.
In a project bidding phase,
Of course it is like manufacturing, but you only make one [or few] copy of product.
Yes, Windows sells millions of copies, but there are millions of products which sell only one copy.
The manufacturing project which most closely resembles this is the Apollo project. The USA developed an industry which was costing $14B a year in 1968, but only $1B in 1973. The cost of development fell once the process was established and the industry established. But we were no longer working on Apollo by 1974. That works well with gov't money, but ask someone else to take that gamble.
If I develop a project for one client, and then can't sell many copies of it, I can't amoritize my costs over multiple projects.
Its like saying I developed a project for dB2, so all I have to do is calculate the costs of changing the database to Oracle, and hence can sell to more costomers. Well, to change it to Oracle is going to take up 75% of the project, so I might as well start fresh all over again. Maybe I hate the GUI anyway, so I might as well redesign that as well.
In order to write such detailed specs to the point where the coding is trivial will take a lot of time. Is the proposal meant to be developed on one's free time, and hoped that it is amoritized once the project is landed? Many companies bidding on gov't projects really get annoyed when then lose the project, yet have the winner review the other proposals for better ideas.
Slashdot Mirror
Maybe projects should be defined in the number of parameters necessary to define it. If you have a bridge or buiding, the CAD diagram should give you a good estimate of the number involved. Now consider a small SW project. the number of parameter is a measured by the number of variables. The complexity could be measured by the number of branches. The coupling factor is the extent to which functionality can be broken down to reusable modules. Basically, my point is that designing a software program should be weighted based on the difficult involved. Most bridge designers would refuse to give you a quote unless he were to spend a good deal of up front time to figure it out, unless he has access data of the same exact conditions. Yet, programmers are expect to come up with estimates in a couple of days, in a world where technology changes faster than Italian fashion. (Consider that in less than a decade, Unix has just given way to Windows, GUI's and event-driven programming popped up, Object-oriented programming has taken off, the internet has become a platform to support, C gave way to C++, gave way to Java, and might be replaced by C#.) That's like assuming that designing a bridge from wood 100 years ago is identical to designing one from steel and concrete now.
In a project bidding phase, Of course it is like manufacturing, but you only make one [or few] copy of product. Yes, Windows sells millions of copies, but there are millions of products which sell only one copy. The manufacturing project which most closely resembles this is the Apollo project. The USA developed an industry which was costing $14B a year in 1968, but only $1B in 1973. The cost of development fell once the process was established and the industry established. But we were no longer working on Apollo by 1974. That works well with gov't money, but ask someone else to take that gamble. If I develop a project for one client, and then can't sell many copies of it, I can't amoritize my costs over multiple projects. Its like saying I developed a project for dB2, so all I have to do is calculate the costs of changing the database to Oracle, and hence can sell to more costomers. Well, to change it to Oracle is going to take up 75% of the project, so I might as well start fresh all over again. Maybe I hate the GUI anyway, so I might as well redesign that as well.
In order to write such detailed specs to the point where the coding is trivial will take a lot of time. Is the proposal meant to be developed on one's free time, and hoped that it is amoritized once the project is landed? Many companies bidding on gov't projects really get annoyed when then lose the project, yet have the winner review the other proposals for better ideas.