Idle hands

 Your dev team hit zero bug bounce (ZBB) two weeks ago, and suddenly you realize—you’ve hit a lull. Any dev who has hit ZBB on a box product knows about the lull. If your team is on Internet time, feel free to stop reading now. (Wait a minute, where did you find the time to read that first sentence? Get back to work!)

Eric Aside Zero bug bounce (ZBB) describes the first moment in a project when all features are complete and every work item is resolved. This moment rarely lasts. Often within an hour a new issue arises through extended system testing, and the team goes back to work. Nevertheless, ZBB means the end is predictably within sight.

BTW, my team now works on Internet time, and we still manage to have monthly morale events and do our share of reading and innovating. Our secret—lean and agile baby! Read about it in Lean: More than good pastrami and The Agile bullet.

ZBB marks the team shift from being blocked by dev to being blocked by test. (Being blocked by PM has no transition.) After handling the initial wave of new bugs the first couple of weeks after shipping, most dev teams enter “hurry up and wait” mode, pouncing on new bugs when they arrive and otherwise just wondering what to do.

The crazy, scary part is that the lull can sometimes last from ZBB until the first milestone of the next version. That could be months on big projects! A dev manager’s hands are always full, so it’s easy to forget that two-thirds of the team members are idle, and you know what they say about idle hands—well, it’s not good.

Baby did a bad bad thing

Here are a few very bad things that idle devs often do:

• Poach bugs. After ZBB, your team should be in lockdown, which means that all bugs go through triage before a fix is even considered. Idle devs sometimes sit by their desks hitting F5 on Raid (now Product Studio) waiting for a bug to appear. When they don’t see one, they check the active bugs headed for triage, find a juicy one, and start digging. Before you know it, they’ve got a fix and are looking to sneak it in. That’s poaching, and no self-respecting dev should do it.

Eric Aside In software engineering, bugs have traditionally meant mistakes in the code. However, internally we use the term “bug” to refer to anything we want to add, delete, or change about the product. Externally, people generally call these “work items,” some of which may be code mistakes. I prefer the term “work item” so that I know which “bugs” are really bugs.

Who knows if the triage team will accept that bug? Who knows if the dev fixed the right bug, as opposed to a larger or smaller related bug? Investigate potential showstoppers—sure. Poach—never.

• Fix bugs that are not logged. Okay, a bug made it through triage and you are fixing it. You notice other bugs nearby, often related to the original. No one has logged them yet, but what the heck. There you are in the code; the bugs are right in front of you. Why not take care of them now, when the getting is good? Ahhhhhhhhhhh!!!!! Stop right there!

Your team performs code reviews to prevent this evil nonsense. In these days of trustworthy computing, the team should code review every check-in throughout the project. During lockdown, you should code review every change with three sets of eyes (the dev and two other people). As for the other bugs that you find—log, triage, and track them.

Eric Aside There’s a great Calvin and Hobbes cartoon in which Calvin magnanimously opens the front door to let out a fly, only to allow three more back inside in the process. That’s why you study and triage every bug toward the end of a project. Once my team changed the value of a single parameter a month before we released. A week later testers across the company noticed that all applications froze whenever you opened the CD tray. Eventually, we traced it back to the seemingly innocuous parameter, and reverted the change. You just never know.

• Fix postponed bugs. Naturally, you shouldn’t be fixing postponed bugs before RTM, but should you fix them while planning the next version? Uh, no. During the project, the team judges which bugs will have the most impact on our customers and must be fixed—but you have no way of verifying that these were the correct choices until you ship. After release, you no longer have to guess. Product Support Services (PSS), Watson, and Microsoft Consulting Services (MCS) will tell you. Candidly. Use the postponed bugs as a reference to understand why these bugs weren’t fixed originally. But don’t second-guess your real customers. Go to the source to fix the bugs that are really affecting your users.
• Rewrite “yucky” code. Devs hate “yucky” code. It’s embarrassing, unreadable, and unmaintainable. So when they have some extra time on their hands, devs will often say to themselves, “Gee, I don’t have a spec, so I can’t write anything new. How about I rewrite that yucky code I hate instead.” They know that they could do better given a second chance, and they will. Devs will write much better code the second time, and more clearly, with far fewer bugs than the first time they wrote it.

Unfortunately, the rewrite will actually have more bugs than the current yucky code has today because of all the months, even years, of testing and fixes that the yucky code received after it was first written.

Sometimes a rewrite is necessary to make the code more performant, scalable, reliable, secure, or adaptable to new technology. In that case, make the rewrite a feature, and then spec and schedule it like you would any other feature. Otherwise, don’t be a fool and regress a ton of nasty bugs while adding no value to your customers.

Eric Aside This goes for refactoring too, as much as I hate to say it. Even if the refactoring is computer generated, you just never know. This doesn’t mean you shouldn’t refactor or rewrite code, regularly. It means you shouldn’t do so arbitrarily. Decide and commit to it as a team, be sure sufficient unit tests are in place to minimize the introduction of new bugs, and do it right.

• Wage wars over coding style. Talk about the ultimate dev team time suck—arguing over white space, braces, and Hungarian have to be in the top five. Keep this in mind: using a consistent coding style has great benefits to the maintainability and quality of your code base, but the specific style your team chooses makes little difference. You are the dev manager; pick one and go with it. Who said this was a democracy?

Tell me what I must do

Enough of the dark side of idle time. What can your dev team focus on that’s constructive during quiet times?

Naturally, your test team will insist that devs find bugs during the time before RTM, but most devs are terrible at finding bugs, even in someone else’s code. Your PM team will insist that devs spend all their time reading and reviewing specs after RTM, but that won’t keep a dev team happy, engaged, and motivated.

So what can a dev do during the lull? Here are a few ideas:

• Analyze your bugs. Look for patterns in the bugs that your team fixed during the past product cycle. What were the common mistakes for individuals and for the team? What can each member of the team focus on next time to produce a better product?
• Write tools for your group. While devs aren’t often great at finding bugs, they are pretty terrific at writing tools to help find bugs. They can also write tools to smooth out processes, like check-in, setup, build, and prop. Instrumenting code or writing a good harness can go a long way toward promoting good feelings with the test team. Naturally, you should check the Toolbox Web site first to see if a tool that meets your needs already exists.
• Make your PM happy by working on prototypes of design ideas. Writing prototypes is great; just don’t write them in your usual code base. Try a different language or at least a separate build. The big mistake with making prototypes within the normal code base is that PMs and upper managers start thinking that the code is almost ready to ship, when in fact there are often all kinds of issues with localizing, platform dependence, logo issues, roaming, performance, security, and compatibility. Confusing prototypes with shipping code can mess up schedules as well as expectations. In contrast, writing a prototype in another language can be a great learning experience. Speaking of which…

Eric Aside It’s been said before but bears repeating, “Don’t ship prototype code.” It doesn’t save time, it costs time. Just don’t do it. Prototypes are for learning—that’s all. In addition to writing prototypes in another language, I used to hook the escape key to an abort call. That way, if my boss ever got too excited watching a demo, I’d hit the escape key, watch it crash, and then point out, “Of course, it’s not exactly ready to ship.” For more on prototyping see My experiment worked!.

• Learn new technologies or skills. Folks always complain that they don’t have enough time to learn new technologies or skills and that they can’t get the training they need to move up. Well, the quiet times are perfect for this. Don’t let the opportunity pass you by.
• Talk to research. Right after ZBB is the perfect time to talk to the research team. It’s early enough to adopt some new technology and quiet enough to learn about it and figure out what you can use. By the time you ship and begin planning the next release, you could have a prototype ready with all the risks resolved and really wow your team. In addition, you and your research contact can plan new areas of research work that will be ready for future products. This is so valuable and easy to do.
• Write a patent disclosure or white paper. When else do you have the time to reflect and write about what you’ve done? If a dev on your team has come up with a novel idea that added a nice or significant touch to your product, then have your dev write a patent disclosure. It’s easy, short, and a huge morale boost. Go to the Patent Group home page for more details. If you want to document information or share an idea with other teams, write a white paper. It’s relatively easy to do and can bring respect and influence to the author and your team.
• Reflect on your career. Last but not least, these quiet dev times are ideal for examining your career status. Are you where you want to be? Is your career moving in the right direction? Are you ready for a new challenge? What do you need to do to stay engaged and motivated? If upon reflection you feel that you need to make a change, the earlier you put the wheels in motion, the better off you’ll be.

Waste not, want not

Far too frequently, time spent between versions is wasted needlessly, often on tasks that harm instead of help. With just a little thought and consideration, your dev team can be improving themselves, the product, their outlook, and the entire group without getting into any mischief. Don’t pass up this opportunity for you and your team. Plan for your downtime and keep the momentum moving forward.