Developers Are The Customer

I expect that there are many situations where the developers of a piece of software are also playing the role of their own customer.

This page is about such situations. I believe there is also an ExtremeProgrammingChallenge that touches on this, but I can't seem to find it.

KentBeck wrote: You know, you just know, that the customer is going to want XYZ tomorrow, they are just too blind to see it. And if they want XYZ, then you'll have a lot less work to do tomorrow if you just add this design feature or that today. I teach my team to take a deep breath and move on, because more often than not XYZ doesn't happen, or if it does happen, fixing the design is easier than I can imagine today (I'm smarter), and anyway it is bad practice for programmers to second-guess customers. It is the first step on a slippery slope to the programmers being in charge, which we know doesn't work.

I'm working in a team that is developing what is basically a visual programming language and accompanying tools. The people who should be going to use these tools are in another department of the company. Using the new language is going to solve a number of the problems they have with their current language and tools, too. But they didn't ask for it.

So we're currently developing this language and toolset, and try to get people from the other department involved as 'the customer'. Problem is, we probably won't get anybody from that department to be our team's customer: they have more than enough work already.

This means that our team is currently playing two roles at the same time: defining the language and tools' requirements, and implementing them. And I can see no clear way to separate the two. Questions: Is such a separation necessary? If so, how should we go about it?

--MarnixKlooster

It's necessary. What sort of answer are you looking for? That you should get baseball caps in two sets of colours, and switch between them when you switch roles? I should think just being aware of the issue, and knowing that you have to ask every question twice (once from a technical perspective, and once from a customer's), would be a good start. -- DaveHarris

Marnix, you wrote: "They didn't ask for it." Let me be somewhat provocative: Why do you do it then? If they didn't ask for a tool plus they don't have the time to discuss requirements (user stories) with you, what makes you think they'll take the time to learn to use your tool? --HaskoHeinecke

This is a high-risk project. How do you know you are building the right thing if you can't get your customers to talk to you? You might succeed if you have done the job of your customers in the past, or if you are planning to compete with them for awhile and build the same kind of applications that they are building. But if you don't know for sure what they need and can't get them to talk to you then you are doomed to fail.

A better example of developers being the customers is when you are building a programming tool that you want to use. This often works well, as we can see in Unix. But if you are going to build a tool for someone else, you need their help. --RalphJohnson

I spend most of my time writing software development tools that I too will be using, things like: debuggers, testing tools, tracking tools, version control tools, build tools, and even libraries and frameworks intended to be part of a reusable codebase. Im definitely the customer most of the time, but rarely the only customer. I like being my own customer like this immensely! It doesn't always work out that way, but for me it frequently does. You still want as much input from as many other users as possible, but its nice to be an expert member of the problem domain rather than dealing with a problem domain about which you initially know nothing at all. There is some related discussion about the benefits of this on the DogFood page (regarding SystemDogFooding? and DeveloperDogFooding?) --BradAppleton