What I do all day

If you're a software geek you were probably asked at some point what it is you do all day. You then do your best to try to describe the code you write in a way which makes sense to you, and which you hope can be grokked... sorry, understood by the other person. But in the end they'll usually just walk away thinking you're doing "something with computers"...

If you're a software geek you will likely "get" what that something is. If only because you've been writing code since you were eight years old. But that still doesn't help you explain this to your friends.

I build cars

This is the earliest comparison I remember, and it comes from a joke where Bill Gates supposedly compares the computer industry with the automotive one: "If GM had kept up with the technology like the computer industry has, we would all be driving $25.00 cars that got 1,000 miles to the gallon." You can probably guess the comeback to that one.

I'm not a big fan of this comparison, mostly because I don't really like cars (I watch Top Gear for the explosions and crashes, not for the reviews :). But it's a comparison that works, to some extent.

So I'm a technical architect. What is my contribution to this car we're building ? Well, I suppose I would be designing the engine and drive train. The brakes. Crumple zones. Etc. What might be surprising is that I don't really care about the body work or what it looks like. That's a job for functional analysts, usability experts and GUI designers. What I need to know is how many passengers it should be able to move, or how much weight it should be able to pull. What speeds and accelerations are you looking for ? What mileage ? At what cost ?

The software developers would be building the car. But, and this is counterintuitive if you've never built software, the developers are really only building one car. Just one. You can't think of developers as the factory workers on a manufacturing line. The manufacturing line is itself a piece of software which can create others. That car you own ? That's just a copy of the one at the factory.

I build houses

My dad was an engineer. People would hire him to make sure that the house they wanted wouldn't collapse when they opened a window. Or that twenty years down the line they wouldn't have to tear it all down and rebuild it just to make it safe again. That's pretty much how I look at my job. Now, because I'm an architect you might think that I actually design the house. Again, this is something which is for the functional analysts, usability experts and GUI designers. My responsibility is in designing the foundations, structural skeleton, the plumbing, etc. --My dad always wanted me to be an engineer; he may not realise just how much that wish came true.--

The foundation of a house is actually a useful analogy. You don't build a skyscraper on the foundations for a residential home. The same is true for software. I can create something simple which is useful to you and the data you have. But don't expect that this same software will still work if you multiply any of those numbers by ten. It will most likely fail.

The physics can also be very different. If you have a roof floor which is supported by two columns then each column will carry half the load. But if you have a software subsystem which is supported by two other subsystems, then each of those subsystems may still be carrying the full load... Spreading the processing load over two CPUs instead of one also doesn't necessarily halve the load on each CPU. This is very much dependent on the algorithms you're using, the communication overhead which is required, etc. Unlike my dad I can't calculate my way out of this. My job is mostly based on experience and experimentation.

I build cities

The analogy of a house works best for software which is stand-alone. This kind of software is rapidly on the decline. Most software you get today will have some form of online services integrated. Or maybe it is fully online, running straight in your browser. The point is that you're not living in one house anymore. You're really moving around a town or city. And these kinds of systems need similar infrastructure: roads, sewers, transit systems, etc.

This is very much the playground of a technical architect. The houses themselves may still require analysts and GUI experts, but the infrastructure itself is mostly a technical matter (if all goes well you'll never see it). But is also very difficult to design because it has a highly dynamic nature. We have to be able to cope with the digital equivalent of traffic jams, for instance. But while you could set up bigger roads, these are also very expensive when they're going unused. Plus you need to provide for possibly varying amounts of policing and fire-fighting. If you're working on, say, a financial district you have to make sure that no thieves get into the offices.

This is also why I find it very exciting to see what Google, Amazon and Facebook are doing with their platforms. They are not just building cities. On the scale they are working you could say that they're building whole countries. And on that scale you need a huge amount of manpower, or you need to start thinking outside the box (and maybe both)...

I build ecosystems

This is, by far, my favourite analogy. The idea that software is something which is (relatively) static has been proven wrong a long time ago. In today's interconnected world this is less and less true. Software grows and it evolves. It spreads. Much like ecosystems. In the same way that we don't want an ecosystem to go out of whack we want our software-ecosystems to be healthy as well. But this takes work and care.

This is how I prefer to see my job: to design and help create a sustainable software ecosystem in which we can all live, work and play.

So...

So I'm not really sure any of this has helped to clarify anything more about what it is I do. If you're still left thinking that I do "something with computers" that's ok. In the end it doesn't make much difference anyway. :-)