BUFD, NUFD and RUFD

By Eugenio, on August 19th, 2009

Venice view from Canaletto

This post is a small contribution to a great presentation from InfoQ.com pointed out by Herding Cats. Moreover, there is a nice comment from Better Projects.

Where Up Front Design (long terms technical plans made at project’s beginning) are conjugated with all possible cases:

Big design. All roots of risks (in particular changes in requirements) are carefully reduced. The OBS –and related financial support – shall be strong enough to supply the necessary workforce that would cover any possible issue.
No design at all. The gap between the requirements and available resources tends to nil.
Relative design. Strong foundations are well entrenched for allowing tactical adjustments.

Criticizing the big design

James Coplien & Kevlin Henney are smart and experienced developers (and leaders as well). Their ideas are based on the “Agile” concept of organizing the production for making easier to accept modification until the latest moment.

This viewpoint will find strong advocates in those customers, who need short time-to-market approach. Therefore, risks related to increasing budget can be reasonably accepted in view of maintaining unchanged the delivery date, scope and quality.

The limits of “beautiful” design

The idea of designing all details (RUP), leaving the simple act of coding to the developers, could be considered as an evolution of the “Big design”. In fact, there should be more interactions with customer, who should be enabled to judge the correspondence of designs with their requirements. To support this viewpoint, they cited L.B. Alberti – who warned architects about the risk of drawing a “would be” reality, instead of spending energy on “mechanical” concepts (those which make a structure working).

In their viewpoint (confirmed by my experience) this approach has two big weaknesses:

This is based on the assumption that the customer can read and go through scores of even more complex diagrams.
The creativity of developers is nullified, increasing the chances of risks either caused by lack of adherence of the design to the “hard” reality of coding; or different results produced by misunderstanding between analyst and developers due to the lack of intelligent human interaction.

No design at all

The only reasonable scenario offered is produced when developers have experience (technical skills and domain’s knowledge) enough for dealing with the “new” project without the need of a plan produced by an “external” analysis.

Missing this condition, the result is a failure.

Strong pillars, smaller creativity and continuous interaction

After a “short” period of inception, the architect (senior developer) starts to write down the necessary (working) code for creating the fundamental (abstracts) classes. Once, these objects are tested for responding to the major customers’ requirements. This enables the (junior) developers to work within a working and dedicated frame where they can tackle the details and accommodate the changes requested during the development.

Conclusion

Given the uniqueness of the projects, this classification offers a good system for understanding the correct (technical) approach. However, the choice shall be taken considering the real options available.

A thorough and impartial assessment of the available resources (that starts from the senior management) is the unavoidable process that shall precede and strongly influences the organizational and then technical choices.

“All generalizations are false, including this one.”