Monday, 14 February 2011

For those who might want to make the leap from Developer to Architect

The last two weeks, actual work has conspired to keep me away from the blog. How rude. I miss "the beach" already.

It seems only fair to summarise the lessons I have learnt whilst masquerading as an architect on a short consulting stint with Marc McNeill.  Simon Brown at Coding the Architecture is much better at talking about this stuff than I am, but I need to update the blog with something!

1. Ask dumb questions
Someone's called you in because they want your help, and presumably if their problem was simple they would have fixed it already.  You're not there to know everything out of the box, you're there to find out what's going on and summarise it. That means asking questions, even the dumb ones.  That's something I learnt off my previous boss.

2. Draw lots of pretty pictures
As a developer, I like to think in code, I like to poke around it to find out what's going on.  But if you want to get a feel for the bigger picture, not having access to the code, or even the documentation, could be better.  It forces you to look beyond the detail.  Sketch things out on the whiteboard to help get the picture of the domain and the systems in your head.

Of course, there's always the worry that your pictures aren't the reality.  That's why you need to...

3. Check your theories/pictures/numbers with everyone
In the first week of the engagement I made some assumptions based on the information I had gathered so far.  Once I'd run those past the architects and developers really working on the code, I found they were only half the story.  The feedback from those guys helped evolve the picture of the current state of play, and shaped the future direction.

4. Take notes
Especially of acronyms used and people's names and roles.

This is probably more a "me" thing.  My memory works as an index, so I need the detail somewhere - I can remember I wrote something about something, and where I wrote it, but I won't remember the details.  I also find that simply writing things down helps to get it straight in my head.  I probably didn't use 50% of my notes, but all that information was in my head.

5. Buy your own whiteboard pens!
I've worked in a lot of places, as a consultant and a permanent employee.  And one thing you can almost guarantee is that the pens in your meeting room will not work.  Or they'll be permanent.

I also bought a board rubber and spray cleaner, but that's probably my OCD....

At the end of an intense two weeks we had delivered:

  • A picture of the existing architecture
  • Pictures of three phases of future architecture
  • An approximate roadmap for delivery
  • Guide estimates for the stories discovered
  • ...and pages and pages of supporting diagrams and information.

The air in Les Alpes must've helped get the brain moving!  Of course, I took my camera on my little jaunt to France.

It was a great first role for me at ThoughtWorks.  I worked my socks off and thoroughly enjoyed it.


  1. Wow! Great thoughts. You're now back again as a developer or what's your role?
    I recently became a Solution Architect, responsible for evaluations, collaboration and finally also implementation. So, holding the umbrella over all. And this post impressed me.

    Although you may know a lot technical things, never forget the easy things and soft skills, which are so naturally.

    Of course, you're blog is now on my Feed.

  2. Thanks very much, I'm glad you liked it!

    I'm back as a developer now, but hoping to continue playing both games in this consultancy lark.

  3. Point 4 has a special resonance with me as my memory isn't great; I remember I read something, just not what that something was! I like to think that my memory is simply being efficient as it doesn't need to remember knowledge that is stored "in the world" as I can just find it again ;-)