It is better when the programmer can be a user of the software. But it is not always necessary, and may also be counter productive.<p>One pitfall can be when the programmer is motivated to "improve" the software indiscriminately. Being a user, he's of course in the best place to debug and add the features he uses and wants. But from the corporation and marketting point of view, it's not always the best: the product owner may want to prioritize the work done on the software on other criteria than a user/programmer might have. In those situation it may be better if the programmer is less of a user of the software and just implements the requirements, from a technical point of view.<p>The software development requires knowledge and skills that may be quite different from the knowledge and skills required of the user of a program, and when the application domain is quite exotic (from the point of view of the programmer), it may be understood that while the programmer can write the code implementing the specifications, he may not have the ability to run (effectively) the program. Again, it may be unrealistic to require extensive domain knowledge from everybody from the team. This is something that the product owner and functional analyst provide. The programmers will provide the computer science and engineering knowledge.<p>As a program developer, I don't know anything about farming, but the most general notion. I made a bean seed germinate as a pupil, and a dug a garden plot once, and that's about all I know about this business. But I know about databases, client/server applications, and user interface development. As long as you can give me some specifications for a "marketplace system for farmers", I can write the software.<p>Of course, I'd agree that at least the person interested should try out the software if it's possible. But when I do that, I realize that:<p>0- I mostly use it blindly, without understanding much of what's happening,<p>1- I can only provide suggestions about superficial elements,<p>2- moreover, my suggestions are strongly influenced by my biases, as a programmer (eg. I tend to have a preference for textual CLI, emacs-like user interfaces and programmable systems).<p>You definitely want a real user, a domain expert, to use your software, rather than programmers.<p>Of course, unless the software is a developer tool (but even then, some prefer IDE, some prefer unix environments, some prefer emacs).