Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Channels ▼
RSS

Debunking Modeling Myths

, August 01, 2001


August 2001: Debunking Modeling Myths

Whether you follow a heavyweight method such as the Enterprise Unified Process (EUP) or an agile process such as Extreme Programming (XP), modeling is a fundamental component of software development—unfortunately, it's subject to myths and misunderstandings. These arise from many issues, among them the misguided efforts of theoreticians, the decades of cultural entropy within information technology departments, the marketing rhetoric of software development tool companies, and the modeling and documentation standardization efforts of organizations such as the Object Management Group (OMG) and IEEE. This month, I debunk myths about modeling and propose some corresponding reality checks.

Myth #1: Modeling Equals Documentation
This is very likely the most devastating of all modeling myths, because it provides developers an excuse to avoid modeling entirely. Claiming that they don't want to waste time writing "useless" documentation, many otherwise excellent software developers have become little more than programming hacks, producing brittle, low-quality systems. Furthermore, even many conscientious developers now consider modeling a bore, and avoid learning necessary modeling skills.

Reality Check: The concepts of "model" and "document" are orthogonal—you can have models that aren't documents and documents that aren't models. A sketch on the back of a paper napkin is a model, as is a drawing on a whiteboard, as is a collection of Class Responsibility Collaboration (CRC) cards, as is a low-fidelity user interface prototype built from flip-chart paper and sticky notes. Though these are all questionable documents, they're valuable models.

Modeling is a lot like planning: just as the value is in the planning effort and not the plan itself, most of the value lies in the act of modeling; not the model itself. In practice, your models aren't part of your system's official documentation, and can usually be discarded once they've fulfilled their purpose. You'll discover that there are few models that you actually need to keep—and that's perfectly fine.

Myth #2: You Can Think Everything Through From the Start
This myth is a holdover from the serial mindset that was prevalent in the 1970s and early 1980s, when many of today's managers learned how to develop software. Believers in this myth often invest significant time trying to model everything up-front in an effort to "get it right," attempting to "freeze" requirements before coding begins (see myth #4), causing "analysis paralysis"—the fear of moving forward until your models are perfect. Project teams suffering from this myth often produce significant amounts of documentation instead of what their users actually want—working software that meets their needs.

Reality Check: How do you overcome this myth? First, recognize that you can't think through all the minutiae. Second, recognize that in these environments, your coders probably have little respect for the efforts of your modelers anyway (a reasonable position, considering the fact that your modelers are doing little of actual value), and will likely claim that the models don't reflect the realities of your environment. Third, recognize that no matter how good your initial specification is, it's destined to quickly become out of sync with your code and with itself, even if you do develop your models over time. The fundamental reality is that only your code is ever truly in sync with your code. Fourth, recognize that the iterative approach to software development—one in which you do a little modeling, some coding, some testing, and then perhaps even deploy a small working version of your system—is the norm for software development. It's a fundamental principle of modern heavyweight software processes such as the EUP, as well as agile processes such as XP.

Myth #3: Modeling Implies a Heavyweight Software Process
Project teams who fall for this myth (often related to myth #1: modeling equals documentation) often abandon modeling altogether because the heavyweight process becomes too complex or too burdensome. This can spell disaster for a project.

Reality Check: You can model in an agile manner. Check out the Agile Modeling (AM) homepage for details on developing simple models using simple tools. Furthermore, you can discard your models once they've served their purpose, as well as model on an ad hoc basis (for example, get up from your desk, approach a whiteboard and start sketching). You can model agilely if you choose to do so.

Myth #4: You Must "Freeze" Requirements
This request often comes from senior managers wanting to ensure that they know exactly what they're going to get from a project team. The good news is that by freezing your requirements early in the life cycle, they're likely to get exactly what they asked for. The bad news is that they probably won't get what they actually need.

Reality Check: Change happens. As you develop a system, you change your approach accordingly: Your requirements change because business priorities change and because stakeholders gain a better understanding of the system as they see it emerging. Instead of freezing requirements, thereby risking the success of your project, try to embrace change and act accordingly, as the XP community advises.

Myth #5: Your Design Is Carved in Stone
As with myth #4, followers of this myth want to ensure that every developer marches to the same tune by following "the design," causing developers to either build the wrong things or build the right things the wrong way, to conform to "the design." Alternatively, they may simply ignore "the design," negating any possible benefits of the design efforts. By freezing your design, you're unable to take advantage of knowledge gained as the project evolves. Furthermore, there is great motivation to write significant amounts of documentation instead of actual software, and to use documentation-oriented CASE tools instead of ones focused on implementation that are likely to provide real value to your project.

Reality Check: Expect to develop your design, in part based on feedback from your application developers and database administrators, who often have a better understanding of your technical environment than the modelers. Let's face it: Nobody—even the best designer—is perfect, and neither is his or her work. Do you really want to carve imperfection in stone and not allow yourself to fix mistakes? Furthermore, if you don't freeze your requirements, then by implication, you can't freeze your design—changes in your requirements will necessitate changes in your design. Look at it this way: Your design isn't finished until you've shipped the code.

Myth #6: You Must Use a CASE Tool
Modeling is often seen as a complex effort, one that requires extensive use of CASE tools.

Reality Check: Yes, modeling can be complex, but you can create effective yet simple models that show only critical information instead of irrelevant details.

For example, I often create UML class models that show classes, their attributes and critical business operations, but don't show the accessor (getter and setter) operations for the attributes, the scaffolding code required to maintain associations to other classes, or other "trivial" implementation details. I create the model to think through an issue, allowing myself and my coworkers to move forward and implement what we just modeled. Taking this agile approach, I often don't need a significant CASE tool to support my modeling efforts—a whiteboard and, optionally, a digital camera often suffices. As a result, I don't spend time evaluating CASE tools, nor negotiating licensing deals with vendors, nor training coworkers. CASE tools are fine as long as they provide the best value for your investment in them, but most of the time, I simply don't need one to model successfully. Yes, I'll often use tools such as Together/J (www.togethersoft.com) because it generates significant amounts of Java scaffolding code, and ERwin (www.cai.com) because it generates database schemas. Both of these tools help me to fulfill the true purpose of software development—the creation of software that meets my users' needs. The vast majority of my modeling efforts are still done with simple tools, not CASE.

Myth #7: Modeling Is a Waste of Time
Many novice developers entertain this myth, often because their education slighted the full development process, focusing solely on how to write code, and because their experiences as junior programmers focused solely on implementing code. This is a true shame because these developers are forgoing an opportunity to increase their productivity as well as to learn skills that they can easily transfer between projects and organizations.

Reality Check: Very often, your productivity is enhanced by sketching a diagram, developing a low-fidelity prototype or creating a few index cards, in order to think something through before you code it. Productive developers model before they code. Furthermore, modeling is a great way to promote communication among team members and project stakeholders, because you're talking through issues, coming to a better understanding of what needs to be built and building bonds among everyone involved with the project.

Myth #8: The World Revolves Around Data Modeling
Many organizations hobble their new development efforts by starting with a data model. Often this is the way your organization has always done things; the data community has a political death grip on your IT department and controls your development projects; or your legacy database(s) is such a mess that you have no other choice.

Reality Check: Data modeling is an important but secondary modeling task that is best performed based on your other models (see "Extreme Modeling," Thinking Objectively, Nov. 2000). This holds true even with data-oriented efforts such as data warehousing projects: Without a solid understanding of how people intend to use the data warehouse (something that data models don't show), these projects often end up as abject failures. You have a wide variety of models at your disposal—use cases, business rules, activity diagrams, class diagrams, component diagrams, user interface flow diagrams and CRC models, to name a few—and data models are merely one such model. Each model has its strengths and weaknesses, and should be applied properly. If managers tell you to base your system on a data model, investigate how well they truly understand software development by asking them when to, and when not to, apply the models listed above. If they can't tell you, or if they simply dismiss models as "something the application developers worry about," then it's clear that they lack sufficient experience to advise your project.

Myth #9: All Developers Know How to Model
Our industry faces a serious problem: Most non-developers, including senior management and users, don't understand how software is built. As a result, they can't distinguish between skilled developers and hack programmers—and certainly not between extreme programmers and hack programmers—and tend to assume that all developers have the necessary skills to develop a system from end to end.

Reality Check: This simply isn't true. Modeling skills, for one, evolve with years of experience, and emerge only when a developer chooses to acquire them. As highly intelligent people, programmers often believe they can do anything—after all, they're programmers. Because of this arrogance, they take on tasks that they simply don't have the skills to complete. Because software development is so complex, a single individual rarely has all the skills required to successfully develop and deploy even a reasonably complicated system. Developers need to have the humility to recognize their weaknesses and realize that there's always something more to learn. By working together to complement each other's strengths, modelers can often learn details of a certain technology from programmers, and programmers can learn valuable design and architecture techniques from modelers. My personal philosophy is that everyone—including myself—is a novice.

Toward Agile Modeling
By understanding and eschewing the myths of modeling, you enable yourself, your project team and your organization to develop software effectively. In the process of exploring and debunking these common modeling myths, I've presented many

of the tenets of Agile Modeling (AM), formerly known as Extreme Modeling (XM). I hope that I've given you food for thought.

I'd like to thank Doug Smith of Blueprint Technologies (www.blueprinttech.com) and Gary Evans of Evanetics (www.evanetics.com) on the Agile Modeling mailing list (visit www.agilemodeling.com to join) for contributing to this article. I'd also like to recognize Martin Fowler, Ron Jeffries and other members of the XP community, because I suspect I've incorporated some of their ideas, as well.

Modeling Philosophies

10 ways to ensure mistake-free design

  1. Data models aren't sufficient foundations for modern software.
  2. Embrace change and allow your models to evolve over time—you can't freeze them and hope to succeed.
  3. Models aren't necessarily documents, and documents aren't necessarily models.
  4. Most models can and should be discarded.
  5. Only the code is in sync with the code.
  6. Simple tools, such as whiteboards, suffice for the vast majority of modeling efforts.
  7. Think first, then code.
  8. You can always learn something from others.
  9. You can model in an agile manner.
  10. Your design isn't finished until you've shipped your code.


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.