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:

1. Understand all the essential facets of a problem domain. (a language/communication skill, not technical)
2. 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)
3. 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.

API design is language design.

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."

I could write this, and use the RDF browser I built for the Texas State Legislature as a starting point. The map would show bands, people, albums and labels as nodes. The relationships would include things like "soundsLike", "playedFor", "produced" and so on.

I wonder what an appropriate URI scheme for uniquely identifying bands would look like. The FOAF gang say it's all subjective so they allow for multiple identifiers, none of which are garunteed to be unique. Your RDF app just has to be smart about how it "smushes" the RDF globs together.

Epitonic and Pitchfork might not be so keen on the idea, but I'd really like to do this. God I love music.