Dogfooding!
I absolutely love the idea of dogfooding; of having developers use the product their developing on a day-to-day basis. In fact, I can’t see how any developer who’s been through a tough roll-out to users can think otherwise - there are bugs you’ll never find until you start to actually use the product.
That said, some of what Iain says here is easier said that done, especially in a corporate IT department. The developer’s job functions are so far from the users that there’s just no way you’ll be able to use the software with anywhere even remotely approaching the intensity with which daily users use it. I suspect it’s not even possible.
At my company we try to counter this by testing early and often, but even that’s tough - the business leaders and subject-matter experts have their own full-time responsibilities and even getting a modicum of time from them is hard, let alone the kind of time that thorough testing requires. Extreme Programming offer some ideas of how to accomplish this, but those are not much of a solution at a company where there’s not a high priority placed on testing.
My company also tries to work around this by assigning program managers and developers who have functional experience in the areas in question. This, however, has its own risks, as these folks are likely to make mistakes by making incorrect assumptions. This risk becomes ever greater as the work processes change in the functional areas and the IT workers become further and further removed from those processes.
Can this be overcome? I don’t know. But I’d certainy like to find a way for the IT workers to use the software and components they’re building.