After Scrum

I like to play a game sometimes, it goes like this: Take a current hot and screwed-up software methodology and try to project what its replacement is going to be.

For instance, the shiny bits of Scrum are starting to wear off like the cheap paint from a fake idol, but there’s still time to dust off the crystal ball and toss some coins in the air. And based on what I’ve seen killed dead on the altar of Agile (and it ain’t been pretty) here’s what I think will happen next.

Remember all those burndown and velocity tracking applications The Powers That Be bought for Scrum? They’re not going to go to waste: Get ready for micrometrics.  Practically everything a team does will be measured, analyzed and acted upon by project managers. Going over checkins and having a thousand eyes on things is going to be horse and buggy stuff. We’re going to see utter exposure of everything that goes into the head and out of the fingers of developers, every cotton pickin’ thing will be timestamped, correlated to features, and graphed during reviews (which will happen in real-time).

In the new world of micrometrical software, no sparrow will fall without a burrowcrat getting on someone’s case about it.

How long did it take you to fix that bug this morning? What source code did you call up? How many steps did you take in the debugger, and what did you look at? What unit tests did you actually write and run?  Did Joe, the dev next to you, fix a similar bug in less time, with better quality? How much email went back and forth about the issue? Do you often mis-spell keywords? Do you hit backspace a lot, or change your mind about function names or parameters? Does it appear that you know exactly what you’re doing?

What percentage of your keystrokes and mouse clicks and minutes of your day can be mapped to a product feature?

My guess is there are shops already doing this, where fractal attention to detail has become a recursive ass-covering game, and everyone has forgotten why they started writing software for a living.

Has it been that long? When was the last time you enjoyed making a hunk of code work?

Please, have fun every day.

Bags of bugs

My new favorite way to get rid of spiders in our house (they are welcome anywhere outside, but not in the house proper, and not in the garage) is to whooshify them with the shop vac. This is safe and efficient because with my superior engineering skills and some duct tape I’ve added an extension wand about yayyyy long to the existing extension wand’s extension. With my corrected vision I can spot a black widow spider from 20 feet away, and now that I have developed the capacity to whooshify them from a distance greater than their pouncing radius, life is better.

Except . . . I have this new irrational fear of vacuum cleaners.  Umgekehtervacuumenspiderenwhooshenobia is the phobia that a vacuum cleaner will experience a sudden polarity reversal and spray several years worth of very much alive and probably quite vexed poisonous spiders around the room. Hilarity ensues.

– – – –

In the software industry, the practice which is most like saving up poisonous spiders in a big bag for a later, less convenient time is the creative denial we call Bug Triage. It’s got other names, such as Managing Customer Expectations, Meeting the Quality Bar, or Getting the Fucking Project Shipped, but it all comes down to one thing: Stuffing defects into a bag (a “backlog” or similar purgatory) and getting the stupid collection of bits to paying customers without the bag or the customers suffering a catastrophic reversal of fortune.

The dirty truth of software is: It’s buggy. From the crappy hacks that run your toasters and flatscreen TVs to the expensive professional-grade stuff that keeps nuclear reactors from running amok and spewing out gigantic radioactive spiders, if something’s got a couple kilobytes of code in it, chances are it’s also got some pretty tasty bugs. We’re just not good enough as a species to put together a gadget with a few thousand parts without risking something blowing up.

Most of the time we don’t see them. Or if we do, they are minor annoyances — who cares if your smart toothbrush crashes?  However, occasionally there is a howler.  Some ship team’s pure, distilled denial lets something through that should have been an easily identifiable must-fix bug.

The truly pernicious bugs are the ones that don’t actually look like bugs. You think you’re happily slinging code around, and one day you wake up and realize that you’ve filed sixteen TFS reports in the last day, all about the same simple problem. You think harder and discover that other groups — people that you’ve never even heard of — have been holding daily war meetings about this bug. Six PMs and three managers are asking about status. (The actual issue? It’s a cosmetic thing affecting the color of a button in an error message, a one-character fix where a less-than should have been a greater-than).

The system has eaten itself, and you’re mired in a toxic, icky pool of process. You’ve become a living part of the bug. Your job? To keep the bug handling system alive by making more bugs. The bug-handling ecosystem has evolved to florish on the bug-making process, and if there aren’t enough bugs, it will make up some of its own.

My advice is: If it gets this bad, either get promoted so you can start lobbing hand-grenades into the machinery, or do something else.  Trust me, the system won’t miss you.