They illustrate their points with physical world architectural examples, a lot coming from Stewart Brand's How Buildings Learn, because design in other domains and design of software aren't so different when you look closely. I was, of course, thinking about interface design and organizational design while I was reading it, and about the book Architecture Without Architects, which I really like in both concept and fact after meeting a few (I'm kidding--mostly). Foote and Yoder's interest in XP (extreme programming) is in part because of the need to accommodate changes in user requirements, but they don't talk a lot about UI design and the difficulties with keeping UI code flexible and modifiable. (I still think it's a shame that agile and XP communities don't connect and work better with UI/UX/UE folks -- apart from the active agile-usability mailing list, of course. The goal of a good designer is to get the right decisions made right and executed well; these goals are the same for both UI designers and code designers, and should be the goals of managers and executives who support them. But.)
Selections from the Ball of Mud article:
- One reason that software architectures are so often mediocre is that architecture frequently takes a back seat to more mundane concerns such as cost, time-to-market, and programmer skill. ... Architecture is a long-term concern. The concerns above have to be addressed if a product is not to be stillborn in the marketplace, while the benefits of good architecture are realized later in the lifecycle, as frameworks mature, and reusable black-box components emerge [Foote & Opdyke 1995].
- In other words, the software is ugly because the problem is ugly, or at least not well understood. Frequently, the organization of the system reflects the sprawl and history of the organization that built it (as per CONWAY’S LAW [Coplien 1995]) and the compromises that were made along the way. Renegotiating these relationships is often difficult once the basic boundaries among system elements are drawn. These relationships can take on the immutable character of "site" boundaries that Brand [Brand 1994] observed in real cities. Big problems can arises when the needs of the applications force unrestrained communication across these boundaries. The system becomes a tangled mess, and what little structure is there can erode further.
- Architecture and code quality may strike management as frills that have only an indirect impact on their bottom lines.
The same can be said of usability and design excellence, of course. It's a special organization that doesn't erode the desire of people to produce quality work by saying "it's good enough to make us money right now."
A good closing quote: Alan Kay, during an invited talk at OOPSLA '86 observed that "good ideas don't always scale." That observation prompted Henry Lieberman to inquire "so what do we do, just scale the bad ones?"
Pretty often, both on the idea itself and the execution. In the short term, the prototype code works well enough, and the design is okay unless you look closer or start trying to add onto it. Same happens with UI design, without enough iteration, and tacking on new features without refactoring is like adding dirt and grass to a ball of UI mud.
I'm now using the new Office 2007 products, and I regret not seeing more refactoring of the UI, despite the famous ribbon. If you're going to start doing a UI refactor, you may as well go all the way once you've disoriented your users a little bit; for instance, why keep Word's header and footer commands under the "view" tab now, and I have to question whether "home" means anything real to anyone except on a website. Some of the changes are a great improvement, but I think a little card sorting might have helped them out a bit, too, and I find some of these choices surprising.
1 comment :
Good for people to know.
Post a Comment