Don’t Outsource Your Code Development to Strangers

During A casual conversation two years ago, Wal-Mart’s then-CIO told me something about his company’s software development practice that I simply didn’t believe. So I made a couple of calls to confirm it. He wasn’t kidding.

He told me that before Wal-Mart’s people actually write and deploy an app, they make the developer work in the job the app is being written to support. If Wal-Mart devises a new point-of-sale system, for example, software team members have to spend time working the cash registers first. Design empathy for software development is, of course, a wonderful thing. There’s also no argument to be made against the world’s largest retailer’s enviable returns on its enormous IT investments. The numbers speak for themselves.

That said, making your programmers work the registers or inventory the stockrooms represents a level of involvement that’s not taught in most software curricula. I had never heard of or observed a major company making that kind of ongoing commitment.

Listening to the user, yes; being the user, no.

But the Wal-Mart story provokes an obvious but underappreciated aspect of software development methodology. Empathy may or may not lead to high-quality code, but it surely improves the chances that the app will be adopted and implemented by its intended users. CIOs can’t afford to ignore the critical link between software development and application deployment. Yet they often do. They believe that they can actually save money by outsourcing the development of code and divorcing development and deployment. That’s simply not true.

This development/deployment dichotomy is starkly highlighted by the tension between uber-trends like outsourcing and clever cult software methodologies like extreme programming (XP). CIOs who care about cost-effective alignment of development with implementation need to understand and manage that tension. (Originally, I wanted this column to explore the software schism between outsourcing at one extreme and XP at the other solely in the context of development. But I changed my mind precisely because I realized you can’t discuss development without acknowledging its impact on deployment.)

XP’s supporters tend to be zealots who are rather contemptuous of more traditional development methodologies. Yes, there’s a cultish quality to their writings and workshops. But then, XP’s champions embraced their heresies only after painful failures with status quo development practices. They care enormously about implementation.

I like XP because it represents a gutsy and rigorous alternative to the academic development pap I was exposed to in school and the desperate, ad hoc and the why-don’t-you-please-shut-up-and-follow-the-process managerial perversions I observed in the “real world.” XP’s relentless use of cases, its insistence on “pair programming” (the code is designed in teams or pairs), and the aggressively iterative link between coding and testing strike me as extremely productive. There is nothing lazy about XP. Put another way: It’s much harder to “cheat” in the XP methodology than in most other methodologies we could name.

This difficulty in cheating or gaming XP is, I think, one of the main reasons why so many software development organizations resist it. The methodology is almost too demanding and too transparent; there’s little room for developers or—just as important, their clients—to hide. XP is explicitly designed to “stress test” requirements, assumptions and nascent implementations in near real-time. Implementation is thus inherently a part of XP’s development requirements.

But if you’re a CIO, XP represents the opposite of outsourcing. Outsourcing software development effectively means you don’t give a damn about the methodology: You just want to get what you ordered with the right features and functionality at the right price and schedule. By contrast, XP is all about development intimacy in almost the Wal-Mart sense. You care so deeply about the software being created that you drive its development with rigor, intensity and flexibility.

XP’s design approach, thus, could prove far more useful to CIOs and the enterprise less as a guide to craft “better” code and more as a medium to facilitate more effective systems implementation. Why? Because the CIOs I know all seem more frustrated today by implementation issues than by development problems. Implementation often exposes the cracks and flaws in the development methodologies.

This is the single biggest risk posed by outsourcing software development. Organizations discover that, in fact, they really don’t know how to define requirements. They discover they don’t really know how the act of using an application changes their awareness of the features and functionality they really need. The economics of outsourcing preclude the iterative interactions that give developers the knowledge—and empathy—of real user needs as opposed to what users say they need.

This creates the double-barreled problem of software that not only lacks essential functionality but—because of that lack—becomes both more difficult and more expensive to deploy. Outsourcing’s efforts to separate the economics of development from the economics of implementation end up undermining the economics of both.

The reason why programming methodologies such as XP deserve CIOs’ attention, therefore, is not that they make for tighter code developed faster, better, cheaper but because they offer an opportunity to review the connection between how software is written versus how it is actually implemented as an app.

What portions of the company’s applications portfolio should never be outsourced because of deployment costs? Which apps should always be outsourced precisely because the cost/benefit of rollout is completely understood? Is this a conversation that the CIO is prepared to have with the operating committee?

Unfortunately, the lure of “cheaper” development ¿a outsourcing distorts CIOs’ judgment. They save a million dollars on development but pay an extra $500,000 on deployment and waste an extra three months because implementation was a tertiary concern for the programmers. By contrast, I have never heard of an XP initiative that faced any technical implementation issues of note.

Why? Because this methodology embraces implementation as a technical cost of development, not as something that’s the customer’s problem. Methodologies that delegate deployment to the user are sewing the seeds of cost-ineffectiveness.

To be sure, superior requirements, features and functionality are wonderful. But they mean nothing unless they’re implemented well. Just ask Wal-Mart.