Robert's blog
Robert Važan

How to sabotage software business

Improving programmer productivity by exposing the most powerful ways to kill it. Do the opposite and save yourself manyears of wasted time.

I originally intended to write about programmer productivity and the little we know about it. But then I realized that productivity is not about the things we do right. It's more like answering the question "what else could we do wrong?" If I were a secret agent intending to sabotage software business without anyone suspecting, here's how I would go about it.

The first thing I would do is to institute coding guidelines. Not just any guidelines. The intent is to increase verbosity and number of lines of the code as much as possible. Extensive use of curly braces, everything on new line, 80-column wrapping, prefixing implicit "this.", expanding "var" into actual type, etc. Patterns provide powerful expansion factors while maintaining fairly broad applicability.

Code templates, snippets, and especially ReSharper provide automated mechanism to perform this attack. ReSharper is my favorite nuclear weapon of mass destruction. It takes split second to permanently obfuscate whole source file. The ease of doing it renders all manual countermeasures ineffective. Nevertheless, bonus points can be gained if I can make everyone implement the coding guidelines by hand.

This attack is scientifically proven to be effective. Research confirms that larger monitors and more monitors increase productivity. Verbose code has the opposite effect, because it makes you see as much code as if you had 4" monitor. Research has shown that fast reading improves comprehension. Verbose, sparsely formatted, and redundant code slows down reading, thus inhibiting comprehension.

Combined effect of these mechanisms results in no less than 10x reduction of programmer performance. If you add to it the fact that bug density is roughly the same everywhere (human nature), 10x larger code base will have 10x more bugs in it. As the reduced programmer performance now makes every bug 10x more expensive, there's a total of 100x increase in debugging time. Since debugging (in one form or another) dominates software development, the overall productivity will drop by factor of 100. You can see why this is my primary vector of attack.

My other favorite weapon is waterfall process. Everyone in IT has been recently conditioned to dismiss waterfall, but introduction of agile methods has been limited to initial stages of development process. Requirements, coding, and automated tests are subject of tight feedback loops resulting in potentially deliverable product. That word potentially is very important. Nobody is actually using the product, so there's no end-to-end feedback loop. Nobody knows whether the features will have desired effects or whether they will be used at all. Encouraging this kind of self-absorbed shelf production is quite reliable way to kill software business. In the rare cases where lean startup model is used, it is often possible to sneak waterfall in through partial validation and weakened metrics.

One particularly hideous weapon is air, or lack of it. This is an extremely unethical weapon that should have been long banned by UN. The way this works is that architects design beautiful offices with density of one person per 50 square meters and managers then turn them into crowded open plan stables with one person per 4 square meters. The result is carbon dioxide levels rising from outside levels of 400ppm to hazardous indoor levels of 3000ppm even with ventilation maxed out. At these levels, cognitive function is measurably impaired and developers are converted into mindless zombies dabbling aimlessly at their keyboards. Rumors say that long-term exposure causes permanent brain damage, which, if true, makes this weapon particularly useful when targeting whole city-wide IT networks.

While I tried to be original in my selection of sabotage techniques, there's a whole array of tried-and-true old school methods. Single authority-craving boss is enough to drive out all talent, leaving the company with incompetent losers who have nowhere to run. Ditto for "clever" compensation strategy or hiring "professional" looking types instead of "unnecessary" talent. What about making all those loafers report their work on hourly basis? Make them wait for approval before doing any work and never approve any refactoring. And stick to 20 years old development tools to cut upgrade costs. Corporate admin is manager's right hand when it comes to blocking developers' access to the SVN server "for security reasons," requiring patches to be ferried on USB sticks.

And yeah, all of these examples are real. I've witnessed each one in at least one company. The list is far from exhaustive. I have been myself guilty of doing several things wrong, which I have tried to correct, but there's an endless array of other things I might be doing wrong. I never know until the light bulb moment comes. There are tons of fast-cooking experts promoting their books and seminars who pretend to know what's killing you. At the very least, you are going to ask them for evidence, not plausible arguments, that proves their stuff works. But more importantly, you are going to check relevance for your business, because programmer productivity is a lot like software performance: there's bound to be some stupid performance bug that eats 99% of all resources.

Did you run your business under profiler recently?