What am I?

While I was traveling earlier this month, I read Dreaming in Code. I sat down to write this post thinking I was going to write a review of the book but 1) I don’t like to write book reviews, and 2) this book has been reviewed to death. I do, however, want to talk about my reactions to this book, and as a preface to that, I will write a four sentence (or so) mini-review.

I liked the book. In fact, I probably liked it more than most people (for reasons I will elaborate on below). Most people don’t like the ending. The book did end strangely, but it reminded me of the ending of a great tragedy rather than a book that wasn’t written well at the end. In other words, the end of the book was a downer because of the story – not because of a fade in the skills of the author.

It’s been a long time since I read a piece of non-fiction that I had a hard time putting down. The writing was quite good, and the story will be interesting to anyone who has ever tried to create software, but neither of those were the bits that grabbed me. What hit me was a weird feeling – a combination of deja vu and flashbacks to my own career. As I read, I wanted to yell into the pages of the book, or go back in time and join the team and help them. My reading experience was like reading a predictable thriller – while drawn into the story, at almost every point I knew what was going to go wrong and so badly wanted to yell at the characters on the pages to “make a change now to save problems later.” Instead, the team continued to make mistakes completely unchecked. I constantly had that sick feeling you get when you screw something important up – like the time I was careless and let an important bug slip through in a beta release, or the time I rushed through a code review and allowed one of my peers to check in code that made the daily build completely un-runnable.

I’ve spent some time since reading the book evaluating what I do. I love testing, and think I’m pretty good at it. I have a pretty good idea what approaches work well in which situations, and have always been able to find and flesh out bugs quicker than most of my peers. These days, however, I prefer to focus on anticipating where problems may occur. Bug prevention techniques are part of this, but it’s about people too. I want to work with an entire organization to help them work more effectively and more efficiently. I want to help developers create higher quality code. I want to enable testers to find important bugs sooner. I want to help managers make reasonable and achievable goals.

But that’s not testing – it’s something else. Maybe it’s quality assurance, maybe it’s consultant, maybe it’s something else…or maybe it is testing. At MS, we have a three tiered engineering system – development, program management, and test. Of the three disciplines, I would think that my skills and interest always fall under the test umbrella, but I’m wondering if that’s what I really want to do. I guess this work fits in test better than anywhere else, but I can’t stop wondering if testing is not really what I do, or want to do. Sometimes I get frustrated with “testers” who just want to test – testers who are happy to wait for the bugs to come to them. I wonder if my frustration / confusion is because when I think about what they do, and what I do, that they are two completely different roles.

Whatever the reasons, I value anything that makes me stop and reevaluate myself, and this book definitely did that. Making software is hard – perhaps too hard – we know this, but it seems that we prefer to plod along thinking we know what we’re doing, when we obviously don’t.

Maybe what I want to do is just make software less hard to make (or make the mistakes harder to make). What’s that job called?

Comments (4)

  1. LOL Nice post!

    Carmelo Lisciotto

  2. orcmid says:

    Man, I wish I knew.  I must read that book.  People I know have their names in it.

    From my experience, you are talking about what concerns a system designer.  I think you can consider solution/enterprise architects, according to some great Architecture 101 material from Mohammad Akif: http://blogs.msdn.com/mohammadakif/archive/2007/04/26/web-cast-series-for-aspiring-architects.aspx (and I think this material goes a long way to rehabilitating the productive role of architects).

    I’m not sure software engineer covers it (or is maybe too confining as ordinarily understood), although there is a lot of what concerns senior engineers in what you say.

    But maybe it is about sensibilities.  You are seasoned and you know to look out for risk management and the related warning signs.  Also, I bet you have your eye on the endgame from the beginning, especially with what can go wrong, the failure modes that must be choreographed for the product, and the need for failure response and course correction ability in the development and delivery/deployment process itself.  You can’t ignore lifecycle considerations.

    I feel like I’m writing your horoscope or a really-long fortune-cookie message.  I don’t know what to call it though.  Here we are, a new version of "so … what’s your sign?"

  3. orcmid says:

    With your inclinations about testing, and the attention you give to it, I think QA is pretty relevant too – in terms of process and in terms of methodology and content with achieving a dependable outcome (product and process). Still thinking out loud here. Good inquiry!

  4. alanpa says:

    Thanks for the comments – I don’t really know if I have any good answers yet. The good news is that in my current position I don’t really do any testing or "the other stuff" outlined above, but that will change within the next year as I move out of this org and back into a product group here at the big M.

    The architecture stuff makes sense – in fact, my title is Test Architect, so maybe that’s what I do :}. I love going through this introspection – perhaps I was overdue for something like this.

    Thanks again.