An article by Walker Royce of Rational, The Case For Results-Based Software Management, contained a few things that I agree with, and some that I don’t. Quotes:

There’s little uncertainty about the steps or the eventual outcome in the construction industry, for example, where the laws of physics, properties of materials, and maturity of building codes and practices are established engineering disciplines. Success simply depends on resource management and proper execution of the plan.

But in the software industry, these traditional methods cause a huge percentage of software-development projects to founder. [T]he success rate for software projects following this approach (typically called the waterfall model) is about one in 10. [–––]

One reason for such a low success rate is that traditional project-management approaches do not account for the level of creativity often required to complete software projects [–––]

What we’ve learned is that software management is better described in terms of “software economics” than “software construction” or “software engineering.” Day-to-day decisions in software management are about value judgments, cost tradeoffs, human factors, macroeconomic trends, technology trends, market strength, and timing. [–––]

Delivering innovation on schedule and on budget requires iterative life cycles, constant risk management, objective oversight, and a “steering” style of leadership that demands creativity throughout the team, however large or small. [–––]

Build the architecture first. [This is part of his 10 principles of results-based software development.] An early focus on the architecture results in a solid foundation for 20% of the stuff (requirements, components, user interactions, project risks, etc.) that drives the overall success of the project. Understand the architecturally important things and stabilize them before worrying about the complete breadth and depth of all the artifacts, and you’ll see far less scrap and rework over the course of the project. [–––]

When software projects do not succeed, the primary reason is usually a failure to crisply define and execute these two stages [of “research-and-development” activities and “production” activities], with proper balance and appropriate emphasis. [–––]

By contrast, successful projects tend to have very well-defined project milestones in which there’s a noticeable transition from research attitude to production attitude. Earlier phases focus on achieving functionality; later phases revolve around achieving a product that can be shipped to a customer.

Regarding building the architecture first: Royce writes that this will lead to you seeing “far less scrap and rework over the course of the project.” Now, this isn’t something that is bad per se. It is bad only if it makes the project take more time, and therefore cost more. The reason that you decide to throw something away is that you have learned of a better way to do it. And this learning is likely to be more profound, as well as more effective, than the one you would have had if you had spent time working on the architecture by creating UML diagrams.

As for what he writes about “a noticeable transition from research attitude to production attitude” – in my experience, the “research attitude” by far constitutes the larger part, so I don’t see why it would be meaningful to distinguish between these phases.

I do agree, however, that it’s important to balance research and production – generally, there’s an overemphasis on production – but these are attitudes that should be switched between many times during the project; in fact, you should switch between them many times every day.

He also writes that a model-based “engineering notation for design enables complexity control, objective assessment, and automated analyses.” So would a tool that analyses the source code as well – such as the Small Worlds tool.