Archive for March, 2004
On Human-Oriented Architecture
On Artima: Human-Oriented Architecture
Resume-Driven Architecture
I love that phrase. I can’t wait to use it the next time I see it happening.
It’s the practice of choosing technologies to solve a problem based on their percieved future value in relation to one’s own employability. Packing your resume full of buzzwords at the expense of building an appropriate solution to the problem at hand.
While Hohmann and Venners discuss how this damages the architecture, I think it also underscores the folly of how developers and employers alike tend to value technical skills (APIs, protocols, languages) over higher-level skills. From time to time I look at my resume and think that J2EE, .NET, SQL, WSDL should all be ticker symbols on a Software Skills Futures market somewhere. They go up and down in value. My value to an employer isn’t simply a weighted sum of the popularity of these technologies multiplied by the time I’ve invested in learning them. My value is in my ability to:
- Understand all the essential facets of a problem domain. (a language/communication skill, not technical)
- Draw a concern-balancing map of the solution space onto the problem domain. (a design/process skill, which is more technical but still heavy on collaboration and communication)
- Follow the map to its conclusion, which is correct, executable code. (the implementation phase, where knowing all the nuts and bolts of the actual APIs and languages is finally important)
Note also that this list decreases in size of the time horizon involved when applying these skills.
So why do so many developers to pad their resume with skills from that last category? In most projects, it’s the shortest phase in terms of calendar days and man hours. The first two are much longer, and thus more expensive even when things go smoothly. They also happen to be where all the Big Expensive Mistakes That Sink Your Project get made. Therefore, I suggest that they are more valuable skills than #3.
All I’m saying is that specific technology skills (anything in which you may be ‘certified’) are secondary in importance to being able to select and apply those skills to solve real world problems. That shouldn’t be news, now that I read what I’m writing. And I also realize some organizations have clearly defined roles for analysts, architects and developers within the engineering group, and those correspond roughly to the above three skills. -But the problem comes up when you’re trying to write your resume: “architect” is sooooo overloaded. It’s not clear at all what people mean by it or how the reader will interpret it. It’s a lot clearer how they will interpret “Java”, “C#”, “BEA WebLogic”, and “XSLT” (clearer, I said.) when they read your resume and calculate what you’re worth. So maybe that’s one of the reasons developers want those words on their resumes. Its a technolinguistic risk mitigation device that trades lower possible valuation for certainty of valuation.
Or not.
Interfaces of All Sorts
Hohmann quotes Conway’s law:
Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.
This reminds me of another statement:
API design is language design.
I don’t know who said it, but it’s absolutely true. Expanding on it, I’d say “Interface design is language design”. Just as an Application Programmer Interface forms the language with which a developer may communicate higher-level meaning, the User Interface forms the language with which an end user may create higher-level meaning.
Test-first development and user interface prototyping are actually very similar exercises. When writing unit tests first, you end up thinking more from perspective of another developer using the class (which is an implementation of an interface, which as I pointed out above, is also a language). You end up creating a more effective language out of your interfaces this way.
It’s like doing a usability study on your own code at the API level.
Hmm, this unit test is two pages long. If I change my interface like so, it all becomes much simpler.
Maybe skill number 0 in my list above should be “0. Be able to put myself into other people’s shoes.”
Eternal Sunshine
Last night, I saw Eternal Sunshine of the Spotless Mind with two close friends. All I said was, “hey, wanna go see that new Jim Carrey movie?” thinking that they knew it was one of Kaufman’s films. They didn’t, and it took them by suprise to say the least. One said, “Holy shit. I think that’s got to be the best movie I have ever seen.”
I didn’t think Kaufman could top Adaptation, but Eternal Sunshine was even better.
If you haven’t seen it already, GO SEE IT. For extra credit, bring two recently divorced friends. After the film, talk about your past relationships and how it all relates. Try not to get all choked up.