Thinking Inside a Bigger Box

Extreme Programming vs. Interaction Design

Elden Nelson interviews Kent Beck, the founder of the Extreme Programming method and author of “Extreme Programming Explained: Embrace Change”; and Alan Cooper, the prime proponent of interaction design and author of “The Inmates are Running the Asylum”. The interview is well worth the effort of navigation through the horrible interaction design of FTPOnline.

Beck’s analysis of interaction design and “Inmates” expresses exactly how I felt about the book when I read it: Interaction design has a lot of really powerful tools to really important questions. However, it constraints itself to working with software people because of assumptions that simply are not true anymore. I share Beck’s opinion that both disciplines have a lot to teach each other.

There is one thing I wished Beck had responded differently on, however:

Beck: [...] For all its Dilbertesque qualities—and I’m still proud of having said “Embrace Change” in the title of the first XP book. I’ve consciously decided to give up the ability to predict the future.

Cooper: I see that in XP. It’s an abdication.

No, embracing changing requirements is not an abdication. It is a realisation that the most valueable insights into systems come after those systems have been put into production. Changing requirements is a sign of a product that the users use it, care about it, and gets value out of it. By resticting interaction design to the inception of the product, Cooper limits the impact it could have on real systems. I would like to juxtaposition Cooper’s statements in the interview with Robert Glass’ Facts 43 and 45 from “Facts and Fallacies of Software Engineering”:

Fact 43: Maintenance is a solution, not a problem.

Fact 45: Better methods lead to MORE maintenance, not less.

Now read the interview.

Yes!

The first thing that strikes me about Eric Evans “Domain-Driven Design: Tackling Complexity in the Heart of Software” is how it seems to bring together the ideas that have resounded the best with me during the last few years. The central thesis of the book is that that enterprise software should to be built around the model that (non-software) experts in the field has of the problem domain. The shared understanding between the software developers and the domain experts and users facilitates communication. And also: In many domains, there are advanced models that have stood the test of time (for example double-entry bookkeeping). Reinventing such models is not the best thing software developers could spend their time doing.

The model driven design effort is based around the shared discovery of a ubiquitous language that is shared by the development team and the customers.

The part of the book that was most useful to me was Part III: Refactoring Toward Deeper Insight. Unique in the books I have read about modeling, Evans claims that a model that does not evolve is dead (or at least fossilized), and is a sign of failure for the project to be useful. This is in congruence with Robert Glass’s observation in “Facts and Fallacies of Software Engineering”: The most valuable programs are changed, as the users discover new needs. Evans describes how to keep a design supple by strategies that build on and extend the recommendations of Extreme Programming.

I only have two practical problems with the Domain-Driven Design approach.

• The software development projects I have been involved with lately has used technology that constains the design. The technologies are also so technically challenging that the development team don’t have the time to focus on the domain model.


• No software project is an island. Practicing domain driven design is hard in the face of legacy systems that the team must maintain or integrate with.

Evans addresses both of these topics, but I feel only the last is answered to my satisfaction.

The question of domain-driven design with the current technological trends is an interesting one. I feel a lot of vendors (but not all) are trying to sell technology that constrains the design further. The worst example IMHO is Enterprise JavaBeans. This is an example of a framework that is invasive, inflexible, and constraining. However, from the open-source scene, the current trend seems to be more in congruence with domain-driven design. IoC/Dependency Injection, AOP, and Naked-Objects are my favorite examples of paradigms where the goal of the frameworks is to get the technology out of the hair of the development team. “Domain-Driven Development” spells out the argument for such tools, even though Evans does not address this aspect directly.

I think this is the only failing of “Domain-Driven Development” as a book. Evans explains in detail a host of useful techniques for working in a domain-driven world. I feel the ideas are important enough to warrant more of a manifesto-like book. The book is great for implementing Domain-Driven Design once you have sold management and the team on the idea. There is a need for something something shorter and more persuasive as an introduction to the subject. Subjects like technology interaction with the domain-driven design should be explored further.

All in all, this book is not for everyone. I feel domain-driven development as a focus for developing software in the future is an essensial paradigm. However, Evans goes into too much details on the techniques, and the book ends up being a heavy read for anyone who just want to get an idea of what domain-driven development is about.

I was recommended “The Art of UNIX Programming” by Eric Raymond (esr) from Joel Spolsky’s “Joel-On-Software” blog. The recommendation in it self warrants some comments, as Joel Spolsky normally is very much a Windows-kind of guy. Despite the title, the book definately has much to offer people who never touch UNIX as well.

esr focuses on the cultural aspects as much as the technical aspects. For organisations that are migrating into Unix infrastructure the ramifications of the Unix culture can be hard to grasp. In my experience, no other technical platform has as strong of a culture. esr does an excellent job of explaining the Unix mindset and how it influences the software on the platform. The heavy use of case studies from big open-source Unix projects helped me understand the factors very well. I was amused by the examples esr choose in the case-study of the cookie-jar format. I generally disagree with the political views of esr, but he is considerate enough to only preach Unix-philosophy in this book. (esr’s political writings define as extreme left-wing what in Norway would be considered the most right-wing parties. Oh well)

What I loved most about this book was probably its treatment of open-source. The subject of open-source is of course not specific to the Unix world. esr covers as diverse subjects as the economic justifications, the schism between the Free Software Foundation and the Open Source Initiative, practical management of open-source projects, and legal implications of open-source licenses. If you are considering using open-source in your organisation (and you really should be, if you are not already), you need to read the Licensing Issues of chapter 16. It is available online. Go ahead, read it now!

This section is directed to commercial developers considering incorporating software that falls under one of these standard licenses into closed-source products.

Having gone through all this legal verbiage, the expected thing for us to do at this point is to utter a somber disclaimer to the effect that we are not lawyers, and that if you have any doubts about the legality of something you want to do with open-source software, you should immediately consult a lawyer.

With all due respect to the legal profession, this would be fearful nonsense. The language of these licenses is as clear as legalese gets — they were written to be clear — and should not be at all hard to understand if you read it carefully. The lawyers and courts are actually more confused than you are. The law of software rights is murky, and case law on open-source licenses is (as of mid-2003) nonexistent; no one has ever been sued under them.

Amen.

Three things I took with me from this book:

• 
  
  A lot of program design heuristics and ideas


• 
  
  Better understanding of the open-source model


• 
  
  An appreciation for the legacy and future of Unix