Beating the odds - a software story

For the second time in my career I had the great privilege of imagining a software product and seeing it through to release. It started out as a key toolset for another product, then ended up, at the end of its initial product cycle, being repurposed for a significantly larger role.

This isn't the kind of software story you usually read about. We weren't a startup group of young developers, we were a small group of grizzled veterans in a large publicly traded company. We didn't have to worry about VCs, but we had our own version of funding uncertainty. If 37Signals is Superman, we were Bizarro. In a mirror world of software development, we faced our own set of grim obstacles.

Frankly, I'd rather face the obstacles of my startup days but, still, we did succeed. We succeeded because we had a great team (seriously great) and, at critical times, we had close collaboration with a great customer.

Here are a few of the things I learned in the process, in no particular order. In a small way, they were a recursive version of a far more ambitious project I read about many years ago - The Data General Eagle ...

• The core of our team was local, but we had key contributors that were remote. Our collaboration technologies were phones (and teleconferences - 1970s tech) [6], email, a Sharepoint 97 wiki [2], LiveMeeting screen sharing [4], and Rally [3]. When I ran meetings with remote contributors I had everyone dial in. We developed some good techniques for managing remote discussions, including sharing MindManager maps to record and organize discussions. The main lesson here is that you can get good results out of some very limited tech tools -- if you thing hard enough about how work around their issues.
• Early on I spent a lot of thought solving problems we never got to. Some of those imaginings led to patent applications [1], but they didn't have much impact on the product. In a few cases though, those solutions were critical. It was time well spent, but it's worth remembering that the real challenges are likely to be surprises.
• What we ended up with had a lot in common with my earliest designs. I don't know if that means they were good designs, but they did persist.
• The curse and joy of software is that there are so many different ways to solve a set of problems. The trick was figuring out what compromises to accept, even when two good alternatives combine in a troublesome compromise. This wasn't hard within our group, but it was challenging when we had to fit into other models. A mediocre compromise, however, is better than a breakdown in critical partnerships. We threaded the needle.
• Our best decisions weren't coming up with solutions to tricky problems, they were deciding what to keep and what to drop. We had to choose between throwing the seats overboard, or the luggage, or dumping fuel. We couldn't afford to get those choices wrong and we mostly got them right.
• Everyone contributed everywhere. I did everything but write Java code. Our engineers did designs. We were all analysts.
• I like Agile. We couldn't do it fully for several reasons, including the world in which we lived. I think though, we stayed true to the sprit of Agile. Rally helped, though I fear the developers have been too responsive to their customers. There are quite a few rough corners left over. Nothing's perfect, but Rally is pretty good.
• I liked the Agile philosophy of just enough architecture. The key for us was deciding where we needed solid foundations and where we could put up a low cost shed that we'd happily tear down when it decayed.
• There's a trick to choosing between a range of reasonable options. It doesn't matter so much which one is chosen, only that we don't spend a lot of time choosing.
• In the absence of proper resources, a well crafted email with an edited thread attached to a Rally story can be a reasonable stand in for a requirements document.
• Inbox Zero was very important form me. When I cleared my inbox and scheduled my Rally tasks [5] into my calendar I was usually in good shape. When either fell behind I was in trouble.
• No emotion. I worked hard to stay balanced. Things were tough when we were repurposed [7].
• No death marches. We are too old for death marches, it's not an option when you're over 40. Quality goes off a cliff. We rescoped or invented easier solutions rather than pulling all nighters.
• I reported out probabilities of success to management rather than predictions like "we'll do it" or "we won't do it". Somehow that worked better.
• I kept a complexity budget in my head for everyone on the team. We spent our complexity capacity carefully, targeting high value work.
• We kept moving. When we bogged down we stopped and moved on an easier path. There were quite a few obstacles we couldn't control, rather than try to knock them down we went around.

We had fun. It's satisfying to beat the odds.

--

[1] Software patents are a curse upon civilization.
[2] Once you figure out all the traps (don't paste rich text into the rich text editor!) and the trick to embed images, you find out the search is pretty good and that SP's wiki isn't all bad. SP as a document management system is pretty bad, though less intolerable with Office 2007 than 2003. This project made me a Wiki convert. (See also: Gordon's Tech: Vermeer/FrontPage lives in Sharepoint Wiki)
[3] Also, alas, StarTeam. I try not to think about StarTeam.
[4] Only the screen sharing.
[5] I got to write the stories and the tasks then do them. A bit inbred.
[6] I tried very hard to get Google Video Chat working. It failed for us. Partly due to bugs, partly due to a remarkably poor UI, but mostly because the corporate net connectivity was overloaded. This is a more common problem than most realize.
[7] Would have been helpful if I'd done the Conversations - From emotional confrontation to dialog class a year ago, but I'm not sure it would have made that much difference. Managing genuine conflicts and power struggles by phone is less than ideal. We had no travel budget.