Summary
Good user interface design is one of the most poorly taught disciplines in software education. Such poor foundations follow programmers all the way to their positions of leadership in the industry, and the Agile Manifesto authors are no exception. Here, I post my thoughts on a recent posting in Håkan Reis' 'blog, whose views struck a chord with me.

A recent 'blog by Håkan Reis picked up on some things I said in my keynote at Øredev 2006 about common pitfalls of Agile practitioners, and in particular those that contribute to bad user interfaces. My points were that: 1. Test-driven development without architecture emphasizes a procedural architecture rather than the kind of good object-oriented architecture than supports the direct manipulation metaphor, which in turn is one foundation of a good user interface; and 2. That the Agile Manifesto leaves usability at the side of the road. Here are the comments I added to that 'blog.

The Manifesto is by and large brilliant, but in retrospect one does find it blind, so to speak, to our users' perspective. Most of it is about solving our problems as programmers. Even customer engagement ends being a problem for us, because we get relatively quick feedback if there is a requirements mismatch, and that stings. So the manifesto has a heavy user-story focus because that's what its authors knew. It's a baby-and-bathwater problem, one more time with feeling.

Usability and maintainability are long-term issues. I think that most Agile organizations adopt short-term postures. Long-term underpinnings are necessary to short-term agility: You must be fit to be Agile. Getting into shape, developing the right architectural posture, takes time and effort. (That was the first point I emphasized in my keynote, referenced in one of the links above). Too many Agile practitioners ignore this foundational discipline because they confuse Agile with instant (programmer) gratification, under the excuse of rapid customer delivery (which is a good thing) and quick feedback from the customer (which can also be a good thing). So I've seen a lot of Agile projects crash and burn after about their third external iteration for lack of good architectural foundations. It doesn't take much architecture to shape the whole -- just enough to keep Conway's Law happy and to lay a foundation for the interface -- but it takes much more than Ron Jeffrie's fabled "ten minutes of design." Maybe a sprint's worth is enough to get started.

If an interface is unproductive or inhumane, users notice it only after a long enough time has elapsed for habit formation to be a factor. You don't notice such things when you test drive the program; the clumsiness is hidden behind the familiar Redmond look-and-feel or behind some graphic artist's sugar coating. Some users never get beyond their awe of such sugar coating to understand that they system is costing them dearly in time. (I think it's Beyer and Holtzblatt who make the point that it takes much longer using Word to type a letter and envelope than it does using a typewriter.) Those users who do ultimately become conscious of the inefficiency of their interface, do so long after leaving the store where they bought it.

Unlike bugs -- which are more black and white -- usability concerns are difficult to convey to the vendor. They often must be substantiated by data, studies, analyses, measures, and comparisons. Most users don't have the tools or even vocabulary to develop such critiques of the interfaces they use. Curiously enough, neither do most vendors, and most Agile projects are changing the software too rapidly to undertake such studies. The most that a user is likely to say is that an interface is "clumsy" or "awkward," and it's hard for a typical vendor to do anything with that. An insightful vendor will of course do some dutiful usability work. I just worked with a client a month ago who quickly (agile-ly!!) responded to static from their users about usability problems. The users were right, and we made a lot of progress. Things seldom go so well. There is a close relationship between the structure of one's domain, the structure of one's interface, and the architecture of one's software. The most superficial understanding of OOD and MVC together bear this out. Those structures evolve more slowly than user stories do, and must be nurtured with care. Agile has a poor history of being patient or of dealing with long-term stable structures, or recognizing the feedback loops that reflect problems in those structures. There is no user story for usability nor for maintainability. So, in fact, I think the problem goes much deeper and is much more serious than you point out here. As you said in your previous 'blog, it's only when developers start taking this to heart that things will change. That goes back to how universities educate their students, and how corporations value investment in the user interface. In the mean time, we follow a blind manifesto. A blind manifesto can type code quick and in an Agile way, but it has difficulty working its way across the busy street of the market place.

Talk Back!

Have an opinion? Readers have already posted 45 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever James O. Coplien adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Jim Coplien is a Senior Agile Coach and System Architect at Nordija A/S, doing international consulting in organization structure, software patterns, system architecture, as well as software development in electronic design automation, telecom, and finance. In this 'blog, he reflects on his academic career pursuant to his visiting professorship at University of Manchester Institute of Science and Technology, his appointment as the 2003-2004 Vloebergh Chair at Vrije Universiteit Brussel, two years as an Associate Professor at North Central College in Naperville, Illinois, and extensive work developing some of the first C++ and OOD training materials. He is well-known for his foundational work on object-oriented programming and on patterns, and his current research explores the formal foundations of the theory of design, foundations of aesthetics and beauty, and group theoretic models of design structure. He most recent book "Organizational Patterns of Agile Software Development", co-authored with Neil Harrison, culminates a decade of research. His book "Advanced C++ Programming Styles and Idioms" defined design and programming techniques for a generation of C++ programmers, and his book "Multi-Paradigm Design for C++" presents a vision for the evolution of current OO design techniques into a more general and better grounded theory of software construction.