My OCLC colleagues at the Developer Network have begun a series of posts that already are beginning to feel like a classic set of posts. The first has tackled the issue of how to communicate your needs to software developers. And although it is written from the perspective of the person asking, I think you will find that the author does a good job of representing the developer’s side of the equation.
But it does more than that. It also sets up questions regarding motives and ways of working. Shelley Hostetler exposes our tendency to jump straight to the assumed “solution” without stepping back a bit and starting with a complete understanding of the problem. This is just human nature. But it isn’t helpful.
In the end, it’s apparent that those who need software to be developed shouldn’t be telling developers what they want. They should engage the developers in a discussion of the problem that needs to be solved, and let the solution emerge from a thorough and shared understanding of the problem. Only then can solutions that will truly solve the problem be found.
About Roy Tennant
Domain Driven Design: Tackling Complexity in the Heart of Software is a wonderful read for software professionals and those who engage them, for understanding the way knowledge needs to be shared in order to get software projects to meet their potential.
“They should engage the developers in a discussion of the problem that needs to be solved, and let the solution emerge from a thorough and shared understanding of the problem.”
Are you suggesting we should talk to our colleagues rather than talk AT them? Noooo! :-)
What’s obvious from Shelley’s post is that working together, for some reason, is not a norm, but an exception, a revelation. Shouldn’t there be an ongoing conversation? Not a discussion of a given problem waiting to be solved, but a flow of information that fosters mutual understanding and pursuit of shared objectives.
Agreed!
I really like what you said about, ” those who need software to be developed shouldn’t be telling developers what they want. They should engage the developers in a discussion of the problem that needs to be solved, and let the solution emerge from a thorough and shared understanding of the problem”. This pretty much sums up the attitude you should have toward any type of communication. It cannot be one sided. It needs to be collaborative. Thanks for sharing.