Cooper Interview

Visual Studio Magazine has an

with Alan Cooper. An excellent read, Alan talks
about the differences between engineers vs. craftsmen, the
role of software architects, XP vs. RUP, and his opinions of the
.NET platform. Highly quotable:

  • The role of architects: “Architects synthesize people,
    purpose, and technology. If you just take people and technology,
    you have art—entertainment. If you just take technology and
    purpose, it’s engineering. And people and purpose without
    technology is psychology.”
  • On complexity & components: “Software construction has
    often resembled digging the Panama Canal with a teaspoon. You can
    make the walls of the canal perfectly straight, but it takes
  • How .NET provides portability: “… by providing cleavage
    planes. It’s like cutting a diamond. You can’t just cut one; you
    search for the natural cleavage planes in the diamond’s crystalline
    structure. Likewise, you have to find the cleavage planes in the
    software and break it in two. Those cleavage planes, of course, are
    APIs and the CLR.”
  • On competition: “A Microsoft API such as the CLR allows an
    opening for other language vendors, as does offering Web services
    through XML. It means the days of getting all your services from
    one vendor—or even a single app—are

[Peter Drayton’s
Radio Weblog

This most certainly is a very interesting and thoughtful
article. I’ve been struggling with the contradictory approaches of
RUP/UML vs. Extreme/Agile Programming over the last few weeks. This
week I’ve gone back to basics with UML and started relearning and
redeveloping this skill set anew. Some things that didn’t really
seem to sit well before are making a lot more sense now. What Alan
Cooper says about the two approaches makes sense, but I wonder
about a happy medium where RUP takes care of a good general “big
project” design approach, but XP/AP solve some of the smaller
sub-problems that they’re good at too. Maybe that’s not practical
and would lead down a road of problematic boundaries. Don’t

“Where is it carved in stone that we have to use the same
method for all projects? A carpenter can build a house just fine,
but you can’t use carpenter skills on an aircraft carrier. On the
other hand, if you’re used to building aircraft carriers, with
giant metal shops building giant subassemblies, then you’ll try to
build a small house using giant slabs assembled in a welding shop.
This doesn’t mean what we know about building houses or aircraft
carriers is wrong.”

This applies to more things in life than programming. Choose
your tools carefully (as well as your battles ;o) ).