« Microsoft's Workplace Advantage | Main | Microsoft Employees are VIPs at DiscoverU »

April 18, 2006

A Former Microsoftie: Kapenda Thomas

I was sitting in a class today where the subject of developers vs. PM vs. test was being discussed. I've written (in Proudly Serving) about how important it is for Microsoft that the test team gain full respect from dev and PM. Unfortunately there is a lot of history there. This is a piece of it.

Back in 1994 I was working as a dev on NT networking. This was in the days when test was just told to deal with whatever dev threw over the wall. In networking we had a huge lab where we ran stress, and we had hired these two contractors to work in the lab. Their jobs were pretty menial ones: they had to wait for a new build to come out, put it on a large number of machines, set up debuggers and network sniffers, start stress tests, and then wait for machines to hang or crash. Since builds came out at all hours of the day and the lab was pretty big, these guys were there a lot.

I remember their names: Bryan LaPorte and Kapenda Thomas. There were lots of contractors working in labs, but I remember those two. First of all, despite the working conditions (which I guess relative to most of the planet weren't that bad), they had chosen to be happy. I didn't think of it in those terms, but that's what it was. They hung out together, listened to music, told jokes, whatever (and being contractors, they got paid pretty well).

But the real thing that impressed me was that Bryan and Kapenda made a serious effort to learn about what they were working on. Whenever something broke in the lab they would call in one of us developers and we would futz around in the debugger or look at the network sniff and eventually decide what the problem was. Most testers would just ignore us while we were doing this work, but Bryan and Kapenda would actually pay attention. Remember this is at a time when they were likely explicitly told that this wasn't their job. They did it anyway, and eventually they picked up enough to do some preliminary analysis on crashes. I mean just basic stuff like doing a stack trace, making sure symbols were right, poking around in memory a bit, etc. but still it was very helpful because it helped route problems to the right developer. They were the only testers (contractors OR full-time) that I ever remember doing this, so I noticed it.

Anyway I was sitting around today and started wondering whatever happened to those guys? So I looked them up. Bryan (assuming it's the same guy) is now working at Microsoft full-time. And Kapenda (I'm pretty sure it's him, since the name is unusual) is now the CEO of a search company in the Seattle suburbs. Pretty impressive, and I knew the guy when he used to rock and roll. There's a moral in here, but it's too obvious to bother.

Posted by AdamBa at April 18, 2006 11:49 PM

Trackback Pings

TrackBack URL for this entry:


I'm surprised that this is not requirement by all testers.

In your book you also talked about the old (NT) times where developer could freely fix each-others code, and the current (nightmare) times where the code must be approved and then committed. Have something changes since then?

How about splitting the repository at 2, stable and developer. Where all developers work on same repository and approved and tested code is moved to the stable one.

On the big scale the problem with debugging is actually problem with the time line. Developers tend to overlook debugging their code if they are late in the schedule. If their ratings are calculated on finished code then they will also get monetary punishment if they don't do so. (am I wrong?).

Fixing this is just a matter of changing definition of finished code to fully tested and bugfree code.

This would have at least 2 effects. Developer would not start writing another module until this one is tested, so he could assist in the tests. He would be full time payed to fix its bugs and he would not need time to remember how him code works. He could even try to improve his code at the mean time.
The other effect is that modules should become smaller so they could pass with less efforts. You also cannot finish modules that cannot be tested. This means modules should be developer in order that provides working system all the time. (just think about longhorn and .net2.0 crap). If you have working system all the time, you can do release anytime you want. This way having some big deadline is meaningless.

I'm sure some people at first may see this as large waste of manpower but actually the fiasco with longhorn/vista shows that the current model is fundamentally wrong.

(well this may be naive but still...)

Posted by: Ivan at April 20, 2006 12:55 AM

In case Ivan checks these comments again, here's an old overview of some of the build process. We're even branchier than that now, but it works something like the article describes.


Posted by: Drew at April 20, 2006 09:01 PM

Ivan, the lab was for stress testing of network components (drivers, transports, etc). The code in question all "worked" in normal operations--that was verified before checkin. The stress lab was for uncovering crashes and hangs and the like that only happened when a server had 200 connections, or an Ethernet was at 50% utilization, etc. Since it can be a hassle to test private drops, at some point you have to declare that the code is solid enough to be checked in, without it being ready to ship. And I would say the code was defnitely in this state before it go to the stress lab.

- adam

Posted by: Adam Barr at April 20, 2006 10:43 PM