Douglas Bowman has posted a piece about the role of the designer in collaborating with their clients. This same philosophy is as applicable in software design as it is web development and branding.

I’ve recently moved from being a hobby programmer to a hobby programmer who sometimes gets money. Which sort of makes me a ‘professional software developer.’

“Development”

To me, the term software development reflects a distinctly corporate attitude toward the creation of software:

• The developers’ natural tendency is to Mess Up.
• We must meticulously document every facet of every feature in order to Prevent This.
• We will Design It. They will Implement It.
• We are not interested in a work-in-progress, we will see it when it’s Done.

It’s not hard to see how this pattern of thought may have developed: Hackers speak in programming concepts. How intimidating it must be to hear expressions like ‘referencial integrity’ thrown around the design table!

It should be our job to carefully explain these things as necessary, rather than jumping to conclusions and leaving the client in the dark. After all, when decisions need to be made, how useful is a customer who’s full of buzz-talk but has no basis for understanding the underpinnings of their new software?

The other part of this is that they need to show us the flow of their business. Not what they percieve the flow of the application should be, that can come later, but the actual product process. The more time is spent showing your programmers the big-picture view of what’s going in the company, the better their understanding will be. The more they see where their new application fits into the existing framework, the more ‘little things’ they’ll be able to add to make it that much better.

With all this teaching going on, there’s an upfront time commitment to be made. But it’s a worthwhile one. And it’s time that would have been spent writing a spec, anyways, so instead of just saying what needs to be done, why not persuade each other of what needs doing?

The Risk

What’s the problem here? The problem is that you can end up with a pig-headed hacker who thinks he knows what you need and won’t bother to learn even if you try to persuade.

Fire him.

And when you’re hiring to replace him, look for someone who’s 50% teachable and 50% able-to-teach.

Pick a project from their portfolio and ask them to talk about it. You’re looking for an explanation of the lowest-level and the highest-level. What makes this thing tick under the hood? And what role did it play in the greater scope of the organization? After data left your program, where did it go?

The amount they’ll share about that project is indicative of what they’ll bother to learn about yours… and what they’ll teach you about it.

Mike

← Earlier Later → Posted at 10:34 pm to Business, Soapbox.