Offering regional and national programs, CIO (and CSO) events bring together some of the most respected names and thought leaders in information technology and security. Presented by CIOs and other senior level executives, these invitation-only programs offer timely topics and strong networking. Learn More »
Public Council Teleconference: Application Rationalization — Hidden Costs and Smart Decisions
November 17 at 11:00 am US/Eastern (GMT-5)
Join Honorio Padrón, of The Hackett Group, who will share the drivers for companies to tackle application rationalization and the results of research that define the hidden cost of complexity. Additionally, we will discuss key decision milestones—to start or not, holding the course steady and fulfilling expectations.
Virtual Desktop Cost-Benefit Analysis — Michael Jacobs, Catlin Group
The analysis contained in this presentation measures the cost of everything from the machines and licenses to the infrastructure for virtual vs. traditional desktop environments.
Honor your best senior team members - Apply for the CIO Ones to Watch Award
Get well-earned public recognition for your top up-and-coming team members, your IT organization and your enterprise. Award winners will be announced, publicized and feted in May 2010, great timing to help attract new IT recruits to your company.
Learn more about the CIO Executive Council »September 15, 2003 — 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.