Street Direction Savvy vs. Being a Good Driver

Whenever I'm doing architecture or talking to managers and such about projects, I always have a collection of metaphors in my head. I've always wanted to pull this particular metaphor out at a party but I've never had the right moment, so I decided to put a blog together about it since it is one of the architecture tools I carry around in my toolbox.

As with all metaphors, there is the danger you take it too far so...let me know if I've done that :-)

In practicing architecture and implementation and especially discussing project planning with people I encounter situations where a distinction is necessary between Street Direction Savvy (best thing I could come up with) vs. what I could probably term as simply Being a Good Driver. What's the difference you may ask?

In the real world, we spend a lot of time teaching our kids the mechanics of driving things: a bike, a skateboard, skis, and eventually a car (by the way, I believe the legal driving age should be 31). The parallel in programming is a person that has spent a lot of time learning the mechanics of a language or a specific part of a platform: Java 2 Enteprise Edition, Web Tier User Interfaces with AJAX, Database Engineering (by the way, I believe the legal age for use of Java 2 Enterprise Edition should also be 31...ITS A JOKE).

(Image linked from eHow)

One thing you quickly realize when you start to drive is that the technical ability to drive something does not make you an expert in getting from Point A to Point B. What's worse, the shortest path from Point A to Point B is almost always mired in complexities such as what you are driving (using a bike to get between points may yield an entirely different route as compared to a car) and what time of day it is (traffic often sends you onto side streets at particular times in the day). Further, what you know how to drive often forms your decisions on how to get between the points (knowing how to drive a bike and then learning how to drive a car yields some remarkably inefficient ways to get between points...often including driving through a neighbors yard (this is frowned upon when you have 4 wheels and 2,000 pounds added to your vehicle)).

As a result, you develop street savvy that goes with the context of what you are driving. Bringing this back to engineering, I like to think that architecture is all about street savvy and the better you know how the architecture is to be applied (how to drive) the deeper an architecture can go. Not only can I provide a map to the engineering teams, but I can also tell them specific platform decisions rather than just wave some boxes and requirements of those boxes at them.

Interestingly, some people never learn how to drive things but they have remarkable street savvy. Other times we are asked to have street savvy but we don't know how to drive what the other person is driving...I was asked by one of the Project Blackbox drivers how to get from Point A to Point B and I was like "are you driving your semi or your car".

This happens all the time as an architect. You end up applying the knowledge of something else that you learned how to drive that is similar. For example, an architect with experience in Swing and Designing User Interfaces may have a valid estimate for a team that is building an AJAX user interface. More importantly, I feel, is that the architect has to be sure to inform people of the differences in various tiers and platforms. Many times you are asked about an individual and whether they could fill a role on another team. People with driving savvy in one tier are often not useful in another tier if they haven't learned quite a bit about street savvy. Someone that has spent their entire life writing scripts in perl may not be helpful building an AJAX Web User Interface, yet it is a time honored tradition that management asks the question of whether the perl programmer can fill a role that needs immediate filling in the UI tier.

More than anything, I believe you are morally responsible for the information you give to people. So why not be transparent when you tell a person that your estimate to get from Point A to Point B is based on a map built for a bike rather than a map built for a car. Also, when asked about resources, feel free to ask questions about the person if you are not fully informed...if you've known someone only in the position as a database engineer, ask if they have experience in the user interface tier and what type of projects they've worked on. Ask if they understand the abstractness of languages and not just a language, this can be a big help...we all know that someone that understands a clutch and how to drive a particular manual transmission will probably be quicker on the uptake of another manual transmission since they get why they are pressing the mysterious third pedal down.

The metaphor works if you think about, enjoy...and let me know if there is a party around that I can use it at or if I can refine it a bit more.


Post a Comment:
Comments are closed for this entry.



« August 2016