I recently started as a UX designer at Emma. It’s my job to design and build products that are easy to use, look great, run quickly and smoothly, and most importantly, help people get their jobs done. I think carefully about how disparate factors like user experience, design, code, and data come together to make an awesome product. Because so many factors come into play, a product’s design has to be sound before we allocate a lot of resources to building it.
One of my engineering heroes is Rich Hickey, author of the Clojure programming language. His essays and interviews on the subject of programming languages and paradigms have been the basis of many lively discussions among my more nerdy friends. Recently, Hickey gave a talk entitled Hammock-Driven Development at Clojure Conj. During his 40-minute presentation, he lays out a framework for effectively and efficiently navigating a project’s design phase. I recommend watching it, and I’ll outline some of its insights here.
Spot problems early
In software development, we try to minimize the number of bugs in the final product because it’s extremely expensive to fix bugs in a production or shipping software system. So, we institute a formal quality assurance process to catch bugs before code goes into production. But a quality assurance process is pretty expensive, too. So, software developers try to catch bugs in the development process, before the code goes to QA, by using software-testing methodologies.
But, Hickey argues that “most of the biggest problems in software are problems of misconception” not of implementation. Expensive, fundamental problems in designing any sort of deliverable tend to happen when you don’t have a clear picture of what you’re doing before you start. Hickey suggests spending a good amount of time “in the hammock” coming up with a good solution before you start any work.
In hammock-driven development, the analysis and design phase of any project — during which we can identify and understand the problem, propose a solution and assess the viability of the proposed solution — is the most important.
Do the right thing
To understand the problem, take inventory of what you know — the context of the project, facts that bear on it and constraints that are imposed — as well as what you don’t know or cannot yet determine. Also, anticipate that, at the outset, there will be aspects of the problem that you don’t know you don’t know.
Then, Hickey suggests, do research to find the best solutions that already exist in the problem space. Learn from them, examine them critically and create a better solution. “You will often find the next big idea by completely crucifying the last guy’s idea,” Hickey says.
This is where the hammock comes in. With a good conceptual map of the problem, it’s time to start forming solutions. Focus and minimize distractions. Hickey implores us to “step away from the computer,” and suggests lying in a hammock to think. “You can go in the hammock, you can close your eyes, and no one knows that you’re not sleeping, but they won’t bother you because they think you might be sleeping.” During hammock time, you propose solutions to yourself, analyze them for their pros and cons, and make sure that they fully address the problem with all of its requirements and constraints.
But this is only half of the solution-synthesis process. The other part takes place while you’re sleeping. For Hickey, “eureka moments” often happen when he wakes up. When you feel a “eureka moment,” capture that insight by writing it down, and be ready to analyze it.
And what if you get stuck? You might need to simply wait for your “background mind” to yield further insight, or you might need to do more research or talk to people about the problem. If you need to wait it out, have other projects or problems to work on while your subconscious congeals around the sticky problem.
Finally, you have to give it a go. Be confident in the solution you’ve devised; you have thought it through and taken copious notes on your solution, so you should be able to do a fairly minimal amount of work to realize a prototype of your idea. If your idea doesn’t quite work, understand that it’s just part of the process, and that you’re already in a great position to think of a better idea.
Check out Hickey’s essay on the rationale of Clojure, as well as the discussion on Clojure’s approach to identity and state. While both of these articles are rooted in the context of Clojure, they present ideas that are generally applicable to many different programming languages.
I’d love to hear your thoughts. Comment here or over at @emmaemailtech.