The Zuulcat Archives

In 2003 I read Kevin Mitnicks book “The Art of Deception”. Mitnick describes how hacking is not about bashing keyboards in a Unix shell but more about talking to people and getting them to slip up — social engineering.

In the same way I realized that building software that matters is not only about writing pristine code — even if that is a great element of it. It’s less about the technology and more about something else.

I first came to this realization around 2005. I had worked professionally for around 3 years, I was young, I was naive — you could call me a technical idealist. I got my first assignment on a big team — when I say big I mean brontosaurus big — a kind of teams within team setup. I was eventually tasked with writing a module for this gigantor project, the language was C++ something I had studied and played around with but had little professional experience of.

Illustration by the great Mikael Brassman.

I started writing the code according to specifications; I was test-driving every line, working hard to make the code magnificent. I can’t recall if it was due to the way the project was structured or because I was programming at a hellish speed but once my work was done I had an abundance of time. I rewrote the whole thing 3 times, got it reviewed and refactored it for weeks on end. It was perfect — I don’t have the code — but the way I choose to remember it is that it was some of the best work I’ve ever done.

I had created this paradise of code but when I took a step back and looked at it from a distance it was an oasis in the midst of a war-zone. Very little else was working, nothing was shipped and my teammates where struggling. I had performed well, the code was good but we had no application. As the feeling sunk in I my soul was slowly crushed.

This is when I realized that in the same way that hacking is not about bashing keyboards in a Unix shell, software development was not only about writing pristine code. I recognized that it was not what we did, but how we did it that mattered. That week I picked up my first agile book.

The project was a behemoth and I was young and naive. That book made very little difference at the time but I often remind myself of this today when I run around my clients’ building popping my beard into offices, hijack people for meetings and posing uncomfortable questions. My primary work tool has morphed from the computer to a trusted Moleskin, whiteboard markers and post-it notes.

I usually carry the official role of tech-lead, agile coach or something similarly unimportant even though what I mostly do is software investigation or archeology — my job is to make sure that the code that is written matters and nobody ever has to feel the way I did back in that project.