One of the online lists I read frequently has been debating the proper metaphor for the software development environment. The building trade has been used quite often in the past. In fact, we use the term “architect” quite frequently, although ten software engineers will probably give you ten different definitions of what an architect actually should do. The on-line group recently explored metaphors for the person who guides the feature prioritization. (eXtreme Programming followers would call this person a Customer. In a custom software environment, this might be the business analyst. In a product oriented environment, a product manager plays this role.) We turned to ships and explored pilots and captains and navigators, all of whom fit in one way but not in others.
I think there is no single metaphor for software development roles because there is not a single software development environment. Metaphors can be very useful in terms of exploring various roles and duties. Just as the XP method of coming up with a system metaphor leads to creative problem solving, so I’d like to explore a new set we might use to communicate roles within the software development environment.
Music as Metaphor
The world of music offers some very interesting metaphors. In my personal experience, more programmers play music in their spare time (or used to) than design houses or office buildings, so I think it is a more understandable world from which to draw. And just as there is no single software development environment, there are many rich methods of creating music, and very different methods used to create unique kinds of music.
Symphonies and Large-Scale Systems
I’ll start with the classical music world, with which I have little firsthand experience, so forgive any errors in the metaphor, please! A composer creates the music, writing the score note by note for each instrument. A musical director for a symphony chooses which pieces to include in a concert. The conductor works with the team of musicians so that everyone plays together, as the melody is handed back and forth from instrument to instrument, the infrastructure is created for the melody to lay in, and the soloists can be heard at the appropriate time. The musicians work on their parts both individually and together. If you go to hear the same symphony played by different orchestras, they ought to sound more alike than different. A large-scale software project seems to have this same set of roles: someone selects what to build; someone typically makes a fair number of up-front “architectural” decisions; the team leaders work with their individual team members and each other; the programmers implement. Hopefully, there are builds that test whether all the parts work together as designed and intended! Just as more things are defined up front, there are more opportunties for things to be misinterpreted or incorrectly built.
Jazz Bands and Small Teams
Contrast that with a small jazz or bluegrass band. There may or may not be a true leader, but in most small bands the individual members have a lot of input into what gets played, how it gets played, when it gets played. They still practice individually and as a group, but each performance will have variations as each musician gets an opportunity to solo. You can hear ten bands play the same song and there will be huge variations in the interpretations. Even the same musician within the same band will play the solo differently at different performances, reacting to what the other musicians played, the audience, and so forth. A small development project rarely has most technical decisions made by someone else, although the platform and language may be determined prior to the team being created. Discussions happen and agreements are made verbally, right then and there. There often is no score to update, no requirements document to keep up to date. Whiteboards provide ample opportunity for communication of ideas. Once the decision has been made, they’re erased!
So who is the architect in each group? Is there an architect in the small group? Who’s making what are commonly called “architectural decisions” in the small group?
A more interesting question to me is: Is there an architecture even if there is no architect? To play the musical analogy further, there may be no score but there is still a key, a time signature, and a melody. A musician who cannot read or write music can still create a song and it contain these things. The fact that they are not documented does not subtract from their existence. In fact, often the architecture of the song may be noted down after its creation so that others can implement it and expand upon it. This is rarely done in software circles, except as user documentation. But perhaps that’s all that’s necessary.
One Key Does Not Fit All
The debate about what architecture is and isn’t and who should and shouldn’t make architectural decisions and whether those decisions should be made up-front or in an evolving manner totally depend on whether you’re creating a symphony or a jazz piece. In the worlds of music and software, we would suffer by constraining all songs to the key of C, all projects to a particular methodology. Take advantage of everything you know and pull in what works to your own projects.