OK, I think we've got enough data to not be confused about your examples. I'm not totally sure. Here's how I understand it: 1. Both Project A and Project B did incremental development. 2. Both hit a snag at detailed design review for increment 1 that required starting over. 3. To get to detailed design, Project A took about 65% of the increment 1 budget. 4. To get to detailed design, Project C took about 20% of the increment 1 budget. OK, we don't fire everybody on Project A. That comment came from the (mis)understanding that they burned 65% of the PROJECT budget to get to detailed design, and still hadn't communicated with the customer well enough to find the time bomb. I'm still not sure I totally understand. You said that, at nominal detailed design for the first increment, Project C had "a first iteration of the finished product." That is, they developed the first iteration of their system before they developed the first increment of their system. But that wasn't prototyping. I hope you can see why I find that confusing. Here's how I understand it. Project A did a formal waterfall within the increment. This makes it credible to spend around 65% of the increment's budget to get to detailed design review. Project C developed one or more versions of their system, or of some critical components, rapidly and without a formal design phase, before their nominal detailed design review. They showed these to the user, intending to throw part or all of them out if the user response indicated that radical rework was needed. They used these prototypes as their design documentation. Overall, I would say that your company should learn a couple of important lesson from Projects A and C: - Develop key elements of the design early and verify them with the user. - Simplify your design approach for early increments. This doesn't require you to do sloppy work, just do less work; be aware that your early analysis and design are tentative and likely to change. Both of these can be done with Ada. It's commonplace for key elements to be prototyped (or pre-developed, or fast-tracked, or done in research implementations, or -- pick your own word). This is done during design or even requirements analysis, using Ada or any other language. We did this for the Space Station Training Facility. It's something that people have been doing since before computers existed (although not for software, of course). And Ada's constructs for modular design (packaging and child packages) make it simple to carve out pieces for pre-implementation, even before you know the overall design. Hurry-up development is an engineering decision. I'll grant that less-formal development is not "textbook method." Textbooks exist to explain formal methods, and the language features that support them. But it's certainly possible to work less formally in Ada. And, it is NOT bad engineering. Bad engineering is using the WRONG level of formality, too low or too high, for the job at hand. It does take experience to know when to apply the methods and use the features. Here are a few pointers: - If your system is simple enough, you can skip formal pre-coding design. You represent your design decisions in code, building up your understanding of the system as you code. Ada gives you some good facilities for breaking out work into units (packages) that reflect your current idea of how the system will work, and that are easy to reorganize when that idea changes. - Ada lets you document your design ideas in code in ways that let the compiler help you keep your thoughts straight, which usually gets you to a WORKING version faster. - There are shortcuts, like documenting design intent with subtypes of standard types, instead of creating new types. This will still locate errors for you when data goes out of range, but it lets you mix different kinds of data freely. If you're having problems, you can turn a limited subset of your subtypes into full types -- the compiler will then force you to document all your type mixing, and you may well debug your problem before you run another test. Actually, this isn't so much a trick as a matter of learning when to create new types. Most new Ada coders -- perhaps most Ada coders -- create way too many new types. Approaches to incremental development have been in the Ada literature for years. I believe there have been articles through the years in ACM SigAda's Ada Letters. I know I have seen others, at conferences and what-not. Perhaps the Ada-oriented folks there have been tending their own rosebushes and not working to stay current. (I've had that problem myself.) Or perhaps they'd jump at the chance to show how flexible they are, but nobody has tried it with an Ada project. But, if I understand your example projects correctly, you have a people issue or a management issue, not a language issue. If all the Ada users in your company are dedicated formalists, and all the C users are dedicated informalists, then you'll get the dichotomy you described -- but it's due to the people, not the language. Best, Sam Mize -- Samuel Mize -- [log in to unmask] (home email) -- Team Ada Fight Spam: see http://www.cauce.org/ \\\ Smert Spamonam