I've always discouraged ivory tower development-- teams where developers are cloistered away for years in their high towers, working on technical software wizardry. These developers have no idea how users will respond to their software they're creating. They probably couldn't even tell you the last time they met a user! In the absence of any other compelling evidence, developers assume everyone else is a developer. I hope I don't have to tell you how dangerous that is.

In my experience, the more isolated the developers, the worse the resulting end product. It doesn't help that most teams have a layer of business analysts who feel it is their job it to shield developers from users, and vice-versa. It's dangerous to create an environment where developers have no idea who the users are:

I gave a presentation to an all-hands meeting for a division of Sun, and I asked the group to raise their hands if they'd met a live customer in the last 30 days. Couple of hands went up. "The last 90 days?" One more. "The last year?" Another two. There were over 100 people in that room directly responsible for deliverables that went straight to users... in this case, Java training courses.

This flies in the face of some software development models that believe if you've done your specifications right, there should be no need for the "workers" (programmers, writers, etc.) to ever come in contact with real users. That's nonsense. What users are able to articulate before they have something is rarely a perfect match for what they say after they've actually experienced it. It's just like market research: people can't tell you in advance exactly how they'll react to something. They just have to try it. And you have to be there to watch. And listen. And learn. And then take what you learned and go back and refine. Which is why the old waterfall model is pretty much the worst thing to ever happen to users.

Make the effort to expose your developers to users throughout your project lifecycle. Bring one developer from your team to every meeting with users. Involve developers in your usability and acceptance testing. Nothing removes a developer's Homo Logicus blinders faster than seeing a typical user struggle with basic computer applications. Developers simply cannot comprehend that the average user doesn't even know what ALT+TAB does, much less how to use it. They have to see it to believe it.

Most projects I work on these days are internal. I define internal projects as projects where users are forced to use your application whether they want to or not. So much for free will. And, too many times, so much for concerns about software quality. As Joel says: sadly, lots of internal software sucks pretty badly. It's true. And it is sad. This is another form of Ivory Tower Development: what incentive do I have to care about the concerns of our "customer" when their job requires them to use my application?

I'd much rather work on projects with paying customers, or at least treat internal projects as if users were paying real money for your product. That engenders what Eric Sink calls a mutual trust relationship:

When people buy software from you, they expect a lot, both now and in the future:

• They trust that your product will work on their machines.
• They trust that you will help them if they have problems.
• They trust that you will continue to improve the product.
• They trust that you will provide them with a reasonable and fairly priced way of getting those improved versions.
• They trust that you are not going out of business anytime soon.

So, by asking users to pay for your software, you are asking them to trust you. But how much do you trust them?

The vendor/user relationship is like a relationship between two people. And relationships don't work without mutual trust. If one side expects trust but is unwilling to give it, the relationship will fail. So often I see software entrepreneurs who don't want to trust their users at all. It is true that trusting someone makes us vulnerable. Just as in a human relationship, trust is a risk. We might get hurt. But without that trust, the relationship isn't going to work at all.

I've actually begun to think that internal departments [of large companies] should act as micro-ISVs, charging their users for the applications they build, and actively marketing and selling them to other groups inside the organization. I think that would lead to a leaner, meaner, and ultimately more healthy organization. Plus, the boondoggle projects so common at large companies would die naturally due to lack of demand.