Monday, August 20, 2007

Minsky Moments in IT

According to the Wall Street Journal (In Time of Tumult, Obscure Economist Gains Currency) we're having a Minsky moment in the financial markets: "...At its core, the Minsky view was straightforward: When times are good, investors take on risk; the longer times stay good, the more risk they take on, until they've taken on too much...". At some point, we're reminded that the odds are usually stacked against the gambler. Taking on too much risk, whether from buying more house than you can afford (or being coerced into doing so), or investing in high risk hedge funds for the promise of a 30% gain, is a gamble. It's seductive to fall back on natural optimism and believe that house prices and investments will continue to appreciate indefinitely, or that we'll see the drop coming in time to get out with assets in tact. The longer we're rewarded with gains, the more risk we're willing to take - until the bets are called in. A Minsky moment.

Minsky could have been a great IT executive. Of course, he would have helped us avoid the tech bubble of the late 90's, which was yet another example of his economic perspective. But, what if he had worked with the fledgling technology consulting industry during the 90's? Companies like Cambridge Technology Partners came alive during the bubble and changed the way that software was delivered to corporate America. I made the shift from being a 'product developer' to a 'high tech consultant' during these years. Looking back, the shift was largely about taking on more risk in technology delivery. Over the past fifteen years we've embraced so much risk in custom software delivery, it's no surprise we're seeing Minsky moments in corporate IT.

TIAA-CREF is currently in the midst of an IT Minsky moment SunGard, TIAA-CREF IT Slammed by Developers. It's not unusual to see executives and vendors begin to believe their own 'best case scenario', and willingly take on the risk of pushing code to production early (believing that it will just work, or issues can be patched post production). Sometimes you win, sometimes you lose.

I was very fortunate to be indoctrinated in software development discipline in the early 1980's at IBM, where I started my career as a mainframe product developer. At that time, most of the management team in my area were ex-military, and IBM put me through over 560 hours of classroom training in software development process, technology and team development. We had the luxury of 18 or 24 month product delivery cycles, but that time was well used - we had formal software estimation processes and extensive testing. Although we ran into and solved some very interesting problems, we had very little drama and few surprises. It was the complete antithesis of the high tech consulting I did in the 90's. From my perspective, custom software projects in corporate America are run more like hedge funds than military operations these days, so it's no surprise we're having Minsky moments in IT.

No comments: