Monthly Archives: January 2010

Why IT Matters More Than Ever

In 2003, Harvard Business Review published Nick Carr’s seminal essay, “IT Doesn’t Matter.” I remember that month well. The previous years of the PC boom, followed by the dotcom boom, had seen a tidal wave of money spent on technology. Much money was wasted on heavy investment in systems that either sat unused on a shelf, or ultimately were scrapped. To top it all off, the big “emergency” of the time, the millennium bug, turned out not to be as bad as everyone had feared. The time was rife for someone to declare the strategic irrelevancy of technology, and Mr. Carr stepped in and made the case. Because many executives desperately wanted to reduce technology spending at the time (in the aftermath of all that gluttony), reading Carr’s article was like receiving manna from heaven.

As a technology practitioner myself, however, it should surprise no one that I believe Mr. Carr to be wrong. Regardless of any biases I may have, the reality is that his argument contains several holes that have become ever more glaring with the passage of time. My intent with this article is to shine a light on what’s wrong with the “IT doesn’t matter” argument. I’ll even go further: I’d like to demonstrate why, now more than ever, investing—not just in technology, but in the intersection of technology and people—is the most important action that a company or organization can take.

The Company That Couldn’t Run a Second Shift

In my years as a technology consultant, I’ve certainly seen what happens when you don’t invest in technology. One client I vividly remember—we’ll call it Company X—had quite a conundrum. An amalgamation of nine different manufacturing organizations built up over time, Company X spent very conservatively on technology. When making an acquisition, Company X would do as little as possible on integration; for example, only enough to get the accounting systems and the order-entry systems sending orders to a central mainframe.

Over time, this management behavior at Company X resulted in a “Rube Goldberg” system requiring the work of hordes of COBOL programmers just to keep running. Overnight order processing required more than 200 manual steps. The maintenance cost of this Frankenstein’s monster of a codebase included at least 40 full-time COBOL programmers, a couple of dozen system operators, and who knows how much management hierarchy on top of all that. Company X was spending an estimated $15 million annually just to keep the system at its current level of functionality.

Unfortunately, that $15 million wasn’t even the most significant problem. When demand increased, Company X decided to run a second shift. The issue was that the system literally could not process orders in greater than about a 12-hour window. Moving to a 16-hour window, and eventually to a round-the-clock business, would require either radical changes to the old system or building an entirely new system—and it would have to match the quirks of the old system, in order to maintain compatibility with the nine other satellite systems!

Business analysts estimated that adding a second shift would increase gross margin in this low-margin business by around 3%, while increasing top-line revenue by over 20%. Moving to round-the-clock processing was also a precursor to being able to sell into new global markets, which would have increased top-line revenue even further.

Sadly, none of these happy improvements could come to pass for Company X.

The problems at this company were many, of which technology was merely one aspect. The deeper issue was that the operators and programmers who understood that mess of a codebase had a vested interest in keeping the current technology set running. But even if all those people were replaced, technical debt in Company X had built up over a long period of time, to the point that the company would need to invest around 2–3 times its annual profit in order to get out from under the load of technical debt.

In this culture of hubris, fear, and inertia, any new technology initiative to pay off the technical debt would almost certainly be killed. It was literally a recipe for company bankruptcy. When competitors are blowing you out of the water with 3% higher margins and 20% higher top-line revenue, taking that increased profitability and investing it into further productivity-enhancing technologies, it’s hard to see why “IT doesn’t matter.” If you’re a CEO in a company that can’t compete because of technical debt, you almost certainly will understand just how much IT does matter.

The rest of this article is available at Pearson Education’s InformIT website here.

The Root Causes of Technical Debt

When we spend 80% of a development budget just keeping software that we already presumably “own” working and current, we know that technical debt is extracting a terrible toll on our budget. When making a simple program change requires effort measured in weeks rather than days, something has gone horribly wrong. In many circles, the term custom software has essentially become synonymous with “blank check” and “will drain your budget for a long, long time.”

Do you champion change to help reduce such technical debt? You may eventually be rewarded for your foresight—but meanwhile the risks of championing change are very high. If you want to write maintainable software, a multitude of barriers stand in your way. When you admit that you can’t state with absolute certainty what will be delivered, do other people paint that disclosure as an admission that your team lacks discipline? Do your developers who have not yet tried pair programming or test-driven development reject those techniques without ever really attempting them—just because they’re new and initially uncomfortable?

Previous articles in this series have explored the problem of technical debt, the ultimate costs of this problem, and how methods that work only at surface levels stifle the possibility of changing to something better. In this article, we’ll consider why these problems affect our technology organizations in the first place—how technical risk factors into the technical debt that plagues the software industry.

Taking Down the Hubricists

I defined the term Hubricist in my article “Scrummerfall: World’s Worst Software Development Methodology.” The Hubricist attempts to impress those above him by replacing real data about the real velocity of the project with hubris. What the Hubricist lacks in substance, he makes up in bravado: “Yes, we will hit the deadline. Yes, you will get all the features!” When neither happens, developers are blamed for not working Sundays in addition to Saturdays, and careers are derailed in the aftermath.

Why is the Hubricist so opposed to change? For a moment, try to think from his point of view. Somebody (perhaps it’s you) comes along and trots out this methodology that promises transparency, particularly with regard to quality and technical debt. Is this methodology good for you, Mr. or Ms. Hubricist? Where would you fit into a regime that values results over bravado? Results-oriented management might not allow you to blame other people when things go wrong. If customers see that developers are making progress on a daily basis—working hard, but not at the unrealistic rate of progress you promised in order to sell the project, where does that leave you? Exposed, having made a lot of promises that can’t be kept.

With this kind of mindset, it should be no surprise that Hubricists try to block adoption of Agile methodology, or any other system that adds transparency. Remember the scene in The Wizard of Oz where the curtain draws back to expose the little man behind the booming voice? When the Hubricist perceives the potential for exposure, he plays the FUD card: fear, uncertainty, and doubt. He walks around claiming that Agile isn’t disciplined, that it’s about developers who don’t want to write documentation, that it’s advocated by teams that don’t want to be held accountable for results.

What can you do to counter the Hubricist’s claims?

  • Point out that Agile teams actually tend to produce far more useful documentation than other methodologies can. These are real showcases that demonstrate working software, versus mere status reports with vague claims of xx% complete, based on nothing but self-reported guesses.
  • Note that accountability for results must be based on a solid track record of delivery. Is a high percentage of the development budget spent on software maintenance costs? Past results don’t allow you to claim “accountability” for the future unless you have changed those statistics.
  • Show a real Agile team. Show stakeholders the daily artifacts of story cards moving from backlog to completion. An Agile team room is an active place, where collaboration tends to be visible and signs of progress are frequent. Compare this to a typical cube farm in a waterfall project.

The rest of this article can be read here.

Follow

Get every new post delivered to your Inbox.

Join 29 other followers