Should Designers Code?

No, Part One.

There’s a recurring debate in our industry over whether or not designers should write code. Some developer will pose the question on Twitter, then pundits, practitioners, and gurus answer it. Everyone has an opinion, tempers flare, then people agree to disagree, and the discussion subsides. But a few weeks later someone else poses the same question and social media blossoms with yet another instant replay of the futile, never-ceasing argument.

The debate follows a characteristic pattern: people discussing a question of personal taste as though it were a universal truth. It’s like someone asserting that because they don’t personally like avocados, avocados are a terrible food and others should shun them as well. The issue — obviously — is not in the avocado but in the individual, but emotions conceal the obvious.

I see two reasons why we can’t just ignore this meaningless debate. Firstly, it’s important because young people — ill-equipped to properly assess the question — are liable to waste a lot of effort and opportunity on it. Secondly, the very fact that it recurs, always disguised as a broad and serious question, convinces me that its persistence hides some deeper issues, some lurking motivations.

I consider myself uniquely qualified to comment on the question. Before I developed the practice of interaction design, I built a successful career writing some of the most innovative software for personal computers in the 1970s and 80s. Despite my qualifications, my own tweet storms are inadequate for this challenge. There are too many issues and too much nuance for brief expostulations. Thus, my thoughts on this topic are here.

There are several arguments to make against the premise that designers should code, but I only see one argument for it. The problem that none of the arguments addresses is that the entire question isn’t really relevant. It’s a symptom of other issues in drag. The main effect is to hide the one meaningful, important issue of how practitioners should work together. I’ll talk about that one later.

The primary arguments against designers coding are as follows:

1. You can know without doing. There are many examples of coaches, choreographers, trainers, and executives who direct the work of practitioners without ever actually doing it themselves.
2. Performing a task does not automatically teach you the implications of that performing it. Just because you code, it doesn’t mean that you automatically understand the effects of your code on others, or on the organization.
3. There is a tremendous breadth of skills, tasks, and job roles in the software development world and making assertions in the simplistic duality of “designers” or “developers” fails to recognize the complexity and nuance of these roles.
4. Why are we even asking this question? It always seems to be posed by the practitioners with the least empathy for others, asking for empathy from the far more empathetic group, while ignoring the truly important challenge of empathizing with the user.

The one argument to make that favors designers coding is really just a broad generalization that doing someone else’s job for awhile is a good way to gain an understanding of the challenges that person faces. So, yes, it is generally a good thing for designers to spend some time coding. Of course, by this same argument, coders should spend some time designing. And by designing, I don’t mean designing screens. I mean interviewing users and then making sense of what they learn.

However, I emphatically don’t believe that production coders should do production design. That would be equivalent to asking the programmer to do the bookkeeping. Sure, they are probably capable of it, but why? What a waste of good programmer talent on common bookkeeping. Good programmers and good designers are rare. It is foolish and wasteful to make them work outside of their particular special skill.

The real issue.

The truly serious fault with all of these arguments is that they avoid the single most important question: how do we create software?

A lot of software gets built every day in the world, but that doesn’t mean that we actually know what we are doing. Stuff does get built, and human nature being what it is, we regard that as normal. But infamously, in the waterfall world of enterprise development, some 80% of all software projects fail. We have been building crappy software systems for decades, and we still can’t seem to figure out how to do it effectively. Typical projects never get out the door. Those that do get deployed are often pathetically weak versions that lack power and flexibility.

Agilistas gloat over the failure of conventional software development methods, but their more modern methods of creating software aren’t significantly better. Mostly the failures are smaller, faster, and easier to hide. I don’t want to get into an argument on this point, because I think that agile is a wonderful and tremendous leap forward in the world of practical software development. But it sure hasn’t lived up to its billing. It confounds management. It is notoriously difficult to perform at scale. It often sidelines real user-centered design. It is reactive rather than proactive. And worst of all, many of its practitioners utilize managerial and technical hand-waving, smoke-blowing, bogus claims, and prestidigitation as a fig leaf to conceal ignorance, incompetence, and a refusal to work well with other necessary disciplines, most notably, interaction design (Yes, this is a blast at agile, but — for the sake of perspective — I believe that agile is better than all the other development methods we have).

Worse yet, is that teams are constantly bickering over turf, blaming the various disciplines for their inability to meet deadlines. There are people who claim that “software deadlines” is an oxymoron, and establishing them is prima facie evidence of a lack of understanding of the medium. Frankly, I’m one of those people. Just about every single coding effort is a sally into the unknown, and it usually takes a couple of trips through to learn the territory. Prediction is impossible. I’m fond of comparing software development to walking through a minefield: if you don’t step on a mine, it’s quick and easy. Anybody who gives you a prediction of how long software development will take is dissembling. And if you ask someone for that prediction, you are encouraging prevarication, and you are sustaining the industry wide myth that developing software is predictable.