At its heart, CPD is three things:
- Political critique
- A problem-solving methodology
- A diffusion strategy
Political critique
I like this part of Collaborative Product Design most of all. Open Source is a developer-centric solution model. Essentially we have created a clear distinction between people with problems and people with solutions. The later are called Developers, the former, Users.
The idea is that “Users don’t know what they want”. Which might also be remapped to “Developers don’t know what Users want” given that so many of these developers have created ‘solutions’ that fail. Somewhere in this model, something is broken.
I believe placing the developer at the centre of the solution design process is the problem. We need to put the right people in the right place. Users should be at the centre of designing solutions for user-facing problem spaces: developers should be at the centre of designing solutions for developer-facing problem spaces.
This means we need to do the following:
- first, change the language. We don’t have Users and Developers. We have People with Problems that need solving. Some have workflow problems that need solving, some have technical problems that need solving.
- People with workflow problems design solutions for these problems
- People with technical problems design solutions for those problems
- don’t mix up 2 & 3
Mixing up 2 & 3 is generally the default ‘Open Source’ model and is cast as:
- Developers solve workflow problems for Users
- Developers solve problems for Developers
Number 2 is fine, number 1 is what gets Open Source in trouble.
Where did this cultural default come from? Well…Open Source is famous for a horrible book known as the Cathedral and the Bazaar which the self-appointed bishop of open source anthropology, Eric Raymond, states as cannon
Every good work of software starts by scratching a developer’s personal itch.
He also states as cannon:
The next best thing to having good ideas is recognising good ideas from your users. Sometimes the latter is better.
This is just wrong. Good software comes from collaboration across specialist domains. If someone has an itch, we talk to them, possibly call in people with similar itches, some specialist medical experts, maybe some researchers if it is a new kind of itch, and whoever else is affected (infected? hoho)… and we learn from each other and collaboratively solve the problem. Raymond’s text, which has had a huge influence on Open Source culture, places the ‘user’ as someone who might have some ideas worth considering but really it’s up to the developer to make that decision. The developer is still, even in the most liberal interpretation of these statements, the arbiter of the design.
We need to get everyone to work together, talk to each other, and work out who is best at solving each part of the problem.
By the way, I am not saying that ‘developers’ have no value when creating solutions for user-facing problems. They do have value in this process. However, it is their ability to empathise and join in a collaboration that is of value in this moment, not an ability to code.
…and…if you wish to explore further gems from the genius of Eric Raymond’ please put aside a quiet weekend to dive into Sex Tips For Geeks….
this is a scratch pad…more to come…
