Channels ▼


Dr. Dobb's Agile Newsletter

In This Issue

  • Counteracting the False Arguments for Big Modeling Up Front (BMUF)
  • Hot Links

Counteracting the False Arguments for Big Modeling Up Front (BMUF)

I've been modeling on IT projects since the 1980s and as a result seen a very wide range of approaches. I've seen modeling done wrong far many more times than I've seen it done right, and more often than not the professional modelers around me thought things were going perfectly fine when the project was clearly failing. I've also heard a lot of modelers complain about how everyone else in IT needed to conform to their vision and how it would be a much better world if they did (to be fair, all specialists seem to make this claim at one time or another). Maybe they're right, but I've been hearing this same stuff for over 20 years now so I'm a bit jaded.

The fundamental mistake is that many traditional modelers equate modeling success with project success and that isn't necessarily the case. In the traditional world modelers often come in at the beginning of a project, do their work, typically do very good work I might add, and then move on to the next project long before the current project is finished. Months or years later the traditional project often fails, or at least comes in very late and over budget, and the modelers are surprised because things were going so well at the beginning. The modelers did a great job, they explored the problem from different points of view, took the "big picture" into consideration, and provided detailed guidance for the rest of the development effort. The problem is that for all the rhetoric about the importance of looking at the big picture, of understanding the problem domain, and so on that modelers rarely seem to apply their inquisitive gaze back on themselves. If they were to do that they'd quickly discover that their assumptions about how software development should work don't appear to work out very well in practice.

Traditional modelers assume that it is desirable to model the problem and solution domain in detail at the beginning of a project. I refer to this as "big modeling up front (BMUF)", something which encompasses "big requirements up front (BRUF)" where you create a detailed requirements specification early in the lifecycle and "big design up front (BDUF)" where you create a detailed requirements specification early in the lifecycle. These practices make sense when you're a modeling specialist, and sure enough traditional modelers always have seem to have good reasons for why BMUF is desirable. My experience is that these reasons invariably prove to be false, and here is the ammunition that you need to counter these invalid justifications.

False Argument #1: We can think things through up front

I've lost track of the number of people who have told me that specify the requirements up front and "get it right". After a little bit of investigation I invariably discover that they're bullying their stakeholders into not changing their requirements. This bullying often takes the form of a traditional change management process, something that would be better named a change prevention process. Traditionalists will often make it so difficult to change requirements that stakeholders often give up in disgust. Not realizing this, the traditionalists will claim that they've done a great job at identifying requirements up front and will often question why other IT professionals cannot do the same. It isn't that we cannot do the same, it's that we know better.

False Argument #2: The bridge analogy.

The bridge analogy generally goes like this: "Building a bridge is a very complex thing, just like building software. Bridge builders create complex blueprints up front and then work to those plans, therefore we should do the same thing too." If someone doesn't have direct experience building bridges and building software then shouldn't we question their assumptions? I know some physical architects, and they work in a far more creative and evolutionary manner than you might think. To see a world-class architect in action, I highly suggest watching the documentary "The Sketches of Frank Gehry". I can very safely say that Gehry is an agile modeler, not a traditional one. So, perhaps the bridge analogy does hold, but not in the way that traditionalists think.

False Argument #3: Stakeholders know what they want.

Have you ever tried to fully specify your design when you are decorating a room in your home? No matter how much effort you put into it, you'll always discover that the couch is at the wrong angle, that the wall art doesn't work with the area rug, and so on. You always have to adjust your design and sometimes even make major changes. If you can't do something as simple as specify up front the decoration of a room, what makes you think you can do the same for a system which is many orders of magnitude more complex? People don't know what they want; at best they may understand their goals/intent. People are very good at saying what they don't like, and providing suggestions for possible improvements. This implies the need to take an evolutionary approach where you obtain feedback on a regular basis, not a serial, documentation-based approach. This assumes of course that you actually want to build a system which reflects the needs of its stakeholders.

False Argument #4: Comprehensive documentation adds value.

This argument might be partly true, although writing comprehensive documentation early in the lifecycle is the wrong time to do it. Agile Modeling recommends that you write documentation only when the information being captured has stabilized AND if someone understands and is willing to cover the total cost of ownership (TCO) of that documentation. You don't want to document speculative things, and documenting requirements and proposed designs early in the lifecycle are clearly speculative, because speculative things have a tendency to change and thereby increase your TCO for that documentation.

False Argument #5: There's no proof evolutionary techniques work.

The alternative to working in a serial manner is to work in an evolutionary (iterative and incremental) manner, one aspect of agile software development. Traditionalists will claim that there isn't any proof that these approaches work, yet that simply isn't true. Several studies have in fact shown that evolutionary techniques are superior to serial approaches and there is ample anecdotal evidence. When people ask for "irrefutable evidence" what they're often saying is that they don't want to move away from their preferred way of working. Traditional approaches were adopted with far less evidence than what we have today supporting evolutionary approaches, and to be quite blunt I think that the traditional track record speaks for itself -- the evidence, if you're willing to accept it, clearly points way from BMUF.

Modeling is important to professional modelers, but to generalizing specialists with a wider range of skills it's only one of many important things to do. Specialists are always convinced that their specialty is far more important than it actually is in practice, and I find that when it comes to process-related matters that it's far more valuable to listen to people who have a range of options as opposed to people who are narrowly focused on their favorite strategy.

Hot Links

Read about the Big Modeling Up Front (BMUF) anti-pattern.

Examining the Big Requirements Up Front (BRUF) Approach explores some of the evidence as to why writing a requirements specification early in the lifecycle proves to be a bad idea in practice.

Answering the "Where's the Proof that Agile Methods Work?" question does exactly what the title claims.

The Sketches of Frank Gehry is a wonderful documentary showing how Gehry, one of our generation's greatest architects, works and thinks.

Read about The Change Prevention Process Anti-Pattern.

The Agile Alliance homepage is the best starting point for anyone interested in learning more about agile software development.

In Agile Architectural Modeling, I describe a collection of agile strategies for architectural modeling

The Agile Models Distilled page provides links to overviews of a wide variety of models.

Read about the principles of Agile Modeling v2.

Read about the practices of Agile Modeling v2.

Check out the Agile Modeling mailing list.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.