During A casual conversation two years ago, Wal-Mart\u2019s then-CIO told me something about his company\u2019s software development practice that I simply didn\u2019t believe. So I made a couple of calls to confirm it. He wasn\u2019t kidding.He told me that before Wal-Mart\u2019s 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\u2019s also no argument to be made against the world\u2019s largest retailer\u2019s 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\u2019s 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\u2019t 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\u2019s 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\u2019t discuss development without acknowledging its impact on deployment.)XP\u2019s supporters tend to be zealots who are rather contemptuous of more traditional development methodologies. Yes, there\u2019s a cultish quality to their writings and workshops. But then, XP\u2019s 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\u2019t-you-please-shut-up-and-follow-the-process managerial perversions I observed in the "real world." XP\u2019s 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\u2019s 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\u2019s little room for developers or\u2014just as important, their clients\u2014to 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\u2019s development requirements.But if you\u2019re a CIO, XP represents the opposite of outsourcing. Outsourcing software development effectively means you don\u2019t 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\u2019s 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\u2019t know how to define requirements. They discover they don\u2019t 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\u2014and empathy\u2014of 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\u2014because of that lack\u2014becomes both more difficult and more expensive to deploy. Outsourcing\u2019s 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\u2019 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\u2019s 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 \u00bfa outsourcing distorts CIOs\u2019 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\u2019s the customer\u2019s 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\u2019re implemented well. Just ask Wal-Mart.