I hate software

I wanted to post a quick response to John’s link to a new book on IT management. But the site wouldn’t let me because my reaction didn’t fit in the 5000 character box. So I’ll have to do it this way…

Wow, that’s quite a bit less than the Reader’s Digest version. This interesting teaser to a great subject is more like those internal advertisements that bad news programs constantly trot out just before going to commercial, telling you what will be covered at some point in the next hour or two.

I would like to learn more: I’d love a sort of teacher’s-guide summary that covers the main theses (e.g., without the derivation, supporting evidence, or detailed application plan, but at least actually saying something that I could agree or disagree with). What I got out of the teaser at the given link was:

• The more a business knows about IT, the better. IT is essential today.
• When individual IT programmers and teams develop software the right way, their productivity is discontinuously better than when they do things the wrong way.
• When executives harness the previous properly, the entire enterprise experiences a discontinuous increase in productivity.

Sorry, John, but this is meaningless drivel, straight from the book of crap. The first point is all motherhood and apple pie. No one disputes it. But your friend takes this too far in asserting, “How much do top managers really need to know about IT? As much as is reasonably possible to know.” That’s just silly. The author doesn’t declare the scope of his folk wisdom, but from the nature of the publication (CIO magazine), and the author’s own software products, we can infer that we’re talking about software projects within organizations that are not in the business of producing software or any other product directly produced by software (e.g., not someone using design automation or medical/scientific software). The kind of software we’re talking about is the stuff used to run the business, such as software for order fulfillment or accounting. By definition, all the software activity under the CIO bears exactly the same relationship to the company as all the financial work done under the CFO: it is absolutely necessary to the business, but it is not a line-of-business activity. (Technically, it gets accounted for under General and Administrative.) Neither accounting nor IT nor ordering staples are the reason that the company came into being. The CEO and board members had better understand something about accounting (much more than you or I might need to know), but it is silly to suggest that they need to waste their time on the arcana of the tax schedules or charts of accounts. In fact, it is not even the case that the CFO himself needs to know as much as possible about accounting, as for example, no one expects the CFO to know the parts of tax schedules or charts of accounts that do not apply to the business of the company. Similarly, there is a great deal of computer science that is obviously a complete mystery to CIOs (and the people who sell software to them). Is Dr. Kolowa saying that CEO’s had better learn this stuff? (Maybe the better to not be hoodwinked by software vendors?)

In this support role, bad software processes can certainly ruin a company, but they can’t single-handedly make the company succeed at its core business. When a company’s success is driven by either the CFO or the CIO, it ceases to be in the category of companies that we’re talking about. This neither confirms nor refutes the author’s third banality to the effect that shitty software can ruin everyone’s day, productivity-wise. (Window’s anyone?) But understanding software’s support role is crucial to understanding why the productivity of IT staff is completely irrelevant. Since IT cannot make, but only break the enterprise, the only thing that matters in IT is to not fail. Do no worse than what your competition is doing. There are, in fact, software tools and techniques that have repeatedly been tested to produce an order of magnitude productivity improvement to developers and teams, and these are completely unused in business. In order to not fail (or to not appear to be responsible for a failure), IT managers must avoid doing anything radically different, and must avoid any risk of not being able to accomplish their goal with commodity hacks reliably culled from monster or dice. Even if all IT programmers here and in India had deservedly earned righteous PhD’s in computer science, and every business’s competition used the latest techniques, the CIOs would STILL not want to have more productive IT workers, because accomplishing more with less people make the project more dependent on fewer people. If one cowboy of a team of five goes off the reservation, the whole project can be ruined. But if one loser IT programmer out of a team of 100 decides The Matrix is his true religious calling and becomes a game programmer, the effect on the project is miniscule. It is impossible to agree or disagree with an empty statement that poor software techniques result in bad productivity for developers (What techniques? How is productivity being defined?), but the important thing is that the answer is irrelevant: developer productivity doesn’t matter.

Now, I don’t think Dr. Kolowa is an idiot. I might actually agree with what he really wants to say. But the referenced little teaser just isn’t making the case that Better Software Can Save the World, nor does it tell us how.