Hi Joe. First of all, thank you for answering our questions!

You are very welcome.  I always enjoy an opportunity to talk about software architecture, specifically the BBoM and the influence it still has on us today.

1. Your keynote is about the Big Ball of Mud pattern, fondly known as BBoM. Can you quickly explain what this pattern is about?

Our paper stated it pretty well so I will partly summarize from that:

“A Big Ball of Mud is haphazardly structured, sprawling, sloppy, duct-tape and bailing wire, spaghetti code jungle. We’ve all seen them. These systems show unmistakable signs of unregulated growth, and repeated, expedient repair. Information is shared promiscuously among distant elements of the system, often to the point where nearly all the important information becomes global or duplicated. The overall structure of the system may never have been well defined. If it was, it may have eroded beyond recognition. Programmers with a shred of architectural sensibility shun these quagmires. Only those who are unconcerned about architecture, and, perhaps, are comfortable with the inertia of the day-to-day chore of patching the holes in these failing dikes, are content to work on such systems.”

It is worth noting that If mud is such a bad thing, why do people keep making it and why does it continue to be so successful? Mud is related to Richard Gabriel’s “Worse Is Better” concept.  In a nutshell we are looking at why do we continue to talk about such eloquent architectures while, in reality, the most successful architecture deployed to date do not meet the desired vision.  There are many forces that lead to BBoM such as “Keep It Working”, “Throw Away Code”, and “Piece Meal Growth / Iterative Development”.  Give the current state of the art, maybe this is the norm and maybe we can learn from it.  Our paper discussed the details of how BBoM happen (why and the forces), why there might be valid reasons for them, and how to deal them.

A BBoM in Urbanism

2. Since it is such a common pattern, how long do you think it is possible to delay it?

First of all I want to say that Brian Foote and I are both strong proponents of good architecture.  We evolved from the Software Architecture Group at the University of Illinois where we were dedicated to solid software principles as outlined in good OO design, reuse, frameworks, patterns, etc.  We spent many years in this arena talking about good architecture, working on systems, and writing patterns about these ideal types of systems.  To our surprise, no matter how much work was being done or talked about relating to good architecture, it was very apparent to us that BBoM is a very common architecture that still continues to thrive in our industry.  So maybe we should not try to delay it, but rather embrace it and accept it for what it is.  Maybe it is the best we can do given our current tools and programming languages?

However I am still an optimist.  I believe there are some things we can do.  First, we must be honest and admit the fact of BBoM (that it happens and there are forces that lead to it).  Also, in some cases, it might be inevitable.  Until we do this, we can not do anything about it.  Then, once we see this we can be more proactive with dealing with it.  Rather than running from it and ignoring it, maybe we should embrace it for what it is, knowing it will happen.  Then, we can apply some well known principles such as continuing to evolve our architecture, applying good architectural principles as our system evolves, along with good communication and refactoring.  So, if we accept Mud for what it is and teach more about it, then we can deal with BBoM and help prevent it from getting too “muddy”. So, although we might not be able to avoid it or delay it for too long, we might be able to make our systems a little “less” muddy and give us ways to deal with mud as our architecture grows and evolves.  So this might be our way to delay it.  It takes a lot of hard work and commitment.

3. Do you think it can be reversed?

There are some items that I have seen that can help. For example, some Agile practices can help such as continuous Refactoring, Regular Feedback, Testing, More Eyes, Good People, Continuous attention to technical details, Retrospectives, Face to Face conversations, and motivated individuals with the environment and support they need.  By practicing some of these core well-known principles, you have a much better chance to see Mud as it arises, thus able to make better decisions on how to deal with it and how to reverse it.  For example, Refactoring can help us separate things that change from those that do not change, keeping the architecture much cleaner.  Also, a continuing effort to evolve the design as the system changes is an important facet towards keeping systems from becoming too muddy.   So, yes, we can reverse it some. Though, as we stated in our paper, sometimes the only hope for a system is what we call Reconstruction or a complete rewrite of the system.

4. Recently, Kent Beck spoke about going beyond agile programming. One of the thoughts we had when watching his presentation was that most BBoM we know of were created by valuing the business forces more than the engineering forces. Do you agree with this view?

I don’t completely agree with this view.  Of course if you just value the business forces, then you will probably end up with a BBoM. However, what about all of those muddy systems that focused more on Process and Tools as Kent talked about yet are still messy.  Originally those process and tools were suppose to focus more on the “right” way to develop software with a “good” set of tools and practices.  The goal was to help ensure “good” code. Yet those using those processes and tools still often end up with muddy looking code.  I know of groups who completely focused on the software engineering side of things and yet they still either ended up with a BBoM or never made it into production as they tried to achieve perfection. Now of course with good people and good communication, along with paying attention to good principles of software development, your chances of ending up with a better architecture is greatly enhanced.

However, as things become larger and more complex, the architecture in general becomes harder to keep completely clean and might be as good as we can do given our current state of the art.  Our software systems have grown to model more complex business and engineering needs and thus mud might be “normal” given the complexity of our problems.  On the other hand, it makes sense only to build what you need when you need it.  This might lead to some mud but it seems to be a better way to guarantee success.  We know requirements and needs change and it is hard to completely know how your system will evolve.  So no matter what we do, given changing requirements, mud seems to find ways to creep into the architecture.  If we lived in a world where we could get a solid set of requirements that would never change, and we are given enough time to make sure we end up with a clean system, then we could theoretically avoid mud.  But this is not realistic given our current business and engineering needs and the way the world changes.  I believe that this is why Agile grew and became so successful.  Agile potentially gives us a better way to deal with these changes and, as a side effect, a better shovel for moving mud.

5. We heard your keynote will focus on the relation between the BBoM pattern and Agility (we can’t imagine why :-). Can you give us a very brief taste of what you’ll speak about?

Somewhat to our astonishment, since our original statement, no one has ever undertaken to dispute this premise. Also, to some it might be surprising as to why this approach or architecture stills endures and thrives. This talk will examine a few issues including BBoM’s relation to Agile such as: Why is this architecture so popular? Is it as bad as it seems, or might it serve as a way-station on the road to more enduring, elegant artifacts? What forces drive good programmers to build ugly systems? Can we avoid this? Should we? How can we make such systems better?  I will show how some principles of Agile lead to mud and how some can also help us cope with Mud. Is this brief enough :-).

6. Speaking of patterns, we know you’re an active member of the Hillside Group and the patterns community, and that a lot of your work is on Object-Oriented Analisys and Design. What do you think about today’s OO development and where do you think we’re heading to?

We’ve come a long way but we have a long ways to go.  OO was a good first step towards giving us good abstractions and ways to think about the way we design and develop software.  Frameworks, Reuse, Patterns, and Agile are good principles and  ideas that evolved from the OO community, which have proven invaluable to our community.  My involvement with the Hillside Group and the patterns community relates to my belief that I think software is still too hard to change and I want do something about this.  Putting the ability to change software into the hands of the people who understand the domain seems to be one promising avenue to solve this problem.  For examples DSLs have had many successes for allowing domain expert to change their software. When you get your framework or DSL right, adapting the system to changing requirements can be done fairly quick and easy.  So I believe that we need to focus more on the people side, and help make better languages and tools to support both people creating and using software.  Let’s face it, software is developed by people, for people.  Too often we put our pure engineering hat on and forget this fact.  This is why I also believe that Agile has had such wide acceptance as it embraces this fact that the people side is key to being successful.

7. You’re also widely known for being a co-author of the Adaptive Object-Model pattern. The phrase “everything you do, I can do it meta” comes to mind. Are you able to reconcile this with the subjects we’ve been talking about?

First of all let me briefly describe what is an AOM. Architectures that can dynamically adapt to changing requirement are sometimes called reflective or meta-architectures. We call a particular kind of reflective architecture an Adaptive Object-Model (AOM). An Adaptive Object-Model is a system that represents classes, attributes, relationships, and behavior as metadata. It is a model based on instances rather than classes. Users change the metadata (object model) to reflect changes to the domain model. AOM stores its Object-Model in XML files or in a database and interprets it. Consequently, the object model is adaptive; when the descriptive information for the object model is changed, the system immediately reflects those changes. These are highly related to Domain Specific Languages (DSLs).  So maybe the best way to get agility is to let your users (domain experts) change your systems without needing to changing code.  If you are successful in allowing certain changes to your system in a controlled fashion, such as those outlined by an AOM architecture, will this not give you Ultimate Agility?  Your system can change and you can be very agile and adapt to a changing business requirements while possibly limiting the mud factor in your code.

Joe, thanks once more for your time. See you on June 25th!

My pleasure.  Thanks for the invitation and I look forward to participating at Agile in Porto!