The Itinerant Engineer

At Microsoft, there are three major engineering disciplines: development, test, and program management.  Program managers define what the product should do by authoring scenarios and specifications, developers write the code, and testers create automated test frameworks to ensure quality.

There’s a fun create tension between the disciplines.  The stereotypical tester is an obsessive-compulsive geek, who always worries about what could go wrong.  To a tester, a program manager is a pie-in-the-sky idealist with no clue what’s going on, but program managers and testers agree that the product would be infinitely better, if only the developers weren’t so, ahem, incompetent.

Some teams adhere strictly to disciplinary roles, (“I’m a tester, I don’t make those kinds of decisions”), while others are more fluid — everyone contributes as best they can, to get the work done.  I’m a big believer in the second model, where everyone contributes what they can.  Developers are not even remotely interchangeable, Joel Spolsky insists, and I think he’s right. We’re all good at different things, so it makes a lot of sense to parcel the work out based on who’s most fit to handle it.

I had a good opportunity to bridge a disciplinary boundary this week.  Shi, one of our developers, is facing a big backlog of bugs, and my manager has been busy trying to get our internal partners onboard with a big project we’re doing.  Faced with the choice of (a) working on some bugs or (b) doing nothing, I decided to take the gloves off and hack some C.

A few years back, Rob Mensching, one of the old hats, developed a tool called ESD Box (short for “Electronic Software Distribtion”), which we use to create self-extracting binaries.  ”Boxtool”, part of ESD Box, consumes an XML manifest describing how the self-extractor should work (which files it should contain, what it should launch post-extraction, etc.)  Boxtool creates a cabinet containing all the files we’re distributing, and then glues the cabinet onto the end of a boilerplate binary (“boxstub”) to create the redistributable package.

ESD Box works well, except for one annoying “feature”: it extracts all its files into the working directory, not a temporary folder, as is customary with most self-extractors.

Over the past two days, I waded through a few hundred lines of gory C code, extending ESD Box to allow selective extraction into a temporary folder.  In the process, I learned a lot about the Windows dialect of C (LPCWSTR, DWORD, lstrcmpW(), etc.), but moreso, I was reminded of how spoiled we are, up in .NET/Java/Python/Ruby managed-land.  Something as simple as copying a string (copying a string!) requires several function calls, because as we all know, strings are not a first-class primitive in C.  The entire experience felt like visiting an old friend, as the memories of nights spent hacking Linux Kernel code rushed back: string allocation by double-indirection, sizeof(), null dereference checks, the -> operator…

There’s something romantic about programming on the metal.  But I feel like it would get old, if I did it every day.