“Postmodern Project Management,” an article released in Defense AT&L in May of 2008, makes a convincing argument for why modern project management philosophy fails to help projects reach success [1]. As software architecture is largely a tool to facilitate communication and provide guidance for a project, it is not difficult to see parallels between current and emerging trends in software architecture with the idea of modernism vs. postmodernism project management practices. Tell me if these sentiments don’t ring true for the upfront vs. emergent design approaches.

Modernism is indeed an effective approach for a rational, static world where surprises are rare, measurements are precise, humans are tools, and our understanding of the system dynamics is very nearly complete. If the PM’s world was linear and predictable, then Modernism would work just fine. But the reality is, reality is messier than that. Things change unexpectedly, surprises surprise us, people are people, and the system dynamics are both unstable and nonlinear. In this sort of environment, Modernism breaks down.

Modernist project management refers to taking a rational, calculated, purely scientific (some might say cold) approach to managing people and projects. By extension, modernist software architecture approaches designing a software system in a similarly rational, calculated, and scientific way. The object of modernist software architecture is to create a process by which great software architecture designs can be consistently and predictably repeated by any team working on any project. The best example of modernist software architecture comes out of the excellent work and research from Software Engineering Institute.

Postmodernist software architecture on the other hand aims to inject some humanity into how we approach the architectural design and ultimately implementation of a software system. In other words, postmodern software architects acknowledge that no matter how much we plan or how good our models are, we can’t predict everything as the modernist software architect attempts to do [1].

For us normal folks, [Postmodernism] can be understood as a worldview that is skeptical of Modernism’s certainties. Postmodernism doesn’t necessarily deny Modern certainties—it just questions, examines, and deconstructs them, investigating the underlying assumptions, particularly when those assumptions are flawed, hidden, ignored, or otherwise not made explicit.

Historically most software architects (and developers in general) tend to approach the design of a complex system in a rational, linear way:  first you gather requirements, then you create a model (which precisely defines the solution), then you verify your model before finally starting implementation. In my experience this approach works extremely well – until things change (and change they always do). Models are imprecise by their very nature and it’s easy to forget important details or get details wrong. Changes happen throughout the life of a project – requests from customers, risks becoming problems, even changes you would have never expected.

When changes happen, the modernist approach to software architecture crumbles. All that documentation, all those models, all that analysis – these carefully laid plans become not only useless but also a burden and a resource drain. Over time systems built by relying too heavily on models constructed through a rational process become rigid and the quality decreases. This is not to say that models are bad. When dealing with something as abstract as software architecture models are essential. It’s how the models are created and how we use them that make postmodernist software architecture work better.

Change is an opportunity to deliver even more value to customers and users. Postmodernists react with confidence and excitement (and a healthy dose of skepticism as any architect modernist, postmodernist or otherwise should before evaluating trade-offs) where modernists react with pessimism, frustration, and disappointment. But lightweight representations are only part of the story. By recognizing that people are not interchangeable and that all humans are inherently flawed, postmodern architects naturally tend to design systems that are more flexible, testable, and maintainable. By not only allowing change but embracing and encouraging it, architectural drivers can evolve and converge more rapidly, actually shortening the “period of uncertainty.”

Faith in the power of individuals and accounting for their humanity is what makes postmodern software architecture so powerful. No amount of up front system analysis will ever change human nature.  And as architects we can never forget this when designing systems.

[1] Maj. Dan Ward, USAF, Maj. Chris Quaid, USAF, and Capt. Gabe Mounce, USAF, “Postmodern Project Management”. Defense AT&L: May-June 2008.  [Being a defense journal it's no wonder that I missed it (thanks to the Rogue Project Leader for pointing it out!]

Extreme Programming’s system metaphor, as traditionally presented, has a fatal flaw. It has a nudge which encourages teams to describe the system at too high a level, as one large monolithic thing. The result is nearly always the same: a generic metaphor that doesn’t really describe the software and provides next to no guidance for implementation. This has led many in the Agile community, including Kent Beck, XP’s creator, to abandon the system metaphor entirely. I have three big worries with this.

1. While Beck may have changed his mind about many practices from XP, both versions of Extreme Programming, available in two editions of Extreme Programming Explained, are readily available and actively promoted by the publisher.  Treating both editions as equals curbs the adoption and spread of better practices.  The metaphor lives on in spite of being abandoned by its creator.
2. Agile teams, while improving, have been generally slow to adopt now common knowledge on software architecture.  Deemphasizing the system metaphor has created a black hole in the software lifecycle around architecture and design.  Those teams that are software architecture-focused have a hard time figuring out how to remain agile while incorporating architecture best practices.
3. Metaphors aren’t going anywhere.  They are a natural reaction to describing complex things – in literature, in life, and in software.  Ignoring the system metaphor makes it more difficult to use effectively.

So rather than fighting the metaphor as a tool for describing software architectures, we should embrace it.  It’s time to refresh the system metaphor by combining current best practices from software architecture with what we know works for metaphors in literature.

The System Metaphor, Refreshed

The ultimate goal of the system metaphor is to create a common vision and vocabulary for discussing and reasoning about a system – with all stakeholders.  This stands for the refreshed system metaphor too.  Communication is king in the abstract world of software architecture, and so communication is the ultimate metric for determining whether a system metaphor is good or bad.  Metaphors that enhance communication are better than ones that confuse or mislead the team.

To this end, there are five guidelines for evaluating metaphors to determine their fitness as aids for describing software architecture, and one corollary for sharing and using metaphors.

A good metaphor:

1. Represents a single view.
2. Deals with only one type of structure.
3. Gives clear guidance concerning design decisions.
4. Sheds light on system properties.
5. Draws on a shared experience.

The system metaphor is one of the 12 key practices from XP and it is probably also the most controversial. Researchers at the Software Engineering Institute have observed that, of all the practices from Extreme Programming, the system metaphor is used the least. Other research done on graduate students at Carnegie Mellon concluded that natural language metaphors are useless for either communication or architecture design.

These are damning findings for the system metaphor, and yet on nearly every technical team with which I’ve built software, natural language metaphors were a daily part of how we communicated with each other. Maybe it has to do with the inherent abstractness of software, something that can’t be touched or tasted, only described. Maybe my teams have simply lacked the technical vocabulary needed to communicate in more precise words.

In spite of this nearly all of these projects were successful. Certainly there must be some merit in using natural language metaphors to describe a software system?

This got us thinking. Metaphors frequently come up in our everyday lives quite naturally and they are used effectively in books and movies. Is there something special about software that makes metaphors not work? Why would folks have such a hard time applying the system metaphor in practice when it’s obvious that metaphors in general are so effective in other places throughout our lives?

The simple answer is that we’ve been doing it wrong this whole time.

There’s nothing wrong with the system metaphor. It’s our application of the technique that has been wrong.

What’s missing from the prevailing literature on the System Metaphor is clear guidance that shows what a good metaphor should look like. Without this guidance, and without the background in software architecture to backfill this knowledge, teams are left alone to cobble together our own metaphors based on the limited information available on the Internet; a web of information that is largely an echo chamber of the same few sentences from the XP book. It should be no wonder that the system metaphor is unsuccessful in many cases.

What does a good metaphor look like? How do you know if you’ve created an effective metaphor? When should you create or update a metaphor? Why is one metaphor better or worse than another metaphor?

In looking for answers to these questions we combined what we knew about literary metaphors and software architecture practices to come up with a clear set of guidelines for the System Metaphor. These guidelines completed the System Metaphor definition and provided us with the guidance we needed to effectively design, analyze, and communicate the architecture of the software system we were building. We were no longer fighting our natural tendencies to create metaphors but instead were embracing them. And we created a more solid architecture as a result.

Interested in hearing more? If you’re going to Agile2011, why don’t you come to hear my talk? During this session I will explore our six guidelines for making better metaphors and walk through examples from our project. In only 30 minutes you’ll learn how to make metaphors that matter to your project, your team, and the system you are building in a way that improves team communication and encourages architectural thinking. This is a session you won’t want to miss!

As I’m writing this I am making final preparations to leave for Trondheim, Norway to present an experience report at the 11th International Conference on Agile Software Development and Extreme Programming, or XP2010. After my experience report was accepted, the conference organizers opened up a second round for lightning talk proposals, and in a moment of whimsy I decided to propose another talk. That was accepted as well. So I’ll be giving two talks at XP210.

If you’re at the conference I would very much like to meet you! This is my first time presenting at a conference and only my second conference attended (my first was OOPSLA this past October) so I’m a little nervous and unsure what to expect. Above all I hope that I’m able to share some information that is useful, interesting, and inspirational. I think I have some interesting insights and perspectives that can help make the way we build software just a little bit better and I want to hear your opinions, your thoughts and experiences too. If you can’t make it to my talks, come find me, I’d be glad to discuss any ideas with you. I plan to have a copy of the paper and slide decks available on this website along with a brief synopsis of the talks shortly after the conference. And of course I’ll be looking for people to eat meals with and hang out while I’m here on Wednesday and Thursday. I’m here to present, to learn, and to discuss cool ideas with other practitioners.

Here’s a summary of the two talks I’m giving along with some background information. The background isn’t necessary but just interesting information and context related to the talks.

Put it to the Test: Using Lightweight Experiments to Drive Process Improvement

This experience report tells the story of how my team ran a lightweight experiment to figure out whether we should use pair programming or program alone and review our code with Fagan inspection. With only a few hours of work and only a few weeks time we discovered that pair programming was instrumental to our eventual success.

In this talk I will discuss what we learned about setting up and running the experiment so you can run lightweight experiments of your own on whatever topics your team finds most interesting or pressing. Experimentation doesn’t have to be this overbearing, lofty, academic thing that it has become. My hope is that teams around the world will use this technique to discover just a little more about how software engineering works and that they’ll share what they learn in white papers, blog posts, and future experience reports. We can help close the gap between research and industry with just a sprinkling of scientific thinking.

Background Information

• Paper and talk abstract
• Pair programming experiment work plan as executed by the team (archived)
• Square Root’s team reflection blog
• A brief analysis of why pair programming seemed controversial to the team while we were planning.
• Complete Square Root project archive (You’ll find data from the experiments along with tons of context information on the project. This is a very raw archive, but there’s tons of great data if you’re willing to root around.)

Lessons from a Software Engineering Dojo: The MSE at Carnegie Mellon University

At OOPSLA in Orlando, Florida this past October I heard proclamations like this more than a few times: “The only way to teach software engineering is through experience. What we really need is a software engineering program that uses a capstone project, a non-trivial, long term project that lets you practice what you learn. No university programs currently have such a project in their curriculum.” I agree. In fact, I agree so much that I attended the only university in the world in which a long-term, realistic (in both scope and complexity), team-based capstone project is an essential part of the software engineering curriculum.

I have two goals with this lightning talk. First, I aim to spread the word about the existence of the Master of Software Engineering program at Carnegie Mellon University. Carnegie Mellon is on the forefront of software engineering education research and the Master of Software Engineering program has been teaching professional software engineers to become true masters in the field for over 20 years. Second, since the studio component (the capstone project) of the MSE degree is so similar to an industrial setting, there’s a lot industry teams can use for training and educating software engineers as you work. There are tons of lessons that can be taken from the MSE in the form of both research and battle tested experiences. This second goal will be the greater emphasis of the talk.

Background Information

• Lightning talk abstract
• The 9 crafts of software engineering proposed by Alistair Cockburn
• Master of Software Engineering homepage
• Wikipedia entry about the MSE program
• MSE studio projects archive