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 ▼


Dr. Dobb's Agile Update 09/09

In This Issue

  • The Theory Needs a Strategy
  • Hot Links

The Theory Needs a Strategy

Ivar Jacobson wrote an article entitled In Need of a Theory for Software Engineering which compared the IT industry with the fashion industry. It started with the observation that sometimes it seems that it's more important to many IT practitioners that they follow the latest software development fashion, such as a new methodology or cool new technology, than it is to produce great software. People will often discard existing strategies which they know to be good in their zeal to adopt the new, more fashionable ones. Pity the poor developer who admits to programming in COBOL, or applying a modeling notation with the word "Unified" in it, because they very obviously aren't up to speed on the latest IT trends. Jacobson points out that this constant pursuit of the latest IT fashion, of the next new thing, results in wasted effort. Frustratingly, many of the "new" ideas and technologies are really just existing ideas and technologies that have been modified slightly and then repackaged.

In August Bertrand Meyer extended Jacobson's position in Methods Need Theory. He believes that there is a "bad politics" aspect to the problem that we face because the emphasis is rarely on substantial solutions to hard problems but instead on slogans, propaganda, and emotions. For example, consider all the rhetoric within the agile community about the importance of processes being empirical, rhetoric typically spewed by people who rarely seem to have actual data to share with us. How about slogans such as "potentially shippable software every sprint" (who can argue with that?) and catch phrases such as BDUF, TAGRI, and YAGNI? Meyer points out that these concepts are marketed like brands, spread by gurus who often downplay or simply ignore existing concepts that are often incredibly similar to the platitudes they espouse, or that when they do recognize of the work of others it is to berate it. Houston, we have a problem.

The IT industry can clearly do better. When it comes to software methods, Jacobson and Meyer suggest three strategies:

  • First, as an industry we should model the nature of software methods in a method-independent manner which describes the problem, not the solution.
  • Second, we should find the kernel, what they refer to as "the mother of all methods", in recognition that all software methods share a common set of properties.
  • Third, describe each interesting method using the kernel. With the kernel in place, all methods can be described and compared and we can harvest the implicit practices from widely used and proven methods.

By doing so perhaps we can stop focusing on the "process wars" and instead focus on what we should be doing -- providing great solutions which support our stakeholders.

This is wonderful vision, but without an implementation strategy there is little chance that we'll see it come about. I believe that there are six critical success factors:

  • Creation of a working group. From Jacobson's and Meyer's description it sounds like there's a fair bit of work to do. Who's going to do it? Will this be a private effort or a public one? Will there be some sort of organization formed or will the effort be ad hoc? Will this work be done in some sort of open source manner, commercial manner, or somewhere in between? Can we leverage existing sources of practices such as the Eclipse Process Framework (EPF) or do we need to start from scratch yet again?
  • Production of an initial set of suggested practices. Visions are one thing, having some a kernel of practices for others to consider is something completely different. The proof of the theory will be in the practices pudding.
  • Experimentation and evolution. People in the industry, ideally people not actively involved with the working group, need to apply whatever the working group produces. There must be a mechanism in place to provide feedback and to more importantly evolve the work.
  • Broad support of industry groups and vendors. Groups such as the International Association of Software Architects (IASA), the International Institute of Business Analysts, and the Project Management Institute (PMI) already have bodies of knowledge. Vendors such as IBM have process repositories such as Rational Method Composer (RMC) and Microsoft has the Microsoft Solution Framework (MSF). These organizations can either be competitors or they can be working partners. I propose the latter, but how can we motivate them to get involved?
  • Funding. This isn't going to be cost-free, even if it ends up being an open source effort developed completely by volunteers.
  • Marketing. All of this will come to naught if practitioners don't know about it. Even viral marketing campaigns start somewhere.

The idea of having an acknowledged collection of common software practices which can be leveraged by practitioners is a good one. Sadly, it will be a difficult one to achieve, as our previous track record suggests. In the early 1990s the patterns community developed a collection of process and organizational patterns, but these patterns were overshadowed by design patterns and never really caught on even though there was some solid ideas captured. About the same time the Unified Process, which Jacobson was intimately involved with, fared better but also didn't achieve all of its goals. Although a wonderful repository of process information, it was driven by a single vendor (IBM Rational, my current employer), implemented far too heavily in too many organizations (although some implemented it in a very agile manner), and grew large over time (which is what happens when you try to cover a wide spectrum of situations). The Object Management Group (OMG)'s Software Process Engineering Metamodel (SPEM), similar conceptually to the "method model" suggested by Jacobson, is a great piece of work that has proven to be of interest to only a small handful of people. So, if we're to learn anything from history, it's that there are many potential challenges which this effort will need to overcome.

In short, Jacobson has shared an exciting vision of the future with us, at least it's exciting for anyone such as myself who is interested in software process. My fear is that this is a vision which will be very difficult to achieve in practice. Together, as a community, I hope we can pull it off. Time will tell.

Hot Links

Ivar Jacobson describes his vision in much greater detail in his blog posting In Need of a Theory for Software Engineering

Bertrand Meyer's Methods Need Theory. reiterates and extends Jacobson's vision for a common method theory.

I recently wrote Our Integrity Debt Continues to Grow, a detailed blog posting which examines the ethical challenges surrounding certification schemes within the agile community.

The Eclipse Process Framework (EPF) is an open source project which has developed method authoring and publishing tooling as well as a collection of agile processes and practices using said tooling.

The Surveys Exploring the Current State of Information Technology Practices page links to the results of all the Dr. Dobb's surveys which I've run over the years.

My [email protected] blog discusses strategies for adopting and applying agile strategies in the complex environments.

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.