Eating your own dog food, in Corporate in-house software development

Many contemporarly writers on software development, including successful sofware entrepreneurs, such as Joel Spolsky, Dave Winer and Paul Graham, emphasize the importance of "eating your own dogfood". This phrase is used a lot in contemporary software development, maybe a bit too much, but what it alludes to is using your product. Not just casually, but intensively. The eat-your-own-dogfood theory makes a lot of sense to me, in theory and in terms of the really good software I have ever used, and also the really awful software (PeopleSoft, for instance).

It is easy to see how it can work for consumer software, or tools used by software developers. It is more challenging to make it happen with in-house corporate systems. I mean, how many developers have ever used a claims-payment system, or a reservation booking system, for example? In my experience, large corporations fail terribly in this regard--and oustourcing and offshoring isn't making it any better.

The problem can be attacked. There are several techniques that I have seen to go a long way. One is to bring people with operational experience into IT. Unfortunately, the trend to offshoring it cutting off the opportunities for entry-level transition into IT. I know of Computer Science undergrads, with average credentials, who have left the field, because they could not get their foot in the door, for a development position. So it is even more unlikely that someone will be able to transition from a business operations job to a technical IT job; the best they can hope for is to make it as a Business Analyst.

Another, even less-used alternative is to have IT people spend some time "apprenticing" in functional areas. Although this has a lot to recommend it, this was never popular, and is even less likely to be tried now. So the last alternative is creating a scaled-down version of this situation. Have the IT people spend a significant chunk of time, 1-2 cumulative work weeks, sitting with real users, and learning their processes. Then, continue that partnership, where those real users--at the do-er level, not at the management level--continue to be closely involved in and consulted throughout the software-development process. Whenever I have done this, the payoff has been huge.