Jake Worth

Get It Working First

Published: April 13, 2022 • Updated: November 21, 2022 3 min read

I recently completed a winter survival course where we built shelters in just ten minutes with only the contents of our packs. The pack I brought was nearly empty, so I made a tent out of my parka. It was ugly, but it could have saved someone’s life.

When building a new feature, get it working, then make it look good.

Let’s say you’re building an app that queries a third-party API to get a data. “Get it working” means get the API returning the data you need, and then just dump it onto the page. It works. Then, “make it look good”: style it like an appropriate twenty-first-century webpage. I’ve had a lot more success doing things in this order than in the reverse.

Why Get It Working First

When you get it working first, you prioritize shipping. You’re getting the data you need to ship. That can be very powerful when staring at a blank screen.

When you get it working first, then run out of time, you have something: real data. Most people can look at raw data printed on the page and imagine what it could be.

You can then make it look good when the time is right. Sometimes, that time isn’t now. It may never be that time.

I’ve also found that this technique relieves stress because I’m not trying to solve two generally unrelated problems– how something works and how it looks– at once. Styling is fun when it’s the last step of a feature. It’s stressful when I’m not even sure that I’m styling the right thing.

Counterargument: Make it Look Good First

What about making it look good first? Maybe you’re a programmer who loves HTML and CSS and that’s where you prefer to start. Here’s what has happened to me when I’ve taken that route.

I built the wrong thing. Perhaps your data comes in a table, and you built a beautiful HTML list. Documentation and API behavior do not always agree, and you don’t know for certain how the data is going to look until you’ve made a query.

I ran out of time. If you run out of time and must ship, a beautiful table full of Lorem Ipsum isn’t going to inspire your stakeholders or earn investment. I’ve found that people can make a mental leap from raw data to pixel-perfect HTML, but most struggle in the reverse.

Who to Build For

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 incorrect. And vice versa, that same person sees an incomplete UI and assumes incomplete software.

Restated, some stakeholders dismiss working features that look bad. Maybe we should prioritize design for them by making it look good first, or earlier?

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 can read at least a little code. Prioritizing your MVP for people who are mystified by raw data structures is, I think, short-sighted. You’re gold-plating while your competitors are shipping.

Perfect World

At Hashrocket, we had very skilled frontend engineers who built beautiful, responsive, and simple placeholder UIs for the dev teams. We 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. My thanks to Chris Erin, who taught me to think this way a long time ago.

✉️ 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.

© 2022 Jake Worth.