[RogerFGay]

BuckeyeTexan: That's one of the best success stories I've ever heard. When I started reading the post, I was afraid I'd be disappointed with a longer sob story and just be responding to the first couple of sentences.

BTW: If I had, I'd have mentioned there's a big difference generally between project managers who have engineering experience and those who don't. The lines in my article about managers preferring rapid prototypers over good practice - and the one about this leading to longer more expensive projects producing lower quality is from experience. But then, I switched early from being a regular employee to an hourly wage consultant - ethical as I was, I'd try to talk to managers about the don't follow the "twinkle in your eye" ideas about good software - just hurry up and make things appear on the screen being a very bad idea - and after sincerely trying, would accept the situation which I knew would result in much longer contracts. In the world of project work, you have to be a team player.

[BuckeyeTexan]

If you liked that story, sometime I’ll tell you about implementing version control software at the same company. They were using multiple machines with multiple copies of the code as backups and development sandboxes and using the unix date and time stamp for version control. And recompiling code in production.

[Woodman]

The worst projects I have ever worked on were either tested by engineers or business experts. I appreciate everything you have said, but as a quality assurance professional with many years of experience I see a few problems. The biggest downfall to extensive use of reusable code for large complex assemblies is lack of documentation and late defect/issue discovery.

There is a great deal of benefit to using automated tests, they will help insure that positive flows through the code's logic work, and that common error handing routines are sufficient. I have over a decade of OO automated tool experience so I am not panning well constructed automation, but I guarantee you I can break any code tested only in this manner.

In my humble opinion, the path to achieving what you have outlined is:
- Components need to be simplified, documented, thoroughly tested, and rock solid.
- Developers need to be penalized for reinventing the wheel, unless it is truly a better wheel, and then the old wheel should be thrown out.
- QA needs to be brought into the process at inception, not after development has already started.
- QA cycles should not be compressed in order to make up for development overruns (yes I know that I'm dreaming here).
- Project management needs to play a much more active role in projects while they are in flight and learn to close them out when complete to the original scope.
- All major development methodologies are valid and sound if the rules are followed, however most of the time the rules are bent or broken.