Don't Outsource Your Code Development to Strangers

CIO — 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.

Continue Reading