DevSource: You've worked on a lot of things. What have you personally accomplished that you're most proud of?

Sells: Of all of the work that I've done, the thing that I'm most proud of is building the team that designed, developed, tested, documented, shipped, supported and maintained Gen<X>, a code generation tool that's since faded into obscurity (although I see echoes of it in current tools). I don't know if the product itself wasn't packaged properly or wasn't something that was actually saleable, but those were details that I didn't have any experience in, so left them to marketing. The thing that I concentrated on, we pulled off wonderfully.

The Gen<X> story started during my COM consulting days, when I'd wander the country helping people with their designs and then building them a vertical slice of their application as a reference. Their job was to replicate the components at each level horizontally, primarily using a highly sophisticated code reuse technique known as “copy 'n paste.” I always felt bad that I got to do the fun part, leaving the grunt work to my clients, so I was on the lookout for a language that I could use to write them a template of the code that they needed, letting them generate it automatically instead of manually. The night that I figured out not only the right syntax to use for this code generation language, but also how to implement it, was a sleepless one for me. By the next morning, I had implemented a prototype and resolved to productize it.

After that, I started using cash flow from my teaching and consulting to pay contractors to start building the pieces that I designed. I worked with contractors all around the world for a year doing this, doing less and less teaching for DevelopMentor (DM). However, DM's founders didn't like this because they wanted to keep their “brains” in the family. Also, they wanted to expand their business into other, more scalable areas and a code generation tool to capture and deliver implementation knowledge seemed like an attractive area to enter. After a year of spending my own money to develop Gen<X>, I was acquired and made the Director of Software for DM's Oregon branch.

Part of the stipulation of my acquisition was that I would have the ability build a real team to deliver software. Ultimately, this resulted in several full-time employees, i.e. a project manager, a QA director, a QA engineer, a documentation author, a support engineer, three software engineers and a salesman, as well as a team of contractors still spread around the world. We started in a cramped residential apartment with duct tape on the floor to keep us from tripping on wires and ended up in a very nice, software engineering friendly office, complete with a conference room, a lounge and a stand-up Galaga arcade game (the latter being purchasee with my own personal money, however, so it wasn't so opulent).

But much more important than building the office and the product was building the team and the process. I'm still convinced that the DM Software (DMS) team was the best, most efficient, most effective software development team that I've ever been on. In fact, it was the first time I'd been on a functional software team ever, so when I built it, I was really putting my own ideas to the test. Some of them were right, but a bunch of them were just wrong. Those three years, I learned more about the difference between software development and software engineering than I ever suspected there could be, the former being the act of designing and writing the code, while the latter includes not only the code by the packaging, shipping and the people.

For example, one of the most difficult things about software engineering is coming up with an accurate software schedule. For the first version of Gen<X>, because of advice from John Robbins (my chief mentor during this period), we were dead on for the schedule of the software development, but we were off by 50% on the product cycle as a whole. The problem was that without experience, we had no idea how long it would take to debug and ship our code (a full 50% of the total development time was debugging). After that, however, we were able to schedule a six-month development project to within a week or two, which is an accomplishment that I've yet to see matched by any software team that I've been on.

One of the other processes we developed was a way to get good, responsive beta testers. We used a set of surveys to narrow folks that said, “Sure, I'll be a beta tester” to “Yes, I'll give you valuable feedback and here's some for you even before I get the bits.” Those handful of beta testers were far more valuable than a world full of download-and-say-nothing beta testers that seems to be today's standard (I know; I've been one of those beta testers, many times).

Another process that we adopted came from Steve Munger, our QA Manager. Without him, I'd have been completely lost. For instance, he taught me how to do the math on successive QA cycles to extrapolate bug counts into a ship date. The idea is pretty simple. If you reduce the number of bugs by x% between full test coverage QA cycles, and it took you y days to fix z bugs, you can predict how many more QA cycles you have to go through to get to zero bugs, and therefore how long before you're able to ship. He was also the one that drew the line in the sand that we wouldn't ship any product before it had zero unacceptable bugs. (That didn't mean that we fixed every bug that was found, but we did fix every “unacceptable” bug, by our team's standard of “unacceptable.”) And it was Steve's lack of dedicated QA staff and his innovative thinking that lead to us having formal QA Days, where we would package tests from the test plan, putting them into a pool for everyone to select from. Every single member of the DMS team would do nothing but test for as many days as it took to get through every test, always making sure that no developer tested his or her own code, and that no one got the same test to run twice. I can't tell you how effective this kind of focus and perspective differential was in leading to the most accurate ship dates and highest quality software that is practical.

Another lesson that I learned from the Gen<X> project that I use to this day is to write the articles as soon as possible in the development process. When you write an article, you have to tell the story of a technology and show folks how to use it. If the story is filled with workarounds and confusing directions, then you know it's time to go back to the drawing board. We used that technique to check the “user experience” of Gen<X> several times. I'm using it now on the Longhorn Developer Center, to get our product teams the feedback they need, to make sure that when Longhorn ships, it rocks.

Still another thing that we did right was to use our own dog food with Gen<X> and to share our Gen<X> use with the community. Because at the core, Gen<X> was a general-purpose text generation tool, our build process started by building the core and then used the core and our own Gen<X> code templates to generate the next level of code and reference documentation. This teased out tons of bugs and yielded interesting bits that we could share with the budding Gen<X> developer community, showing examples of our vision for Gen<X>, and encouraging some amazing stuff from the community itself. I'm convinced that the Gen<X> code templates from us and from the community represent the best way to write the code in the various disciplines that we attacked.

So, being able to start with an idea at my house and build it into an effective software engineering team that shipped multiple products is still the accomplishment of which I'm most proud. It would've been nice to garner riches with the product simply to keep the team together, but I take comfort in the fact that I'm still fast friends with most of the team members. In fact, I still fantasize about bringing them together again on another project.