Alan Cooper Interview. Visual Studio Magazine…
Visual Studio Magazine has an [ interview](http://www.fawcette.com/vsm/2002_12/online/the/default_pf.asp) 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 forever."_ > * 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 numbered."_ > > [[Peter Drayton's Radio Weblog](http://www.razorsoft.net/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 know.
_"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) ).