jason cole wrote:
This one's for Andy. I was going to discuss this at Sandown with you, but our company decided not to make an appearance on this occasion.
I have worked on several large software projects, and for each one a different software development methodology has been used on each.
Basically, they fall into two camps, "Get it right first time" and "Prototyping".
"Get it right first time" essentially follows the approach of large engineering projects where the system providers have meetings with the end users before a single line of code is even contemplated, let alone written. Specification documents are written, which can be huge and complex, and they effectively become a contractual basis of what the software is going to do and how it's going to do it. Everything is written and tested before delivery, so the end user has to wait for a long time, possibly years. I worked on one such project where it cost £millions and took 8 years from conception to delivery, and at the end of it all it wasn't quite what the users wanted, and cost more £millions in PDS (Post Development Support).
"Prototyping" aims to get initial delivery as fast as possible to end users. The initial result may be nothing like what the users want, and there will almost certainly be lots of bugs. But the power is there for the users to play with the system and get a better idea on what they want, thus further development is directed towards theie needs. Effectively, PDS starts very early and runs through a far greater proportion of the product lifecycle.
There is the argument that building software is cheap (running compilers etc) as opposed to building engineering projects, which is why a lot of planning has to go into the engineering projects; making a mistake is very costly.
There is also the consumer-goods legacy, with respect to VHS/Beta/Video2000 and IBM PC/Apple Mac. Basically, the better engineered products failed, because they didn't get to the market quickly enough.
You also have to consider market sizes; there is mass-production, medium-scale production and single-user delivery. With mass production, any product development costs are absorbed by sales. With the other market sizes, this is not possible. With the single-user case, every change has to be paid for by the user, and only that user benefits.
With medium-scale production, if one user wants changes done, and he pays for those changes alone, he's at a disadvantage because all of the other users benefit from those changes. If each user has his own version of the product, it effectively becomes multiple single-user, and it would be a configuration nightmare for the supplier. The users would inevitably be worse off, since the supplier could then charge every user the same amount for a single feature, even though he only has to develop it once. It's rather "right-wing". Therefore, a supplier is inclined to charge support to pay for the continued development, since it benefits all customers. It's effectively a "left-wing" ideology, where all of the money goes into a melting pot to benefit all. There are losers in this game as well; those who don't want any development, but they are a minority, and don't have to pay for support.
Just remember that when you buy a mobile 'phone you are paying for a lot of features that you certainly didn't want and would probably never use. However, it would be impractical to have it any other way; the only choice you have is which supplier to go for.
Jase
I thought as much.
Claude