Rebecca is an internationally recognized leader in the development of object design methodologies. She is the lead author of two design books, and she invented the set of development practices known as responsibility-driven design. Rebecca is also an innovator of techniques for simply expressing complex requirements and effectively designing and communicating software architecture. She frequently helps product engineering, IT, and startup organizations with the technical bits, as well as with effective teamwork and agile development practices.

Hi Rebecca! We are very pleased to have you in Agile Portugal 2011. Thank you for taking the time to talk with us.

Thank you. I am very pleased to be able to attend Agile Portugal. This is my first visit to Portugal.

You are recognised as a design guru. How have you developed your interest in simplifying complex requirements expression, effective design and software architecture communication?

Although I am an object design “guru”, I have always been interested in the way requirements shape my design thinking. The two are deeply interrelated. I often need to find what the real problem is before I can create a good design solution. I may need to rearrange and/or simplify how requirements are stated in order to create a good design and find reasonable abstractions. So simplifying how complex requirements are written has been an obsession of mine. That is why I like the values in agile development, favoring conversations over comprehensive documentation. It makes it easier to find design abstractions if I can talk about the real issues with a domain expert.

To preserve good design ideas you need to communicate them effectively. So my interest in effectively communicating software architecture has been a natural progression of my ideas and interests.

You’ll be giving a tutorial with Joseph Yoder with the title “Rulemakers and Toolmakers”. Can you tell us and our readers a couple of reason why we really shouldn’t miss it? :)

First, we present an architecture style that enables domain experts to extend the system without programmer intervention. How to achieve that kind of flexibility is very interesting to learn about.

Second, we show you that you can build this kind of adaptive system incrementally, adding flexibility when and where you need it. So we think this incremental development of an adaptive system fits very well with agile values.

Despite Adaptive Object-Model being an architectural pattern, there is a strong philosophy underlying it. Do you see the division of labor as one of its strongest benefits?

I do. With this architecture, domain experts have ability to change and extend their domain objects. This gives them a lot of power and control. But it also places a burden on the developers to create the appropriate tools, to do this safely.

How do you reconcile the agile practices of test-first/test-driven with the model-driven philosophy of AOMs?

OK, I’ll say this very clearly: Just because you are agile doesn’t mean that you can never build frameworks or create extensible architectures. But you should do so for justifiable reasons. I wouldn’t create an adaptive object model architecture unless there is a need. And, I have to do it for concrete reasons and real needs.

Do you recognize any impact of such a model in the way projects are managed?

AOM systems are typically built by really good designers working in small teams. And still, the best way to develop such a system is incrementally. It won’t work if you spend a lot of time building AOM architectures and tools for domain experts and then give them to the end-users to try out after the architecture is “complete”. So, you need to be agile about this. It also is the case that domain experts get much more involved and engaged. So rather than feeding developers yet another user story, they may be implementing that story themselves by adding/extending the domain model.

I see some companies here in Portugal struggling with the introduction of agile practices. Without revealing too much about your talk on “agile adoption”, do you have any advice on how they can ease that path?

First, they should recognize that no one does agile exactly by the book . You also don’t have to throw out every good practice you are doing now in order to become agile. But you do have to develop a rhythm of working and delivering results in small increments. That is new to many people. So it takes practice and commitment to change.

The agile manifesto was created ten years ago, and our industry came a long way since then. Do you think it applies to our industry today as well as it did back in 2001?

Yes, and no. I think the agile manifesto was a reaction by a very smart group of thought leaders to perceived waste, inertia, and lack of attention on the software and the code itself. It was a rallying cry that spurred many to revisit how they develop software. But as agile adoption has spread, we have to have new ideas and innovations. We also need to consider that there are many more people involved and impacted by our software. So while the values of the agile manifesto are good, this is a new decade. So let’s use this 10 year anniversary as an opportunity to re-imagine how we should be developing software in this complex world and how can we can continue to do a better job.

Thank you for your time! We are looking forward to attend the tutorial on the 20th of June.

Thank you.