software development

About

Syndication

Categories

Archives

Eric Raymond: Open-Source Usability Advocate?!

software development, usability

February 27, 2004, 10:01 PM

I was idly surfing the blogspace (doesn't that sound so much nicer than "blogosphere"?) this afternoon when I happened across Julian Missig's blog (a fellow CMU student and a co-worker of Dana's, of all things). He points to an article hot off the press by Eric Raymond where the famous OSS guru actually argues in favor of fixing the open source software usability problem! I could barely believe it until I read the article; frequent readers will recall that I've been studying the OSS usability problem for several months now. But though I've found some encouraging evidence of OSS developers who are starting to get it, I never, ever thought I'd read an article like this from ESR. Some of his suggestions were right on, others I'm not so sure about, but the core ideas about the ways open source software needs to change are right on the money.

I've sliced out some particularly interesting bits below, with commentary.

Aunt Tillie, at this point, is either resigning herself to another session of being tortured by the poor UI choices of well-meaning idiots or deciding to chuck this whole Linux thing and go back to the old Windows box. It blue-screened a lot, but at least it allowed her the luxury of ignorance — she didn't have to know, or care, about what a JetDirect or a CUPS might be.

OSS advocates often emphasize superior stability or security of OSS tools over commercial alternatives. Whether these things are true or not, they are irrelevant to average home users; if Raymond's fictional everyuser, Aunt Tillie, can't figure out how to set up and use her PC, it's worthless to her. Putting up with the occasional crash or theoretical security glitch is worth it to her if it means she doesn't have to be a tech wizard or Unix hacker to get her machine to print photos and send email.

I am not ignorant, but I have my own equivalent of Aunt Tillie's problem. I know I want one of the top two methods, but I don't know which one. And I don't want to know or care about the difference either; I have better things to do with my brain than clutter it with sysadminning details.

Another good point; even though OSS gets most of its support within technical circles, it's not just nontechnical users that software with poor usability alienates. Raymond is far from representative of the technical skills of the average computer user, and even he barely succeeds at performing this seemingly simple operation with CUPS. I, too, am far more technical than your average Joe, but I've played out scenarios similar to Raymond's with my own linux server many, many times. Sometimes, after much wasted time, I succeed at my task. Other times I fail, and figure out an ugly workaround or just give up and go back to the rest of my life. Like ESR, I have better things to do with my brain.

The thing to notice here is how far behind we have left Aunt Tillie. Rule 1 of writing software for nontechnical users is this: if they have to read documentation to use it you designed it wrong . The interface of the software should be all the documentation the user needs. You'd have lost the non-techie before the point in this troubleshooting sequence where a hacker like me even got fully engaged.

Huzzah! Good documentation does not replace good interface design. And if the interface is poor, it's documentation is necessarily confusing, since a convoluted interface requires complicated instructions on its use. Too often in OSS, the solution to poor design is lengthy documentation. Proprietary software companies learned long ago that user's don't read documentation. It's time OSS learned the same lesson.

GUI tools and voluminous manuals are not enough. You have to think about what the actual user experiences when he or she sits down to do actual stuff, and you have to think about it from the user's point of view.

I could hardly have put it better myself, if someone asked me to capture in a nutshell the problem with OSS efforts to bring usability to their software. Open source projects are copying the trappings of well-designed software interfaces without understanding the substance. The result is lots of GUIs and manuals, but interaction designs that all too obviously had little to no thought put into them. This must change, if OSS is to compete with proprietary software in anything other than the (shrinking) niche of highly technical audiences.

I'll note that I had such a hard time believing my eyes while reading this article that I checked the domain name repeatedly to make sure it was really published by Eric Raymond.

None of this is rocket science. The problem isn't that the right things are technically difficult to do; CUPS is already supposed to have discovery of active shareable queues as a feature. The problem is that the CUPS designers' attitude was wrong. They never stepped outside their assumptions. They never exerted the mental effort to forget what they know and sit down at the system like a dumb user who's never seen it before — and they never watched a dumb user in action!

Again, this is right on (although I might take exception with referring to users as "dumb", if I wasn't in such a good mood). I've advocated bringing usability professionals and interaction designers into the open source community precisely to solve this problem; it's hard for anyone to step outside their assumptions and see a system they created as it is seen by those who are unfamiliar with it. It's especially hard for software developers who, while extremely skilled at producing quality code, are unskilled at understanding human limitations and seeing the system from the user's perspective. Hence the need for more heterogeneous skill sets within the OSS community.

CUPS is not alone. This kind of fecklessness is endemic in open-source land. And it's what's keeping Microsoft in business — because by Goddess, they may write crappy insecure overpriced shoddy software, but on this one issue their half-assed semi-competent best is an order of magnitude better than we usually manage.

When I read this section, I wasn't quite sure whether to dance for joy or go into shock.

It's clear that, beyond all hope, Raymond recognizes that there is a problem. With his influence, perhaps others will recognize it as well. And that, of course, is the first step towards a solution.

Because I believe it is a solvable problem. Although many OSS developers are currently naive about usability and interaction design methods, this can change. Although most interaction designers and usability professionals do not currently get involved with OSS projects, this too can change, if a place is made for them. And what's more, I highly suspect that a fully integrated, properly honed open source software community, with interaction designers, usability professionals, software developers, and end-users all working together, could produce software far superior in both design and technical quality than any proprietary company has yet been able to manage.

But that future does not yet exist, and it will take a lot of work to get there.

As I said before, the point of this essay is not especially to bash on the CUPS guys. They're no worse than thousands of projects out there, and that is the point. We talk about world domination, but we'll neither have it nor deserve it until we learn to do better than this. A lot better.

Amen, brother.

[ Permanent Location ]

Movable Type Needs Multithreaded Rebuilds

software development, usability

January 31, 2004, 09:40 PM

I've noticed that posting a comment on roBlog takes quite a bit longer than it used to since I released Heimdall. Although it fortunately does not take so long that browsers time out the request, it takes long enough to seriously impact the usability of the system; at best many posters will be annoyed by the delay, and at worst may think the server is not connecting and may try submitting the same comment again. Certainly the lag is far longer than the 1 second optimum response time and even exceeds the maximum 10 seconds. I clocked it at close to 20.

The problem, I believe, is that Movable Type rebuilds all weblog pages that may be altered when a comment is posted. Since roBlog has many index pages and complex template code, this takes some time, and that contributes to the long post time. For this very reason, Movable Type doesn't bother to rebuild archives when it receives a Trackback ping, since the tool that sent the ping may have even less patience than a human (or something...).

So here's my totally unsolicited advice to Ben Trott: don't rebuild the weblog files during the CGI request! If CGI doesn't allow for the execution of code on its thread after the HTTP response has completed (I'll admit I've never tried such a thing), then spawn another thread to finish the rebuild task in the background. Only generate sufficient information to provide the user (the comment poster or trackback sender) with enough feedback for them to realize their action was successful; the rest of the rebuild can wait until the request is closed to proceed.

And if you don't want to do it yourself, keep in mind I'll be looking for a job starting in August...

[ Permanent Location ]

When Reuse Is Bad For Real Use

software development, usability

January 28, 2004, 11:26 PM

Joel has an interesting article up on the hassle of Microsoft's .NET runtime environment. Joel prefers the "old" approach of using a linker to bind up all the required libraries and resources with the program itself. Despite my love for Java, which is also afflicted with a runtime environment, I agree with him.

Although it is widely considered good software engineering practice to separate reusable code into its own modules, the approach of using system-level shared code libraries takes this too far (run-time environments are essentially just collections of these libraries). Having multiple applications access a shared code base foists the task of upgrading and maintaining that code base on the user. Linux is notorious for this sin; users must often upgrade many shared libraries before a new application will work, and a result software installation is a nightmare. Windows is better nowadays since they developed Windows Update, but as Joel pointed out, with the frequent calls for reboots and other task interruptions, it's still a major annoyance at least.

The Macintosh has always considered each application its own separate entity, and hasn't really had a concept of shared libraries. As a result, software installation (and backup) is painless; just drag an application into a folder. I'm no Apple worshipper, but they've had the right idea all along here. Application developers should worry about whether they have the right version of the right libraries available when they ship, and that should be the end of it. Modularization has many benefits, but none of them directly effect the user. It's just none of their business.

[ Permanent Location ]

A Deeper Look at CSS

internet, software development

January 07, 2004, 02:37 PM

I've been working hard on my new website design, which is why posting new entries has been so slow of late. Rest assured that I have many things lying around that still need saying, however. The well of my verbosity is far from dry.

I did want to offer a few words of apology to the CSS standard, which I have maligned somewhat in the past. CSS's attention to logical page elements and their properties makes it much easier to work with (and get good results out of) than the standard approach of mucking around with using tables as layout guides. There are still some important things missing from the current CSS standards (I spent all last night trying to get rounded borders on some of my divs, and wound up resorting to tables) but on the whole it's a reasonably well-crafted document formatting metaphor.

That said, there's still two major obstacles that are real showstoppers:

1. Lack of a consistent, correct implementation of CSS in the most common web browser. You wouldn't believe the ugly hacks people have to come up with to get even some pretty simple things to work using CSS in IE.
2. No usable CSS-based authoring environment. It's still easier to create a non-CSS page in Dreamweaver than it is to create a CSS page. And no editor has arisen with a sufficiently usable alternative to get people to switch.

The standard's getting better, though, and hopefully the browsers will catch up with it. But until the perfect solution is crafted, here's some advice on switching to CSS for those who just want to get it done:

• Make a mockup of the page design before trying an HTML/CSS implementation. You'll need the mockup to identify the main logical sections of the document that will need to be styled separately, and thus need to be different classes. I was really glad I had mine handy.
• Don't be afraid to go back to tables for some elements, if it won't interfere with your technical design goals. The semantic markup people would shake their heads at this, but unless you really need a semantically clean document, it's foolish to waste time hacking the CSS to work on buggy browsers or support features it doesn't yet. It's good to have a clear idea of what you're using CSS for, so you can make intelligent decisions about these things.
• As always, when problems arise, Google is your friend. Chances are someone else has had the same problem. Google around and the solution is probably just a few mouse clicks away.
• But a human friend is still even better! Without Dave's advice, this effort would have taken way longer. If you don't already have a friend who is familiar with the ins and outs of CSS, make one.

Now that I've got the main document structures nailed down (so hopefully the worst is behind me) I'm glad I made the switch. I'm excited about the new design; it's getting difficult for me to use the old site now that I know something better is just around the corner.

[ Permanent Location ]

A Systemic Problem with Software

design, software development, systems

December 24, 2003, 11:33 AM

One of the core themes you'll find running through this weblog is an approach to analyzing problems from a systemic perspective, that is, an approach that examines the structure of the larger systems these problems exist to gain a deeper understanding of their causes. Recently I've been thinking about systemic problems in software design, and I wanted to articulate the one that's especially jumped out at me.

First off, lets assume a world in which all our dreams have come true. Human-centered design is the norm rather than the exception. Efficient production and distribution models have arisen for software design and development, and the market is perfectly in tune with the needs of its end-users. Sadly, the following problem would still plague us.

Here's the crux of it:

1. Designing good software requires maintaining a strong focus on a small, well-defined user group. Cooper makes this argument, and it's pretty well-known to anyone who has done serious interface design work. Different people have different needs, and any interface that tries to be too general, that tries to do everything for everybody, will only wind up being mediocre (at best) for many, and completely unusable for the rest. Feature creep and the complex, inelegant interaction designs that inherently accompany it will see to that. This is partially why Word and Windows suffer from so many usability problems; they are trying to satisfy too many disparate user groups.
2. But people need to work together, so their software must work together too. Users need to exchange documents, send each other messages, work collaboratively on the same artifacts, etc. If they software they use doesn't support this, it cannot fulfill their goals.
3. If people have different software, this creates an interoperability problem. Different software systems, especially those made by different companies, are notorious for causing problems with interoperability, from the old issues with opening Wordperfect documents in Word to modern problems with viewing web pages in Safari that were created for Internet Explorer.
4. There will always be tension between focused design for usability and generalized design for interoperability. Often, the result of this situation is that natural monopolies get created in the software market, such as Microsoft. One company produces a "one size fits all" solution that everyone uses to avoid the problems with interoperability, but which fails to fully satisfy anyone's needs.

So what can be done about these problems? One option is to explicitly design software to interoperate with other software, which I've discussed before. But it's hard to design two pieces of software so that they communicate together effectively, even when you have full control over both of them. And designing for connectivity with all the software your customers might potentially be using quickly creates an exponential complexity problem.

The obvious solution is to define software standards and design to conform to them. However, we know that usability is not screen-deep, so these standards may put limits on the usability of the final products. Ideally, the standards should be developed while following a user-centered design process as well, but here we come back to our original problem; standards by definition must take the needs of many user groups into account, which is inherently difficult to design for. What usually happens is that standards arise from the experience of many product development efforts, and attempts at standardization that occur too early fail as vendors ignore them in favor of adding proprietary capabilities to their software to fulfill their customer's needs.

I don't see any obvious way out of this messy process, dictated by the structure of software design and development. My guess is that firms must do the best they can in the particular situations they find themselves in, and work to enhance the standardization process so that less time is wasted discarding inappropriate standards.

[ Permanent Location ]

A Usable Open Source Software Community

design, society & sociology, software development, usability

December 18, 2003, 10:42 PM

I've written a lot before on the subject of bringing usability to open source software. I've been silent on the topic recently, but not idle; I've been working diligently all semester long with my friend Dana Gelman for our CSCW course on a project to design an open source community that has the tools, techniques, and participants to develop products that can effectively target end-users.

Our core recommendation is that existing open source communities that develop applications targeting end-users (for our purposes, "end-users" will be shorthand for "users that are not like the developers") should invite usability professionals and interaction designers to participate in the development efforts. This is harder than it sounds, however, since existing, developer-centric communities will have to change the way they work to make room for these new people with new skills. To begin to paint a picture of what this new, integrated community might look like, we have developed eight specific recommendations for any OSS community that targets end-users.

1. Involve usables in the core development team. Our literature search has shown that most OSS projects have a small team of one or more developers that do the bulk of the work. On large projects, this team is responsible for decisions relating to the high-level architecture and organization of the code. We propose bringing interface designers into this team to take responsibility for the user experience, including defining and maintaining the core metaphors, ensuring interface consistency, and other high-level duties. These participants will also need to interact closely with the core developers to determine implementation tradeoffs, which is why they're part of the same core team.
2. Incorporate personas. I've already argued extensively for this recommendation, so I won't say much more of it here, except to note that to be effective, the personas must be used and valued (in particular, they should be frequently referenced by name) in design conversations throughout the community.
3. Build small, heterogeneous teams of developers and usability people. Small teams are more productive, and can focus on the details of an interface design with a minimum of overhead.
4. Modify the joiner script to require newcomers to justify design decisions with the personas. Open source communities have an implicit cultural barrier to entry called the "joiner script" that sets a standard that new members must live up to in order to become contributors to the project (think of it as a very long interview process). We recommend not admitting contributors (both developers and usability people) who are unwilling to justify design changes and feature requests in terms of the personas' needs.
5. Use synchronous communication (chat) for design meetings. Synchronous communication is more efficient at building shared understanding, which is essential for making effective design decisions.
6. Transmit design decisions back to the public list. The previous recommendation introduces a problem, however. People who are outside the immediate circle of the design team (contributors working on other parts of the project, contributor hopefuls, users, etc) also need to be kept in the loop about the design decisions that are made and the rational for them. For this reason, someone needs to be willing to summarize the synchronous design conversation and post it to the asynchronous communication medium in use by the project (e.g., a mailing list or discussion board) so these other followers can get access to it.
7. Provide a shared visual information space. We recommend using a shared, visual information space (like a shared whiteboard application) in parallel with synchronous chat for design meetings. Design is a very visual process, so having the easily accessible graphical space to work on rather than trying to describe all interface changes linguistically is necessary.
8. Modify bug tracking tools to better support collecting usability issues. Bug tracking tools are often used to record change requests as well as bugs in open source projects. On large projects, however, we found that they often break down as large numbers of UI problems pile in and contributors must spend time sorting through them. We propose developing more efficient bug tracking tools that are capable of handling UI issues as well as code bugs. We have not yet defined the form such a system must take, since this is really another semester project in and of itself.

Dana and I have put together a final report that contains more comprehensive descriptions and extensive arguments for these changes, ties our assertions back to the literature, and describes an experiment we are proposing to test one aspect of our solution (how personas change the design conversation in an integrated open source and usability community). I haven't made this paper publicly available (yet) since we're hoping to publish portions of it at CHI or CSCW and I don't want to run afoul of prior publication rules. But if you're really interested, drop me an email and I might send you a copy.

[ Permanent Location ]

Architect Programmers

funny, software development

December 01, 2003, 10:56 AM

This is exactly what many software architects have to deal with, so this analogy is more true than even the author of this joke thinks. I'm all for understanding the user's needs and all that, but that doesn't change the fact that some people have irrational "needs". I propose all managers be required to take a sensitivity course ("So You've Decided to Fund a Software Project...") before they're allowed to talk to a development team.

[ Permanent Location ]

A Naked User Interface

design, software development

November 27, 2003, 01:40 PM

Dave Thomas, one of the Pragmatic Programmers, has an interesting ramble on his weblog that covers a variety of topics of interest to user-centered designers. His analysis of Raymond's discussion of X windows and its lack of imposition of a standard look-and-feel versus the Windows / Mac approach of imposing lots of constraints and standards on interface design is quite interesting in its own right. I'll leave it as an excercise for the reader to reflect on whether the X windows framework is truly independent of human factors and interface design, as Raymond claims (given my writings on the impact of software architecture on usability, you might be able to guess where my feelings lie...).

What I want to focus on, however, is Dave's discussion at the end of "Naked Objects". Naked Objects are a pattern for structuring a software application that has huge implications for interface design but which hasn't gotten much press in the interface design community. As some of you may already know, most software code is structured in terms of objects, software modules that aggregate data structures and the procedures that operate on those data structures. Some of these objects appear directly in the domain the software is being developed to support; for example, a web storefront system will probably include objects like "Product", "Customer", and "Order". Other objects are more esoteric and relate more to technical implementation considerations than the domain itself, but for our purposes we can ignore these and concentrate on the "domain objects".

In a Naked Objects system, the "user interface" of the application as it is commonly conceived is stripped away; instead the system provides a minimal UI that allows users to create, destroy, and manipulate domain objects directly. Now I know many of you are thinking this sounds crazy, but there are a few advantages:

• Exposing the object model to the users ensures a match between the development team's metaphors and the users' metaphors, which provides a shared language for both stakeholders. I've advocated this in the context of XP, but it's important regardless of the development methodology. This has the additional benefit of allowing for user feedback on the domain model as well as on the interface design; most interfaces hide away the domain model which prevents users from commenting on it except in the context of abstract engineering diagrams.
• In a way, Naked Objects is the ultimate minimalist user interface. The designer provides only the bare essentials, fleshing out the tasks is left up to the users themselves.
• Since the user experience design is intimately tied to the internal software design, this approach ensures close collaboration between the interface designers and the software developers, something that doesn't happen often enough in practice.
• Naked Objects eliminates lots of user interface code, which leads to lower cost (less code must be developed, requiring less expensive developer time) and higher reliability and maintainability (less code is easier to test and modify).
• Naked Objects potentially allow for much greater user control over the system than conventional interfaces. In a Naked Objects system, the user defines the ways the objects work together to accomplish her tasks; the tasks aren't "pre-canned" for her by the interface designer. This also allows her to work in ways that the designers did not forsee or intend. Note that this is the basic problem confronted by designers of interfaces that support creativity.
• This level of user control transforms the user from a follower of a proscribed process into a solver of problems. This is the difference between mechanism and policy that Dave's post focuses on. In some domains, this may lead to greater user satisfaction since people prefer to actively solve problems rather than mechanically follow algorithmic task flows.
• It's potentially easy to create both a Naked Objects and a conventional interface for the same application, to provide more power for experts while still giving guidance to novices. Dave mentions the difference between the Mac Aqua interface and Darwin's command line shell as a similar approach.

One might wonder if a Naked Objects system really requires an interface designer, since it appears to have so little "interface" to design. I'd guess that it would, however, both to ensure that the interactions used to create and connect objects are simple and intuitive and to ensure that the naming and behavior of the objects themselves are appropriate. So given that designers are necessary, what techniques would they use to design such systems? And what systems might a Naked Objects approach be appropriate for? My guess is that experts would benefit more than novices, since Naked Objects gives very little task guidance and assumes a great deal of familiarity with the domain. As I mentioned above, perhaps interfaces that support creative tasks are a good candidate. In a way, the direct manipulation paradigm found in Photoshop and other graphics packages is a similar approach.

I'd encourage designers to seriously consider these questions, for I think this approach is interesting and may be more applicable than it initially appears. It also shows that sometimes interesting interface ideas come out of the software development community as well as the usability / interaction design community.

[ Permanent Location ]

Maintenance Projects and U&SA

processes & methodologies, software development, usability

November 22, 2003, 07:06 PM

Turns out Dan wrote an article for Boxes and Arrows about a year ago titled "Tackling Maintenance Projects". The article is excellent and I recommend reading it. What I found most interesting, however, is how Dan's advice relates to the impact of software architecture on usability.

Dan draws a distinction between "Atomic Maintenance Projects" (more or less complete redesigns, of potentially both the interface and the underlying implementation) and "Neutron Maintenance Projects" (small changes that serve as point solutions but may not address the larger usability issues). The problem he observes is that often your client thinks they only need a Neutron fix, but after inspecting the interface you realize that an Atomic redesign is necessary to achieve adequate usability. In his words:

And there’s the rub. Often, IAs are left to wrestle with decisions that were made long before their involvement with the project; decisions that people in the company may not even like but are stuck with. Or decisions they have a vested stake in keeping intact. Or decisions various forces in the company (IT, Marketing, and Legal being typical stakeholders) insist must remain, for reasons the IA may or may not agree with.

Our hope with U&SA is that by bringing usability professionals (or designers or information architects or what have you) into the process at the system architecture design stage and giving them the intellectual tools they need to understand how to effectively contribute, we can reduce the need for Atomic projects so that more usability issues can be dealt with at the Neutron project level, which, as Dan correctly points out, is often insufficient given the current state of the practice.

[ Permanent Location ]

How the IT Industry Really Works

funny, processes & methodologies, software development

November 19, 2003, 04:29 PM

This cartoon is an oldie (I think I first saw it in "Developing User Interfaces" by Hartson and Hix), but it's worth repeating. It's a great 8-pane summary of the product development communication problems that I keep rambling about on this here forum.

[ Permanent Location ]

Discussing Disconnects

design, processes & methodologies, software development, usability

November 15, 2003, 07:08 PM

At the SSS two days ago, I led a discussion on how we can bridge the gap between interaction designers, usability professionals, and software engineers working together on real-world development teams (as I promised I would). I started out with a quick presentation describing the personalities and goals of both "players" (designers and developers) through some rough personas, then opened the session up for discussion on what techniques might help in getting these two players to work together effectively.

Here's a list of the possibilities that were thrown out for consideration. If anyone out there in readerland was at the discussion and notices something I missed, please do add it in a comment.

1. Emphasize more up-front design so design and engineering need not work in parallel. The idea is that this will reduce the amount that the two players need to communicate, thus reducing conflicts and making the process more efficient. It was also pointed out, however, that although spending time on up-front design is good, it doesn't solve all the problems. The final design, no matter how good, will still need to change quite a bit based on engineering's input and concerns, thus reintroducing the communication problem.
2. Design must bring engineering onboard. Those who came from an engineering background emphasized the need for design to justify and "sell" their design solutions to the engineering team. The idea is that although engineering trusts design to be good at their job, they will be more effective participants in the overall development process if they understand what the important usability issues are and why the related design decisions were made.
3. Design and development must "live" together. Basically, the two players should work closely throughout the entire process; there should be no "throw it over the wall" style information exchanges. I've suggested this before in the context of XP, going so far as to recommend that the two players work together in the same room.
4. Designers should contribute to development work. Many designers have enough technical abilities to contribute to parts of the user interface development process. In addition to speeding things along, this gives engineering a better sense that the designers are true members of the team. Cooper and Reimann suggest that one individual cannot fill the role of a designer and developer, due to the fundamentally different mindsets, but everyone in the group thought it was possible to strike a happy medium. In order to facilitate this technique, the software architecture must separate the user interface modules from the rest of the application using a separation pattern such as Model-View-Controller (which still won't handle all concerns, of course).
5. Designers should have engineers sit in on user tests. Watching users struggle with bad designs is often cited as a good way to motivate people who aren't willing to buy in to user-centered design. If this is the situation designers face, this is a technique they can try to bring engineers on board. Randy Pausch, ever famous for mistreating his engineering team, requires them to sit on their hands while watching people use their interface, and demands they keep silent unless they are willing to precede their comments with an apology for designing such a horrible interface. This might be a bit extremist for most industry teams to swallow, however...
6. Both players need case studies on how to effectively work together and how not to ineffectively work together. Design and engineering (and management) can learn from examples. Even experienced industry veterans may not associate usability failures with market failures, since these two events are often separated by a long period of time, and humans are bad at associating effects that occur long after their causes. Of course, someone must put together a collection of these case studies before designers and engineers can learn from them.

Perhaps the most interesting part of the conversation, however, was the discussion of the benefits of "creative tension", or those times when design and engineering don't get along yet wind up with a solution that is better than what they would have come up with if they had. Haven brought up the case of the Harley-Davidson VROD, a case study where there were several examples of the designers putting their foots down and demanding that engineering figure out a way to implement their design, as well as examples of the engineers demanding that the designers come up with workable designs. In the end, this resulted in a better product than Harley-Davidson would have come up with had the two sides come up with a compromise solution.

This raises the question of whether it is necessarily every desirable for design and engineering to get along smoothly, or whether a certain amount of tension and controlled chaos is sometimes necessary to produce a quality solution.

[ Permanent Location ]

Radical Colocation is a Good Thing

processes & methodologies, software development

November 15, 2003, 03:32 PM

Joel has an article up on the subject of adopting methodologies for software development. He makes a lot of good points about the state of the practice, but when discussing the subject of whether software development should occur in private offices or public collaboration spaces, he makes the following claim:

But we don't have the data. We don't have any data. You can give us anecdotes left and right about how methodology X worked or didn't work, but you can't prove that when it worked it wasn't just because of one really, really good programmer on the team, and you can't prove that when it failed is wasn't just because the company was in the process of going bankrupt and everybody was too demoralized to do anything at all, Aeron chairs notwithstanding.

This isn't quite true. Earlier this year I came across an article that came from Judy Olson's research group on this subject called "How does radical collocation help a team succeed?". It's an amazing piece of empirical software engineering research that gives some hard data to back up the claim that putting everyone in the same room together increases productivity in software teams. Due to copyright concerns I can't repost it here, but you can find it in the ACM digital library if you're a member. Here's the abstract:

Companies are experimenting with putting teams into warrooms, hoping for some productivity enhancement. We conducted a field study of six such teams, tracking their activity, attitudes, use of technology and productivity. Teams in these warrooms showed a doubling of productivity. Why? Among other things, teams had easy access to each other for both coordination of their work and for learning, and the work artifacts they posted on the walls remained visible to all. These results imply that if we are to truly support remote teams, we should provide constant awareness and easy transitions in and out of spontaneous meetings.

In short, the article found that, in the situation under study (small teams, fixed time frame), radical collocation drastically increased the productivity of the software teams, as measured by a function point count that they compared to the count for the company's standard cubicle setting as well as to a whole industry baseline. They also found that although many of the participants were reluctant to work in the collocated environment at first, they came around by the end of the study. Not surprisingly, they did find that certain tasks with high cognitive demands were hard to perform in the collocated environment due to constant distractions, so they recommend including private "hoteling" areas for such tasks as well as for placing personal phone calls and the like.

The actual article is worth a read if you can get to it, especially since they conclude with recommendations for developing effective collocated and remote work environments based on their findings. And if you're a researcher, the study is a great model of the direction the field of empirical software engineering should go in if they wish to provide the kind of hard data that Joel correctly points out is sadly lacking in the current state of the science.

[ Permanent Location ]