“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!]

Every 5,000 miles or so I take my car in to the shop for an oil change. It’s part of the routine, preventative maintenance I do to keep my car running in tip top shape. Routine maintenance gives me the peace of mind that my car won’t leave me stranded somewhere, extends the life of my car so I’ll get the most out of it, and makes sure my car is always functioning effectively which is extremely important with gas as expensive as it is. Routine maintenance just makes sense – cars are expensive and mine plays an important role in my day-to-day life. So it is only logical that I would want to take good care of my car.

Routine maintenance is good for other things too. I go to the dentist twice a year for a routine cleaning and inspection to make sure my chompers are in good form. I remove the cruft from the gutters on my house once a year so they don’t clog and cause bigger problems. I take my dog to the vet for blood work and a general checkup every year for her birthday to make sure she stays happy and healthy. I don’t want to lose my teeth. I don’t want the gutters falling off my house. I don’t want my dog getting worms or licking my face with bad breath. Regular checkups and maintenance help me avoid these things.

Routine maintenance is important for software teams too. Part of the total cost of ownership for any software development team is the cost of the routine maintenance that keeps that team healthy, happy, and working at peak efficiency. The last thing I want is for my team to break down in the middle of an iteration. Even a team failing to live up to their full potential is something that can be avoided with simple routine maintenance. Burnouts, flare-ups, missed commitments, firefighting – these are all signs of wear and tear that must be repaired to bring a team back to center. Wouldn’t it be easier just to avoid all that though? Preventative team maintenance is the single most cost effective way for ensuring teams have a full and happy life, operate effectively, and won’t break down at critical times such as in the middle of a project.

Teams don’t have oil to change every 5,000 miles, but there are still activities that should be a part of every team’s regular routine maintenance plan. Here are some of the things I’ve found useful on my teams.

Retrospectives and reflection – This is the oil change, the physical, the teeth cleaning of the software development world. Every member of the team gathers to think about and discuss how their practices are actually working for the team and project.

What do I do? At its most basic, a retrospective is a ritualistic, round table discussion where everyone on the team has a chance to share their thoughts and feelings on how the team is doing. Agile Retrospectives” by Esther Darby and Dianna Larson is a great reference for getting started with team retrospectives.

How often? Retrospectives should be done once every iteration, generally at the end. If iterations are long it might be worth considering doing them more often. If using a continuous release schedule, pick a date every 2 weeks to 3 months to reflect as a team even if you use continuous improvement practices.

Exploration – Always doing the same thing day in and day out creates ruts in our minds and spirits. Most people who are great at developing software will get bored if left to do the same things for too long.

What do I do? Toss things up by letting folks try new things. This might include running an experiment with a new technology or methodology, learning or taking full responsibility for a new-to-you team role, or taking on non-development tasks like writing documentation or coaching. Carefully consider risks when exploring and mitigate appropriately to ensure you still satisfy your threshold of success.

How often? This depends on the team. One tool I’ve found useful for understanding how prone to exploration teammates might be is the VIEW Problem Solving Style assessment. Retrospectives coupled with solid software risk management will also help determine the right amount of exploration.

Upgrade tools – Sticking with old and busted when there’s a new hotness available not only makes us feel unprofessional but can also hurt us.

What do I do? Buy the best you can within the technical constraints of your project.

How often? Upgrading doesn’t have to happen with every new release. There is a diminishing return by upgrading too often. Major upgrades that only happen every few years for tools that are your team’s lifeline (like, say, Visual Studio) are a great candidate for upgrades. For less critical applications like Office you might skip releases. And if the team says a tool is critical then don’t give them a hard time – figure out how to meet their needs!

Quality downtime – Vacation and holidays, time away from computers, projects, and even each other helps keep the team fresh and ready for work.

What do I do? Encourage folks to leave the office every once in a while. Part of this is culture – make it OK to go on vacation and *Gasp* not check your email! The big trick is that this needs to be quality time off, not just time away from the office.

How often? At least 4 weeks a year, more is better. That’s enough for the standard American bank holidays plus another 10 days. Time off should be taken in good size blocks, spread out throughout the year (keep in mind that American holidays are sparse throughout the spring/summer), and preferably not interfere with day-to-day team operations. With enough forward notice, anyone should be able to take a vacation whenever they want.

Status meetings (with visible progress) – Check the pulse and blood pressure of the team.

What do I do? Get together to review progress, risks, tasks, sanity, problems, and make sure there are no big surprises. The key here is to get a real sense of the important things the team wants or needs to track. Big visual charts are great for this – use data when possible to show real status. A round table will catch the outliers that can be challenging to measure.

How often? Generally a one hour weekly status meeting is enough, even if you’re already doing daily stand-ups.

Parties, downtime together – Take time to celebrate your successes! A team that parties together is a team that builds great software together. Do things with your teammates other than writing software.

What do I do? The sky’s the limit – happy hours, LAN parties, hikes, concerts, dinners, lunch. You don’t have to have the whole team for every event, but folks should feel comfortable hanging out together. Designate a social committee to come up with fun things to do or make it a team role that moves around.

How often? At least once every iteration or once a month. Just go have fun and you’ll be OK.

What else?

Look, you’re going to pay to keep teams working one way or another. Either you’re team will break down and you can pay to rebuild it (which may not always be possible) or you can set aside the time and resources to do the routine maintenance. You don’t always get to choose when a catastrophic breakdown will happen, but you do have the choice of when to schedule your next oil change. Retrospectives are a no brainer – just do it.

When building relationships we look for commonalities between ourselves and others. When we have things in common it makes us feel good, like we’re not alone in the world. And the things we have in common become the basis for lasting relationships. Homogony in a group brings comfort, you know what everyone else is thinking, you can predict how the group will react to new ideas, and you become confident, even emboldened because you are surrounded by people who are similar to you. Let’s face it, it feels great when you share a new idea to nodding heads of agreement and a strong show of support from your peer group.

Over time you’ll find your niche, a great group of people who think like you and see value in the same things you do. The more time you spend together the closer you’ll become and the more awesome your community will get. You’ll feel supported and you’ll give support to your peers. Together you’ll build an exclusive community of trust, mutual respect, and consensus; one that feeds on itself with demonstrations of perpetual support free of criticism, negativity, and ridicule.

With a large enough group, it’s possible to warp reality around yourself so that you are only exposed to the ideas and feelings produced by your group, the place where you feel safe, comforted, and welcome. With so much support it is easy to dismiss ideas created outside the group as “radical” or “stupid,” and miss out on huge opportunities in the process.

This mentality is everywhere in the software world.

The software craftsmanship movement largely molded by Pete McBreen in his book pitted the enlightened craftsmen against the ignorant engineers. I strongly identify as a software engineer and was duly offended by this book. It wasn’t until about mid-way through the book, when McBreen suggested that the Personal Software Process was one of the greatest processes a craftsman could use that I realized we agreed more than we disagreed. A line in the sand had been drawn and two groups formed but there was more overlap between these groups than anyone was willing to admit. As an engineer I don’t want to “sweep the shop floor” as someone’s apprentice but I recognize the importance of mentoring. Software Craftsmanship highly values the contributions of the individual but recognizes that teams must somehow be organized so projects can succeed. Software engineering (at least as I’ve always thought of it) and software craftsmanship are nearly identical ideas and McBreen’s book reads as a jaded rant produced after an unfortunate project. Two communities with similar passion and ideals, divided by a label!

Agile and architecture are two other groups that (only until very recently) seem to ignore each other out of spite or perhaps ignorance. The main principle of the agile movement is a focus on delivering meaningful software that helps solve customers’ problems: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” The Software Engineering Institute has spent the better part of two decades researching software architecture and how it affects a team’s ability to deliver valuable software to customers. Software architecture is a communication and organization mechanism. The primary purpose is in helping teams deliver software effectively. It is a means to achieving the very same principles outlined in the Agile Manifesto. There’s nothing wrong with documenting a design, writing down quality attribute scenarios in addition to user stories, or making a plan before your start laying down production-quality code. It is true that the wrong kinds of up front design will do more harm than good for all but the most trivial systems, but that doesn’t make all architecture practices as bad as agile zealots will have you believe.

Is Kanban agile? Who cares?!? If the process works for your team then use it! The more important (and interesting) question we should be asking is – how do I know if my process is working?

As someone who regularly experiments and actively seeks innovation, I’ll be the first to admit that I get things wrong often, but I pride myself on not allowing my likes and dislikes, my preconceived perception of my reality, to get in the way. While I don’t enjoy leaving my comfort zone, I recognize that it is important both for personal growth and the growth of the communities in which I participate.

And when it comes to building software, I recognize that though I may have a preferred approach or process, and set of tools and languages I like, there is no one-size-fits-all solution and the most important thing is to use the best tools for the job at hand. While I may have strong beliefs they are weakly held, my one conviction is to always do what I think is best for the project and the people involved with it.

I was reading an article from the Joel on Software archives and was struck by this quote from The Project Aardvark Spec:

I can’t tell you how strongly I believe in Big Design Up Front, which the proponents of Extreme Programming consider anathema. I have consistently saved time and made better products by using BDUF and I’m proud to use it, no matter what the XP fanatics claim. They’re just wrong on this point and I can’t be any clearer than that.

When thinking about design there are two extremes pivoting around how much up front design work needs to be done before you start writing code. Proponents of up front design point out, as Joel has in the quote above, that making changes in the design is a lot cheaper in a 20 page design document than a partially or fully implemented system. With a solid plan you stand a better chance of not painting yourself into a corner and avoid having to make expensive design changes in the code later. Opponents of BDUF worry greatly about analysis paralysis, which can severely delay a team’s ability to provide working software to the client. Codified in this thinking are the assumptions that clients don’t really know what they want until they see it and that only by getting working software in the hands of users can we understand whether a proposed solution is a good enough solution. To these folks, writing a design document is wasted effort because they don’t know what they want and they believe to their core that things are going to change anyway.

Both of these perspectives are correct. Both of these perspectives are also wrong. Since everyone loses when thinking in extremes and ultimatums, let’s figure out what is really going on.

Choosing a Software Design Approach: Theory

Building software falls into an interesting case of problems known as wicked problems. This means basically that there are many possible solutions and that no solution is really “right” or “wrong” only “better” or “worse” given your current understanding of the problem. Further each problem is essentially unique, there isn’t an explicit stopping rule, and as the designer you will be held liable for consequences of your solution.

With this in mind, in thinking about software design there are two variables which will determine how you go about designing a solution.

• How well do you understand the problem domain?
• How well do you understand the solution space?

In the software world, understanding the problem domain means thinking about technical constraints, functional requirements, quality attributes, and business constraints. Understanding constraints is critically important since these will define some of the boundaries of the solution space. Functional requirements deal with what the system will do while quality attributes deal with how a system should behave when performing certain functions. Finally business constraints are things the customer simply requires of a solution usually for business reasons (a common example is a budget or delivery date).

The solution space is a multi-dimensional landscape filled with nearly limitless possibilities. As the designer it is your job to figure out how to navigate this space in search of a solution to a problem. Your current understanding of the problem limits your ability to see solutions and often the fitness of a solution can only be understood in reference to another possible solution. I imagine the solution space as a mountain range and my job as the designer is to find the “best” mountain for my client. Of course some mountains might block my view from others which means I may have to climb a peak just to see a better solution. This implies that my understanding of the problem dictates my understanding of potential solutions and that my understanding of the solution will yield further insights into the problem. This is one reason why it is often helpful to get working software in front of users quickly.

When designing something we have a natural tendency to prefer making rational design decisions where, after careful examination of all information we choose the best or optimized solution. To make a rational choice requires not only that we know everything about the problem domain but also everything about every possible solution to the problem. Both business constraints, by constraining time or money, and shortcomings in the human brain limit on our ability to seek this knowledge creating a boundary around which a solution must be found. And it is in this world of bounded rationality that we must find a solution for our customer’s problem. Searching for a solution then is not as much a matter of optimization (finding the “absolute best”) as it is a matter of satisficing, finding the best solution with the information currently available. To complicate matters further, an individual’s understanding of the problem domain and solution space is relative to that individual’s experience and capabilities, the size of the problem, and the complexity of the solution.

When designing software it’s natural to want to move as far up the knowledge curve, get as close to making a rational, optimal design, as possible. This tendency stems from our instinctual preference to avoid loss [1]. In other words, designers assume that an optimal solution exists and so are predetermined to reject less than optimal solutions.

Choosing a Software Design Approach: Application

In the software design world there are four basic types of design strategies.

• Planned Design: All design is completed before beginning implementation. Often referred to as Big Design Up Front by detractors and associated with waterfall lifecycles. The essential assumption is that you can fully design a system before beginning construction.
• Minimally Planned Design: Some design is completed before beginning implementation. Sometimes referred to as Little Design Up Front. In using this strategy you acknowledge that some change is likely to occur but still want to avoid painting yourself into the obvious corners.
• Evolutionary Design: The design of the system grows as the system is implemented , but growth is deliberate and controlled by experienced engineers and proven engineering practices such as reference designs and refactoring. At least some requirements are usually specified in the beginning but it is not expected to be exhaustive.
• Emergent Design: The design of the system is allowed to occur organically as the system is implemented without specific intentions.

The design strategies appropriate for your team to choose is going to be determined by the amount of risk remaining in the bounded knowledge graph. Less risk implies that you anticipate less change (or at least that you feel you can deal with the change reasonably) and the more options you will have in choosing a design strategy. Choosing a design strategy then is a matter of deciding the degree to which your team would like to plan within the determined appropriate strategies. The amount of planning will depends on your team’s preferences and experience, or can be driven by customers’ business needs. From a theory perspective, the amount of planning appropriate to the project is directly proportional to how much you know about the problem domain and the solution space. In other words, the less you know about a problem and the fuzzier the solution seems to you, the less capable you will be in making planned designs. As designers we run into problems in our designs when we are wrong about what we think we know about the problem domain or solution space. Unfortunately as eternal optimists, software engineers get these things wrong often.

Don’t feel comfortable with the design strategies appropriate for your project? Remember that the appropriateness of a design strategy is based on your current understanding of the solution space and problem domain. Therefore, to make more design strategies available to your team you must learn more about the solution space and problem domain. I find that examining the project risks is the best way to determine what you think you know about the problem domain and solution space. Understanding the engineering risks your project faces also serves as a blueprint for moving along the knowledge curve. For example, if your team feels that they don’t know enough about the problem based on the identified and prioritized risks, you can increase your knowledge about the problem domain. On the same token, if the team feels there is a lot of risk concerning the solution space you can explore different designs, run experiments, or create prototypes for your users to try. Another option other than looking at risk is to use a design process such as Architecture Centric Design Methodology (ACDM). ACDM is a staged design process that encourages teams to explore the design space through experiments by addressing issues in proposed designs. ACDM strongly focuses on quality attributes and will nudge your team toward a planned design strategy but the process can be adjusted to use a different design strategy, if that is something your team strongly desires, by adjusting the go/no-go criteria between stages.

Remember too that you learn more about the problem and solution as you implement the system. So by the end of the project there will be no risk, you’ll know everything about the system you can, and you’ll have all the information necessary for a great (and practically useless) planned design.

The Project Aardvark Design Approach

Let’s apply this information to Project Aardvark and figure out why Joel is such a strong supporter of BDUF at Fog Creek Software. Project Aardvark, like most other software systems developed at Fog Creek, is a developer tool. This means that the folks developing the system are also going to be at least one of the groups of end users. We can assume based on Fog Creek’s hiring strategies that the developers are pretty smart. Further, Aardvark falls into a class of problems which has been well studied meaning there are examples available for study and some folks at Fog Creek may have even implemented similar (but not identical) systems or subsystems.

The implication is that the Project Aardvark problem domain is well understood and the solution space doesn’t need much exploration because Joel doesn’t perceive much risk in the solution. Since Joel has a firm grasp on the problem domain and since he feels confident about the solution space, he doesn’t anticipate much change in the design throughout development. Based on the information Joel has available about the project relative to his knowledge and experience with the problem domain and solution space, a planned design strategy is appropriate for this project. Joel could use other approaches further down the application curve too, but since Joel has relevant experience with planned design, the design probably won’t be that big (in fact it was less than 20 pages), and the Fog Creek team is used to following planned designs, planned design is probably a good fit for Project Aardvark.

One last note. Bounded rationality implies that the planned approach to design may not always be possible. There is a limit based on the size of the problem domain, solution space, and business constraints (especially time and resources available) that may prohibit you from effectively using Big Design Up Front. In other words, it may not always be possible to be high enough on the knowledge curve for a planned approach to make sense. Opponents of BDUF will tell you that most software falls into this category. In the case of Project Aardvark, the system was relatively small and Joel ensured that he had plenty of resources and time for exploring the solution space. It is critically important to understand where the boundaries that might prevent you from rational design are. Since we prefer rational optimization over decision making with less information, failing to recognize these boundaries will result in analysis paralysis.

By understanding some of the theory behind design decision making it’s easier to know where in the spectrum of possible design strategies your project belongs. Examining a project’s engineering risks is a relatively simple and repeatable way to determine where you are on the knowledge curve for a project. Now it’s possible to move your team up the knowledge curve, as necessary, to reach a point where you feel comfortable with the risks your project faces. You move along this curve by addressing the project’s risks through prototyping, research, experiments, evaluating proposed designs, and interacting with the customer. You could also use a specific design process such as ACDM. It is important to recognize that by moving up the knowledge curve you are necessarily moving your team closer to being able to use a planned design strategy. Your location on the knowledge curve will determine which design strategies you can use but you still need to determine which makes the most sense for your team and the project. Finally, these curves are relative and the scale is going to change from project to project and team to team. I think the principles behind the curves are more important than the curves themselves and you shouldn’t take the curves literally as a mathematical function.

Further Reading

• The Design of Design by Gordon Glegg – Primarly focuses on traditional design and manufacturing but the lessons are universal. A brief but excellent read.
• The Sciences of the Artificial by Herbert Simon – Explains the concepts of bounded rationality, satisficing, and using utility functions for design optimization. This is a very heady book but super interesting. I reccomend discussing the concepts with someone knowledgeable on this subject while reading the book. I had to read some chapters of this book multiple times before I even started to understand the implications of some of the concepts; Herbert Simon was just that ridiculously smart.
• The Design of Design: Essays from a Computer Scientist by Fred Brooks – See my review for more information on this great book.
• Just Enough Software Architecture: A Risk Driven Approach by George Fairbanks – Forthcoming book which presents the Risk Driven Design approach from a software architectue perspective. Includes an excellent overview of software architecture concepts. A must read for any software developer.
• Architecting Software Intensive Systems: A Practitioners Guide by Anthony Lattanze – Presents the Architecture Centric Design Methodology (ACDM) and lays a strong foundation for the concepts and principles necessary for planned software design through software architecture.

End Notes

[1] This also explains why humans behave the way we do in free market economies, gambling, and other similar situations. I am attempting to apply information I learned watching this TED Talk on monkey economics and irrational decision making by Laurie Santos.

If you were to go to two improvisational jazz performances, even two concerts by the same band, you’d hear different music at each show. The thrill of experiencing something unique, as it is created, without any kind of real plan or rehearsal, is both exciting and entertaining. Sometimes the music is so spectacular you feel like you’re witnessing a miracle. Other times the group can’t seem to get it together and the show is one long, painful indulgence in artistic expression. No matter the outcome, what you hear during that performance will never be experienced again.

Music has always served as a great metaphor for thinking about software development. At XP2010 during one of the most original key notes I’ve ever seen, Bjørn Halterhaug and John Pål Inderberg, professors of musicology and improvisation respectively, from the University of Technology and Science in Trondheim, Norway and both veteran jazz musicians, discussed, through music and words how they approach improvisational jazz, the mechanics for making it work, and the general implications on collaboration among artists. It’s tempting to romanticize improvisational jazz as a truly spontaneous creation but this isn’t exactly how it works in reality. For any improvisational jazz band to be successful its members must exhibit seven key characteristics.

1. Provocative Competence Interrupting Habit Patterns
2. Embracing Errors as a Source of Learning
3. Minimum Structures that allow Maximum Flexibility
4. Distributed Task: Continual Negotiation toward Dynamic Synchronisation
5. Reliance of Retrospective Sense Making as Form
6. Hanging out: Membership in Communities of Practice
7. Alternating between Soloing and Supporting

I propose that these seven characteristics apply directly to how teams who espouse emergent design should approach software architecture.

Music and Design

Experienced musicians have an attenuated ear which enables them to hear music in ways that novices can’t. Drawing on a well-developed playbook of clichés, an expert in the standup bass for example can not only follow the minimally, well-defined structure of a song but also weave pleasing bass licks into the musical ramblings of his band mates, adjusting his actions based on the paths his band mates choose with appropriate responsiveness as the song develops. Part of it is musical maturity, a taste or style developed over years of playing, part of it is also trust both in himself as a musician but also in the rest of the group, that they too will not overreact to mistakes and are also able to follow a musical flow as it develops.

Well-defined but minimalist structure. Contrast this with the music played by a symphony which is also well-defined but has explicit and detailed structure.

When I hear this I immediately think of architecture as seen through the lens of agile software processes which advocate strongly for emergent design. Agile software development processes and agile culture in general strongly encourages teams to become improvisational architects. Create a minimalist, well-defined design of the system and then allow the developers to evolve the system, creating the design as they develop, playing off the code written by their fellow teammates as the system emerges. The romantic view of this is appealing to some: “Let’s go have a code jammin’ session, you dig?” But the results of an emergent design can be just as varied as improvisational jazz bands; some designs are elegant and spectacular successes, some designs are flaming piles of disaster, most turn out somewhere in between – usually good enough for customers who aren’t paying too much and who expected a somewhat unpredictable but functionally adequate outcome.

So if you enjoy the thrill of experiencing once-in-a-lifetime moments of creation, the outcome of which can never be predicted or known ahead of time, then emergent design is probably right up your alley. As demonstrated by the near exclusive emphasis on code and shipping, many agile developers fancy themselves as code jammin’, improvisational architects.

The exact opposite of emergent design, of course, is the easy to hate (and rightly so) enemy of creating things that actually work, Big Design Up Front, where a heavy cost is levied against a project in the beginning without producing any usable code whatsoever. Sticking with the music metaphor, the well-defined, explicit, and detailed structures of a symphony might take a composer months or even years to create. But in exchange for this planning you get a piece of music that is guaranteed to be executed (for all intents and purposes) in a nearly identical way in every performance in which it is played. I am not saying you should use a Big Design Up Front approach, in reality, even Mozart tried out music and made incremental deliveries to his sponsors as he wrote.

While certainly a degree of improvisation happens when we develop software, customers paying for software usually expect more predictability in the outcome. So, while it might be ok to spend 30 bucks for a fun first date with a girl at a jazz club – if only for the experience of it – when I pay 100 bucks a ticket to see the symphony play Mozarts’s Requiem, I would be more than a little disappointed, angry, and confused if the first chair violinist “felt a groove” in the middle of the second movement and began jamming. The greater the cost of a project, the more highly valued predictability in it will be.

Who can be an Improvisational Architect?

Mozart was a true genius, a master of composition. To play Mozart, you need to be well practiced but you don’t need to have his level of genius. On the other hand, most members of a great improvisational jazz group must be experienced musicians – experienced in composition as well as technical playing ability. Even then, a great group will usually avoid disaster but occasionally it will still happen because of the nature of improvisation.

In my experience, teams that plan to allow their designs to emerge do an ok job of providing the minimal structure that is essential for evolving a design. But only a few developers have the necessary experience and background to truly improvise a design. The implication? Most teams are terrible at improvising architecture because they have neither a solid enough understanding of the core fundamentals for software architecture nor the experience with using architectural design to reason about a system.

I believe that most of the seven characteristics of improvisation are deeply ingrained in agile culture, but agile teams often fail to fully embrace all seven characteristics of improvisation when designing a software system. A team without the experience, who doesn’t understand design cliché’s (architectural styles and patterns) will have an unpredictable outcome when allowing the design of a system to emerge as the system is developed. This is something the agile community must work to resolve.

Bonus

Cory Foy was thinking ahead and had the foresight to record video of the performance/keynote.  It comes in 6 parts.

• Part 1 – introduction number
• Part 2 – introduction to improvisational jazz, link to XP, perspectives and group dynamic, a glimpse of how they teach jazz and improvisation
• Part 3 – Second number, application of theory discussed in part 2
• Part 4 – Beginning to introduce the idea of minimalist structures, awesome body percussion number
• Part 5 – communication, the seven characteristics of improvisational jazz, demonstration of “minimal structure for maximum flexibility”
• Part 6 – closing remarks and the final number

Ingvald Skaug was also inspired by this talk and wrote an interesting essay which explains kanban as agile jazz. Check it out for a process perspective on the idea of “minimal structure for maximum flexibility.” If you believe Conway’s Law, then it isn’t coincidence that we would apply the characteristics of improvisation in jazz to both process and design.

I like the idea of the risk burndown chart. Burndown is an effective and satisfying visual indicator of progress and it’s relatively easy to calculate to boot. But does looking at a project’s risks through the lens of a burndown chart make sense?

I see several problems with thinking about risk in this way.

Numbers can be Misleading

The first key to effective risk management is to value accuracy over precision. This means that it’s better to be right in your predictions than it is to be spot on correct. Remember, risk is about assessing your likelihood for project success. It doesn’t matter if you miss your threshold of success by a little or a lot; either way you still fail the project!

Pop quiz. Say there are two risks in your project. There’s a 25% probability that Risk A will become a problem while Risk B only has a 20% probability. For now, assume the impact is the same for both risks. Which risk is a greater threat to the project?

That one’s easy. Risk A is a greater threat because, impacts aside, Risk A has a 5% greater probability of turning into a problem.  Ok.  What if I told you that I made up probabilities based on my gut feelings so I could easily rank risks? Now which risk is a greater threat to the project?

The real question I’m asking you is this. Are you willing to bet the success of your project on those numbers? Because if my best guess, gut feeling probabilities are off by more than 5%, the project could be in serious trouble depending on the risks’ impacts.

I know, I know. That was a trick question. Nobody on your team would make up numbers on one of your software projects. In all fairness, nobody goes out of their way to fabricate false values. Use your logics. If you were any good at guessing the probability of futures events occurring, you would not be reading this post right now. You would be a multi-millionaire, off enjoying your gambling winnings from the ponies. Too much precision gives folks too much confidence in the correctness of your assessment when the reality is that probability and impact are based on best guesses and gut feelings. Probability and impact numbers just make it easier to calculate exposure so risks can be ranked automatically.  Burndown is a fairly precise metric.

Not all Risks are Created Equal

If you are monitoring project risk with a risk burndown chart, how do you know whether the right risks are being reduced? Let’s take a look at an example.  Which of these sets of risks should be addressed?

Set 1 with a total exposure of 7 days made up of the following risks:

• Risk A has a probability of 20% and an impact of 15 for an exposure of 3 days.
• Risk B has a probability of 25% and an impact of 10 days for an exposure of 2.5 days.
• Risk C has a probability of 30% and an impact of 5 days for an exposure of 1.5 days.

Or Set 2 with a total exposure of 7 days (6.7 rounded up) made of the the following risk:

• Risk D has a probability of 95% and an impact of  7 days for an exposure of 6.7 days.

In the first set, I can mitigate 3 risks, each with very low probability of becoming problems. In the second set I mitigate only 1 risk that is almost certainly going to become a problem. Reducing the imminent risk seems to make the most sense but this choice is not reflected in a risk burndown chart. Simply reducing risk over time is not enough. You have to reduce the right risks.

Impact Isn’t Really About Money or Effort

The only way for a visual chart such as risk burndown to work is if we’re able to quantify risks. This is generally done with exposure. Exposure = probability x impact. Impact is a funny thing. Impact is an assessment of how much the consequence of a risk will affect the project if the risk becomes a problem. Traditionalists like to think about this from a money perspective (which makes sense since software engineers stole most of our risk management practices from the finance world, originally anyway). For small teams, effort is a better measure as in the number of person days a risk that becomes a problem will cost to fix. This is a quantifiable loss.

There’s a problem with thinking about impact in terms days of loss. Since not all risks are created equal, not all loss is truly equal either. Some kinds of loss can’t be measured in terms of effort. It really all depends on your project’s threshold of success. Some example risks (which don’t rely on ye olde life-critical system standby) from which you might never recover if they became problems include:

• We don’t have a reliable backup solution; might lose all of our project data. (Lost yer data? You’re up a creek, son!)
• We don’t have backup power for our data center; data centers might go offline for more than a few hours. (How many days will it take you to get those customers back?)
• The demo has bugs and our contract renewal is based exclusively on how much the client likes our demo; a bug might occur during the demo. (HA! HA! You don’t have a job!)

In all of these cases you would reduce the risk by working on attributes other than impact (e.g. reduce probability, eliminate the condition, extend the time frame). Enough said. When it comes to calculating exposure, each of these risks has a catastrophic impact. That’s catastrophic, short for epic failure. No amount of days can really capture the essence of complete catastrophe.  Impact works best when considered in terms of success, not days or dollars lost.

Forget Risk Burndown

I want risk burndown to make sense, but given the problems I can’t help but think of it as a meaningless metric. Sure, some risks will be reduced and some will go away by converting into problems or being overcome by events. And a chart showing this would be really neat. But you’ll also uncover new risks as the project goes on. And some risks are just not worth caring about while others deserve a lot of attention. Risk management is about identifying the things that are most likely to kill your project so you can deal with them before it becomes too expensive (or impossible).  A burndown chart doesn’t reflect any of these things directly.

Burndown masks project risks too much and gives teams a false sense of confidence. To put it another way, there’s a risk with using risk burndown:

Our new risk management strategy assumes our estimation precision is better than it is; we may not mitigate the right risks.

Exposure is a ruse. And risk burndown is a metric for showing a reduction in exposure over time. To wax poetic, perception is reality and risk burndown provides a false perception.

That said, any risk management is better than none at all.  If a risk burndown chart helps to get your team thinking about risk, then so be it.  But there are other ways (might not be as fancy) to manage risk which are easier and more effective.