Tim sparked an interesting discussion around the office last week when he circulated a post from Derek Powazek’s blog called “Programmers are tiny gods.” It offers a provocative analogy for the designer/programmer relationship:
Programmers are the Gods of their tiny worlds. They create something out of nothing. In their command-line universe, they say when it’s sunny and when it rains. And the tiny universe complies … So if you’re working with a programmer, you have to treat him or her like a God. You have to pray. You cannot issue edicts. You have to come on bended knee. “Here’s the problem I have. I need a solution. Please help.”
It’s from a series called “Things I learned the Hard Way.”
Tim McCoy: It’s a nice insight into the psyche of many development organizations. This is meshing with a sentiment I’ve heard a lot lately: “Don’t tell me what to build. Tell me what you need built.” It’s a subtle distinction that replaces the feeling of micromanagement with one of empowerment.
David Fore: Right. But this sentiment begs a fundamental question. When a programmer objects to being told what to build, how can biz decision makers ensure they aren’t wandering into the weeds, building a taco stand rather than a playground, let’s say. In other words, taken to the extreme, this sentiment means the inmates shall run the asylum. Alan, do you want to rewrite your book?
Tim McCoy: For me, it doesn’t challenge the notion that design has the responsibility of describing the product and development the responsibility of creating it.
I recently had a conversation with a developer who said “I want the definition of behavior as soon as possible, and I want to delay the definition of implementation for as long as possible.”
The issue is that being told what to build is a command, not a dialogue. Being told instead what needs building is an invitation to collaborate. That acknowledges programmers as professionals with expertise designers don’t generally have. (In turn, it assumes programmers acknowledge designers as professionals with expertise they don’t generally have.)
Programmers then have the flexibility to assess what building that thing would entail, express concerns over feasibility, timeline, motive, etc., and offer alternatives or adjustments that impact their ability to be successful.
So it’s about removing the friction to object to in the first place. Derek is being sensational with the bended knee bit, but the sentiment is sound. The payoff of his post is this:
The good news is, programmers want their work to be used, and the good ones know that the design matters. So programmers and designers actually have the same goal: getting the stuff used. If each can honor the talents of the other, great things can happen.
It’s about approaching developers as co-conspirators in producing great work: designers know what needs to happen and developers know how it can.
Lane Halley: I think you’re right on when you say “being told what needs building is an invitation to collaborate” and that designers and developers can be “co-conspirators in producing great work.” However, there are some nuances to the situation.
I think that when SW developers are removed from business decisions about what they are building (e.g. work for a salary, or code for hire), there’s a sense of relief when someone, anyone, steps up and takes ownership for the “what” of the product. However, at many companies, this responsibility for the “what” isn’t totally owned by Designers, it’s a space shared with Business Analysts, Product Managers and other folks.
I’ve also seen small teams of collaborative generalists at Web 2.0 companies and startups who have a different attitude. Those folks don’t think of “design” as a separate role, it’s more like an activity, or a skill set that has to exist within the team, somewhere. SW developers who work in this environment feel a greater sense of ownership of the product, and expect to be involved in defining the “what” too.
Tim McCoy: That’s a great point. The dynamic in a small team, startup, or indie development shop is usually much different from the situation Derek describes. I think it’s a side effect of the traditionally down-stream role developers have in larger established organizations that leads to this outlook, and why it’s design’s responsibility to say “hey, I’m not coming down here to drop a spec on your desk, I want to talk about how we can solve this thing.”