It all depends where you’re going (and where you start)

As developers, our main task is to make the journey from A to B. A is you and the idea of an application, and B is the actual application, working well, a happy client and job (or flow of work) security for you.

As with any other journey, how you make it very much depends on where A and B actually are, and how they’re connected into transport options.

Where I live there are three viable transport options: a 4-wheel-drive SUV, a tractor and a horse. When I lived in London I walked, bused and used the tube. A tractor or horse would have been pretty hard to park.

If I was going further afield, walking, bussing and tubing weren’t enough. I added trains, planes and boats to make my way around Hong Kong, San Francisco. I once worked on film in Norway where we used a helicopter to travel between two locations that were only 100m apart on the map. There was a raging unbridged river and a 1000m altitude difference between them.

When I develop an application, my choice of frameworks and utilities, and how I use them, is my mode of transport. I need to consider

  1. the distance between A and B
  2. the proximity of A and B to existing transport options
  3. how many people need to travel together
  4. the reality of the terrain

To be clear – this metaphor is about how you get to the destination, it’s not about how individual classes communicate with each other. The choices you make will then dictate the code. You, your team’s collective energy, is the precious part.

Code doesn’t get frustrated, feel disappointed or fail to turn up for dinner on time.

Prioritise your process over your product. Without your work, there is no code.

The reality of the terrain

The original London Underground Map is iconic – but it’s also a lie. This alternative version actually shows the distances between the stations:

Geographical map of the London Underground (Wikipedia)

Another perspective: Geographical map of the London Underground (Wikipedia)

This geographically accurate map still doesn’t tell you that it’s virtually impossible to cross the road between Euston and Kings Cross, or that changing between some lines requires a major hike and 3 long escalators, while switching between others is a 20 second hop across the platform.

But, it’s a better guide for choosing whether to walk or get the tube than the schematic that shows most stations as equidistant.

The more accurately you can assess your terrain, the more likely that your journey will go smoothly.

How many people need to travel together?

My least favourite part of daily commuting in London was the tendency, in the summer holidays, to step off an escalator and straight into the back of a stationary group of foreign students, identifiable by their matching backpacks or jackets.

If you want to keep a group of developers together, there are better ways to do it than to use a transport option suited to individuals and then have to congregate regularly to ensure that you’re all going in the same direction. Hire a minibus.

The proximity of A and B to existing transport options

I once lived right next to a bus stop. I could actually see the bus coming from my apartment, and make it to the bus stop just at the right moment. As you can imagine, I used the bus a lot. Most other people thought the bus was a crappy option – I guess they lived a long way from a bus stop on a useful route.

The robotlegs MVCS trousers use the eventDispatcher as a shared communication channel not just because events provide great decoupling if used in this way, but because the cognitive distance between any AS3 class and an EventDispatcher is negligible.

They’re also programmatically near to almost any class. If you’re plugging in a utility, or using a service, or working with some existing views, the chances are that they are ‘near’ to a way to attach to the shared eventDispatcher. You might wrap them in a proxy or mediator to take the final step, but you don’t have to take three extra modes of transport just to get started on the journey.

The distance between A and B

You do not need a framework for a 2 hour project. You probably don’t even ‘need’ object oriented code. Write a functional-style script. Do not charter an airplane to go to the store.

At the other extreme, cycling your way around the world is possible but damn hard work. If your client is paying you to get from A to B, they will rarely pay for you to do it by bicycle.

Mixed transport approaches

There is no single pattern, or approach, that can take you the entire journey if you’re going more than a short distance. You’ll need to combine transport options. Mindfully. The connections between these modes are where you lose or gain energy and time. Sometimes it matters that the choices are consistent, other times it’s irrelevant.

Identifying where it matters and where it doesn’t is hard. One of the things I like about the robotlegs mvcs trousers is that, applied cleanly and out-of-the-box, the framework makes it hard to get lost. It also makes it easy to carry a large number of people on the same project – as long as your ‘parts’ fire and respond to the correct events, we’re golden.

Again – I’m not talking about the code here, I’m talking about what you do, how you work with it, how irritated you feel when the client wants to add or change something, how much cognitive load you carry when you work on a class, how much technical debt you amass to keep you awake at night.

How do you feel about directions?

I shan’t resort to poor stereotypes about men preferring to drive round in circles here – my (female) partner can’t stand being given directions. She just wants to know where she needs to be, and she’ll work it out herself from there. She actually gets angry if you start to tell her which way to go.

I do like to get directions. If someone has travelled my journey a lot, and they’ve learned to avoid a particular street because at least half the time it’s snarled up with traffic, I am grateful for that advice.  If RyanAir are cheap but never, ever get you there on time, I want to know that too.

My assumption is that because best practices have been developed through experience, if they were sucky processes they wouldn’t have been tolerated long enough to become a best practice.  Over the years, coders have travelled journeys similar to my own project’s A-to-B, so when they say “take this path” they’re not just telling me that it’s the right direction, but also that the route isn’t boggy and doesn’t involve rock climbing – so I can walk if I like.

When we debate approaches we often confuse the code with the process.

So – I’ve well and truly worn out this metaphor. Just one parting thought: Don’t fall asleep on the train. Waking up in Cockfosters with a hangover at 1.30 am is no fun.

About the Author

I'm an actionscript programmer living and working in a tiny village in the Yorkshire Dales, UK. I used to be a TV reporter, but my inner (and often outer) geek won. I also write stuff. Most recently Head First 2D Geometry.

Visit Stray's Website

Share the post

Delicious It Digg this! Stumble this! Share on Reddit Share on Buzz Share on FriendFeed
  • robin wilding

    “Waking up in Cockfosters with a hangover at 1.30 am is no fun”

    Hah – done that a few times both in and out of the metaphor!

    • Stray

      Could be worse… the N29 to Wood Green goes a very, very long way. Though at least there’s always the option to stay on the bus and go round again.

  • Michael Cann

    Nice article Stray! I totally agree with what you are saying, another analogy is to use the tool that fits the job, you wouldnt use a big sit-on mower to do a small front-lawn.

    On a different note, do I smell someone preparing to write a book perhaps? With all these little breakout boxes and tips and things it reads like a book ;)

    • Stray

      I think it’s more the other way around – once you’ve written a book it’s hard *not* to do breakouts and subtitles and stuff. You get in the habit and it’s hard to shake :)