Building Software that Matters
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.