Sofware Engineers Should Think Like Architects
Software engineers and software designers need to become more like architects
Preface: throughout the article I refer to “architects”. I always mean they type of architects that design buildings, not the “software architect” role that exists at many tech companies. Also, be aware of the difference between “a design” (a plan), “designing” (planning) and “Designer” (a discipline).
An architect is a person who is trained to design buildings. When you study architecture, you take courses that cover how buildings are used (interaction design), the beauty of buildings (visual design) and the various materials/construction techniques/legal codes/physical limits that stipulate what is possible to build and what it will cost (technical design). When it comes to making buildings, the word “design” covers both the “why” and “how” of any project.
However, if you ask people in software what “software design” is, you’ll get a very different answer depending on who you ask. A software engineer will describe the technical design; how the design is modular and maintainable or how fast it is. If you ask a Designer they will describe either how it’s useful or beautiful. We have separated the “why” and “how” of design into 2 roles.
A design process needs to continuously weigh the user value against the cost of implementation. By splitting into Design and Engineering we’ve created two roles critical to the success of any project, and we haven’t given them the vocabulary to communicate effectively. To worsen things, most people on one side don’t fully understand what the other side does.
The classic example is one I’ve seen a dozen times. A designer and engineer are sitting in a room. The designer pitches their perfect design. the engineer says “that’s really cool, but that’s not technically possible” *. A hint to designers, pretty much anything is possible. 5 years ago Kinect or the iPad would have seemed impossible. What the engineer is actually saying is “that’s going to be very expensive” or “we don’t have the resources” or “I don’t know how and I’m not creative enough to try”. If it’s the last one, get a new engineer, but the first two are valid. Without the designer having technical training, its very difficult for the engineer to explain the details behind why the design is challenging/expensive, and the designer doesn’t have the chops to challenge the engineer (even though a good one will try).
Another classic example is a designer assuming technical constraints where there aren’t any. For years web designers assumed they were stuck with the “click-wait-load” interaction commonly seen on the web. It took an engineer at Google to challenge that and build Gmail, the first large scale web-app that used AJAX/javascript to instantly render the next page when you clicked a link **. Conversely I often see engineers assume a user need where there isn’t one. A huge number of settings in software are not the result of any user need, but an engineer refusing to make a decision when faced with 2+ acceptable options.
Luckily, our nature seems to push back on the false boundaries we created when we split design process into so many roles. Since everyone involved is usually passionate about the project, they try their best to look at the holistic design. I’ve seen software testers critique visual designs and Designers critique software performance or ask how much time would be saved if we cut feature X or Y. Great engineers and designers fight for what we believe is right, and by respectively challenging each other we get some pretty amazing things done.
What can we do to break down these barriers further?
First, teach more “design” skills to Engineers and engineering skills to Designers ***. We’ll likely never fully converge (after all, Civil Engineers and Architects are separate roles), but we should at least share a vocabulary. Call bullshit on “that’s not possible” and be willing to sit through the painful conversation that follows. The result might be that it will take 2 years to build, but it might just be worth starting now. Build a design team with both engineers and designers. Keep it small. Reduce the division of design wherever possible. If you had a Engineer, a Tester, a Interaction Designer and a Visual Designer try to make it just one Engineer and one Designer. **** Don’t design by committee. Not everyone on the project has to be on the design team. However, don’t ever discount feedback, great insight can come from anyone. Don’t silently assume technical constraints or user needs. Make them explicit, and let people catch faulty assumptions early Keep the passion alive. Passionate people will find a way to make things happen* I once asked a developer at Microsoft to increase the size of a list from 10 to 25, and he told me “that’s not technically possible”. He still works at Bing.
** http://en.wikipedia.org/wiki/History_of_Gmail - Note: AJAX interaction was around before Gmail, but I’m giving Gmail credit since it was one of the first big applications using it for all of the interaction
*** Some schools such as the MIT media lab are excelling at this, and it’s no surprise a huge number of entrepreneurs come out of those programs.
**** I worked using this model on Windows Phone. When it works it’s awesome, but too often the engineering role is filled by a Program Manager who hasn’t touched code since they graduated 14 years ago.