SIGIA-L Mail Archives: RE: SIGIA-L: Extreme Programming v. Inte
RE: SIGIA-L: Extreme Programming v. Interaction Design
From: Christopher Fahey [askROM-remote] (askrom_at_graphpaper.com)
Date: Thu Jan 17 2002 - 19:24:05 EST
I've been having a similar discussion with other colleagues. Here's my
take from another list:
----------------------
Hi Nick,
Your post is very thoughtul and even-handed, and I agree that towards
that end you perhaps give inordinate credit to the engineer's ability to
design.
I think part of the problem may be a matter of semantics - what is a
"design"?. Even in the excellent Beck/Cooper debate you sent me, Beck
seems to not even remotely understand what it is that Cooper does.
Depending on who you are and where you've worked, "Design" might mean
"Software Architecture", "Business Workflows", "Database Architecture",
"Interaction Design", "Interface Design", etc, etc. I would doubt that
Beck has *ever* worked on a project where the instructions were "Build
me something that in the end produces the following user experience:
<describe product behavior>", which for me is how a project should be
run.
You and I come in part from the CD-ROM/shrinkwrap software world, and we
both are highly product-oriented. Cooper is also so inclined. When
making CD-ROM games, our worst worry was that we'd be designing for 2x
speed CD-ROMs and by the time we got to market 4x models would be the
norm. My experiences lately working with firms on Wall Street is that in
large businesses there is typically no person responsible for any
particular product, and in fact there is no boundary between one product
and another. Deadlines slip indefinately, requirements change, and every
change impacts dozens of other projects integrally. The systems with
which you are typically integrating are themselves changing constantly
and nobody is responsible for coordinating the separate development
teams. In networked applications, this problem is multiplied
exponentially, as half-finished, ill-considered bits and pieces are
rolled out continuously within a laege enterprise.
It is within this kind of business software culture that XP may be
finding its greatest proponents. The idea that you can nail down
requirements before building a product is (to many software folks)
ludicrous and totally inconsistent with anything they've ever seen in
the real world. In the shrink-wrapped-disk product world (and even to a
lesser extent in the web-launch world) you can define the boundaries and
timeframe of a project. Making children's CD-ROM games forced me to
understand the urgency of seeing a project as a finite endeavor - if we
didn't make the christmas shipment, the product would not sell even one
copy. IN the shrinkwrap world, we have the "luxury" of a
design-then-build model. This is not the case in Beck's world,
apparently, where few projects ever really start from scratch (a typical
business project is: add this feature to this existing system), and few
projects have leadership powerful enough to exert control over and
coordinate all affected systems at once.
The "don't-bother-designing" engineers we've been speaking of exist in a
world where any project that cannot be completed in three months will
probably have the requirements shifted dramatically beneath it halfway
through the design phase, not only through customer whim or changing
markets, but through the nature of the uncontrolled beast that is the IT
department of most large firms.
Imagine you are trying to build a house (there's that metaphor again!).
Imagine you are building on top of a pile of other people building and
renovating houses. And there's a pile of houses being built on top of
you. A big mountain of houses being built and rebuilt by desperate
carpenters, with an overlord who cannot see all of them at the same time
(in fact, imagine that the carpenters get bonuses for causing other
carpenters to fail). If you spend any time planning your house, all of
the other builders will have changed the landscape and your plans wil be
irrelevant. In this world, allowing the carpenter to be able to
architect their house as they build it makes sense, in an absurdly
tragic way.
What is this house-mountain model missing? A manager responsible for the
whole mountain who can arrange production so that each team is
coordinated enough to allow each house to be built according to a plan,
plans built by architects. And each plan needs to be part of and
subordinate to a larger plan. At the top of all this planning is, yes,
an architect with a master plan.
The real question, and one I face every day as a Cooperite "Interaction
Designer", is how to give myself the room within such an enterprise to
be able to plan and build something in the correct sequence,
particulalry with development teams that have never met a guy like me
who can, given a little time to plan, with a design document that will
make their lives a thousand times easier. How can I make the people
around me stop building stuff blindly and participate in planning a
usable product? If Beck was ever handed the kinds of documents Cooper
(or myself) generates before writing code, he'd probably pee his pants
with glee, provided his bosses ever ran their organizations in a way
where this could occur. I've found that it takes a fight, but if you can
convince the right people in management that an engineer-designed system
will piss off customers, they can be convinced to create that elbow room
and allow your project to proceed according to a user- and
interaction-design-centric methodology.
It always seems like these guys are trying to defend the software
practices of Kafka Software, Inc. I doubt, for example, that anyone at
Microsoft or Adobe or Macromedia (or LucasArts or iD or Valve) would
ever seriously propose programming first then designing. Maybe that's
why those companies are so successful and companies like Netscape can't
get rid of 7 year old software bugs. XP is a survival strategy for
working within a wild beast. I think the statement that Interaction
Design and XP can work together is like saying that recipes and napkins
can work together: Napkins are useful for messy dishes, but you cant
cook without a recipe. I guess that's what I mean about semantics.
Apples, oranges, etc.
-Cf
[christopher eli fahey]
art: http://www.graphpaper.com
sci: http://www.askrom.com
biz: http://www.behaviordesign.com
This archive was generated by hypermail 2.1.2
: Sun Nov 23 2003 - 22:54:58 EST
|
