Developers and designers don’t usually get along well, and they need to. I first encountered this antipathy at Tech·Ed 2007 in Barcelona, Spain—the first time I’d seen a whole track of talks aimed at designers. The attendees hated this track, panning it so badly that management had to cancel it after the second day. I observed a few of these talks and found their quality decent. I didn’t see any of the usual causes of terrible evaluations, such as demos not working or the speaker being more hungover than usual. Instead, I think that, at that time, the developer community was not willing to hear the fundamental message of the track: that these newfangled Windows Presentation Foundation (WPF) and Silverlight graphical environments required the services of new team members, with different skills but with status equal to the developers’.
Their attitude toward each other hasn’t improved much. My keynote talk at Dev Days in Amsterdam, Netherlands, in 2008 pleased both communities, but then the designers went off into their own world and didn’t rejoin the developers until evening, when the beer started flowing (funny how that works). The same thing happened with my keynote at ReMix in Milan in 2009, except that in Italy they served wine.
Developers and designers hold different worldviews, as do physicians and surgeons. Both pairs make different, incompatible uses of similar environments; both take different, incompatible approaches to similar problems. And both developers and designers are now necessary to any successful client program, as both physicians and surgeons are necessary to any successful medical practice.
The antipathy between developers and designers reminds me of the conflict between cowboys and farmers in “Oklahoma!”—the 1943 Rodgers and Hammerstein stage musical (exclamation point abuse didn’t start with Yahoo!). In the song “The Farmer and the Cowman Should Be Friends,” Aunt Eller has to pull a gun to force the two groups to mingle at a dance (you can see a YouTube clip at www.youtube.com/watch?v=9WUHlqmD7jM for an excellent performance).
I’d like to encourage better cooperation between the developer and designer communities—ideally not requiring coercion with firearms. Perhaps I’d update the lyrics:
Oh, the devs and the designers should be friends,Oh, the devs and the designers should be friends.One just bangs out code all dayThe other wears a cool beretBut that’s no reason why they can’t be friends.
Software folks should stick together,Software folks should all be friends.Some get down with Visual C#Others get high on Expression Blend.
Oh, the devs and the designers should be friends,Oh, the devs and the designers should be friends.One of them grinds his tooth enamelThe other knows how to think in XAMLBut that’s no reason why they can’t be friends.
When I teach WPF or Silverlight at a company, I insist that each class contain both developers and designers. And when I consult with companies on UI projects, I insist that the design team contain both. Usually the designer figures out what would make the user happy and the developer figures out how to implement those ideas efficiently, but a surprising amount of cross-fertilization runs both ways.
For example, at a recent session with a European client, I proposed a classic dialog box for looking up a customer, with a text box for government ID and a calendar control for date of birth, with labels identifying each. The designer said, “Fine, but this operation happens so frequently, how about a search box on the toolbar like Google? The user types in whatever information she has, and we’ll take it from there, like a search engine.” “Yes, I can parse out all the possible inputs,” said the developer, “I have some good reusable classes, it won’t take long.” (It did, but sic semper cum geeks.) “And we can put a prompt string inside the text box, so the user knows what it’s for,” I added. And—zing!—we had a prototype in front of users for testing in just a few days.
That’s what we can accomplish when developers and designers work together, assisted by a designated curmudgeon who keeps the pot stirred. Now start doing it, or I’ll butcher that song again.
David S. Platt teaches Programming .NET at Harvard University Extension School and at companies all over the world. He is the author of 11 programming books, including “Why Software Sucks” (Addison-Wesley Professional, 2006) and “Introducing Microsoft .NET” (Microsoft Press, 2002). Microsoft named him a Software Legend in 2002. He wonders whether he should tape down two of his daughter’s fingers so she learns how to count in octal. You can contact him at rollthunder.com.
More MSDN Magazine Blog entries >
Browse All MSDN Magazines
Subscribe to MSDN Flash newsletter
Receive the MSDN Flash e-mail newsletter every other week, with news and information personalized to your interests and areas of focus.