Published: April 13, 2022 • 3 min read
I recently completed a winter survival course, where we had to a build a shelter with just the contents our packs, in ten minutes. Unfortunately, my pack was nearly empty. I made a tent out of my parka and some branches. It was ugly but it could have saved my life.
When building something, get it working, then make it look good.
This is advice I’ve relearned many times. I’m writing this post for you and also for me. My thanks to Chris Erin, who taught me to think this way a long time ago.
Let’s consider a weather-forecasting app that queries a third-party API to get a forecast. When I say “building something new”, I’m describing a scenario that most programmers will find familiar: you’re building greenfield and there isn’t a UI already built.
When I say “get it working”, I mean get the API returning data and dump it onto the page. Ugly is okay.
And when I “say make it look good”, I’m talking about styling it so that it looks like a modern application.
When you get it working first, you prioritize shipping. You’re getting the real data you need to support the actual feature. That progress is very powerful when staring at a blank screen.
When you get it working first, then run out of time, you at least have data. Most people in the vicinity of software-building can look at raw data printed on the page and imagine what it could be.
This approach gives you something real: data that you can manipulate when the time is right.
What about making it look good first? Maybe you’re a programmer who loves design and that’s your comfort zone. Here’s what has happened to me when I haven’t followed this advice.
I built the wrong UI. Perhaps your data comes in a table-shape, but you build a beautiful list. Docs aside, you don’t really know how the data is going to look until you’ve made a few queries. You made a beautiful thing that’s useless, and now you have to throw it away.
I ran out of time. If you run out of time and must ship or demo, a beautiful empty table isn’t going to excite your stakeholders or inspire future investment. People can make a mental leap from data to a table, but most struggle to do the reverse.
Something to consider is the Iceberg Secret. In this post, Joel Spolsky argues that nontechnical stakeholders assume that a polished UI means that the underlying behavior is complete, even if thought that’s often wrong. And vice versa, that same person sees an incomplete UI and assumes incomplete software. Maybe we should prioritize design for these people?
I think Joel’s assessment applies only to the least-technical people involved with software. And as software eats the world, these people are becoming less common. Many people who don’t have the title ‘programmer’ can read at least a little code. Prioritizing your MVP for people who are mystified by data is, I think, a mistake. You might make them smile but you’re slowing your path to a working proof-of-concept, and that’s what they actually want.
At Hashrocket, we had very skilled designer slash frontend engineers who built beautiful, responsive, and simple placeholder UIs for us. We engineers got to think almost entirely about data flow because the UI details were solved. I’ve only been on a few teams that worked this way, but it was sublime. Thanks Cameron, Rye, Mike, and Daniel.
Get it working, then make it look good.
✉️ Get better at programming by learning with me. Subscribe to Jake Worth's Newsletter for bi-weekly ideas, creations, and curated resources from across the world of programming. Join me today!
Blog of Jake Worth, software engineer in Maine.