Design

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.

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.

Video

This month's Dr. Dobb's Journal

This month,
Dr. Dobb's Journal is devoted to mobile programming. We introduce you to Apple's new Swift programming language, discuss the perils of being the third-most-popular mobile platform, revisit SQLite on Android
, and much more!