Making IT Work – Is Offshoring Coding Yesterday’s Fad?

Over brunch in a cheap Brooklyn restaurant, a longtime MIT friend proudly demonstrated his latest startup’s software. The idea is clever, and its beta implementation is sweet. I liked it; usually the stuff I see turns my stomach. So I’m pleased that Hans Peter Brondmo’s Web-based “personal information organizer” has technical chops and global business potential.

Then again, I usually pay close attention to Brondmo’s digital designs. He’s not an uber-geek who’d rather write code than chat up prospects. A reasonably successful entrepreneur, he’s a get-it-done pragmatist who won’t coddle programming prima donnas. He wants to hit the market cheap, fast and hard with products that aren’t hard to upgrade or maintain.

So when Brondmo told me his software, called Plum, was the first time he’d done serious coding in over a decade, I was taken aback. “I couldn’t believe how much things have changed,” he confided. “When my development teams wrote code 10 years ago, it took us three days to find and kill a bug. Today, it takes us only three hours.”

What’s more, he continued, whenever his (geographically distributed) development team runs into trouble, they can usually instant message their way into a just-in-time partnership that simultaneously solves the problem while alerting everyone to potential conflicts. “We do better real-time collaborative development and review now remotely then we did back at MIT when we were all in the same building,” he notes.

Brondmo’s favorite development discovery occurred when he was stuck for a few lines of code. He realized that by Googling he could see if anyone anywhere had posted something he could use. He and his team found quite a few virtual solutions this way. “But what about context?” I asked. After all, not everyone documents their C++ in English. He dismissively waved his hand: “Code is code. I found something that looked like what I needed in the middle of what looked like a bunch of Chinese. You paste it in and see what happens. It worked.”

The ultimate result? He’s never done a startup where the software development has been better, faster or cheaper. “In the past, I’ve had to raise lots of money to support the burn rate and the licenses necessary to develop real software over a couple of years; the costs are huge,” he said. “You had to deal with the venture capitalists. They had the money.

“Development cost is still significant, but it’s now focused on value creation, not infrastructure development,” he added. “Open source and the availability of tools reduce our infrastructure cost. We don’t have to pay for expensive software licenses and engineers to implement ’commodity’ functions. So more money can be focused on innovation, not plumbing. We do more features faster. Development isn’t really an obstacle.”

Even allowing for hyperbole—perhaps Brondmo’s “three days to three hours” time compression is really closer to “two days to five hours,” we’re still describing at least a fourfold productivity leap. That’s impressive. Marry that to the evolving array of development-oriented communication, collaboration and search tools spilling into the global digi-sphere, and the serious CIO might want to delay that Bangalore RFP. The new economics of software development may have rendered India and China yesterday’s fad.

Plum’s provenance may not be typical, but there’s nothing extraordinary about it either. A savvy entrepreneur is exploiting technical innovation to cost-effectively generate technical innovation. The stuff works. This is where savvy CIOs need to sit up and take notice. The implementation implications are enormous.

I’m the last person to suggest that busy CIOs should immerse—or, God forbid, reimmerse—themselves in code. But any CIO preaching the gospel of productivity better know if his organization’s methodologies discourage—or invite—healthy experimentation with these nascent development platforms. A CIO should know if he can now consistently get a year’s worth of software development in 90 days. A CIO should know if 75 percent of a project portfolio can go to value-added features instead of infrastructure maintenance. This matters.

Transforming the economics of software development completely transforms the economic rationales for outsourcing. Reducing both the cost and time-to-market of new features and functionality completely transforms a company’s economics of innovation. Ideally, CIOs should “own” these transformations. Do you?

Three clear implementation transformation scenarios emerge. The first scenario is the easiest and most obvious: These development economics create a new generation of Salesforce.coms and other ASPs that offer suites of mix-and-match business processes for enterprise consumption. For example, while Brondmo has given little thought to Plum as an enterprise “knowledge management” platform, it could easily be adapted to become one. With a little goosing, it could become an “account management” app too. More choice, less money.

Toward Value-Added Innovation

Scenario two has IT recommit to enterprise software development. These tools and technologies turn the internal economic equations for IT investment away from outsourcing and toward value-added innovation. IT becomes a better, faster and cheaper innovation partner for both key business units and core enterprise processes. ERP systems are goosed and spruced by customized Web apps instead of extended by packaged procurements like Siebel or PeopleSoft.

The third scenario has IT bypassed by ambitious business unit leaders who can’t—or won’t—wait for the CIO to get his act together. So they pursue scenario one and scenario two-type behaviors independent of whomever the CIO is and whatever the CIO wants. Like the rise of the software spreadsheets more than 20 years ago, the rise of Plum-like digital platforms and processes proceeds without the need for central approval.

Scenario-three CIOs will have a hard choice: Either be seen as enablers and champions of creative enterprise interoperability or get used to losing a lot of fights.

My personal belief is that the variation IT’s been witnessing since 2000 will accelerate: The “IT doesn’t matter” crowd will continue to manage and invest in IT as a commodity, while the “strategic IT” companies will be exploiting these new development economics for better and faster differentiation, segmentation and innovation. These emerging economics will further fragment the CIO community. The rich will get richer; the smart smarter; and the not-so-rich and not-so-smart will find themselves struggling to remain “fast-followers.”

When you look at the core economic dynamics driving software development and business competition, it seems painfully clear: There has never been a better time to be a smart CIO at an organization that wants to win.