Navigating your design

Let’s pretend you’re visiting a foreign country and you want to get somewhere interesting, in order to do so you need to drive to this new place, one where you’ve never been before. And so you get into your (rented) car and all you’ve got left to do is to ask yourself - how to find the quickest/simplest/shortest way from where you are to your desired destination?

In my case Well that question depends on when you were asking me..

Navigation 101

My preferred tool of navigation used to be a simple map. I would find my destination on the map and my point of origin and try to decide the optimal route (or at least the one which is easier to remember) and write it down and be on my way.

But I don’t do that anymore…

multiple-gps-in-the-one-car1

Meet my little friend

 

Nowadays all I need to do is tell my trusty GPS (A.K.A phone) where I want to go and it would guide me step by step until I arrive at my destination.

Unlike the map of days of old – he knows when the road is blocked and can update my route if I made a wrong turn left (as I do from time to time). It even can suggest a route based on current traffic conditions – a trick which my map is yet to learn.

When using a GPS I find that I no longer care about the entire road but only how long do I have until the next turn.

All in all a good driving experience.

What does it have to do with Software development?

If you know me you know where I heading with this, if not – keep on reading.

 

It occurred to me last week while teaching Test Driven Development how similar is this practice to using a GPS – when using TDD I know where I want to get but instead of trying to plan the entire trip in advance, I take small incremental steps (turn right here, exit on the 2nd lane, drive through tunnel etc.) until I reach my destination.

When looking at my code design in that perspective I also understood something else –The practice of designing the implementation before writing code is very similar to planning the trip using a map – it would work for small (short) problems but as soon as the trip/problem becomes too big, too complicated or you run into any obstacles (feature change, design bugs, annoying manager) – the map needs to be consulted again, and hopefully while having a good idea where you are.

Another point where using my GPS and writing my code are similar is the fact that although I write my code iteratively I always keep my eyes on big picture – architecture, use case and so on. In a similar matter usually when using a GPS I’ll have a look at the proposed route from start to end – just to make sure that the GPS does not try to take me through “interesting” terrain (dirt roads - happened before) or somewhere I don’t (or can’t) go to - a particularly faulty GPS has tried to get rid of me by suggesting I pass the border – obviously I’ve stopped using that one.

 

When driving – which to you prefer? the old fashioned, fixed route of the map or the updating, simple directions the GPS provide?

 

I believe the same rule should apply to your code as well.

Labels: ,