No One Wants to Waste Time on Rework

So often in my career, I’ve heard, “We have to lock down that design before we develop,” or have been asked, “Is that the final final version?” before an engineer wants to touch it. I’ve even been that arbiter of finalization myself in the past. But I’ve learned recently that this completely cuts off the opportunity for innovation and creative problem-solving. It also doesn’t work to serve your users as best you can. 

What if we approach software development similar to how Thomas Edison approached making a light bulb: “I never once failed at making a light bulb. I just found out 99 ways not to make one.” Each time he tried wasn’t a waste — it taught him a valuable lesson about what didn’t work.

It’s the same with what we do.

We should constantly be talking to users, testing designs, and getting feedback on what we’re building. And if we end up needing to redo something, it’s because we learned something valuable. That’s the whole endgame, right? We have an opportunity to deliver something better than our original vision. 

Keeping a flexible, fluid approach to design and engineering allows us to solve problems in real time, focusing on the task or feature at hand instead of planning out the whole menu in advance. 

In fact, that’s a good way to think about it. Imagine you’re a chef tasked with cooking a five-course meal for 50 people. You’re going to carefully plan out a menu, shop for ingredients, and plot out the specific timing of each course, right? But what if only 20 people show up for the first course? Then for the second course, half of the new arrivals are vegetarians. Then, at dessert, you find out that several folks are allergic to dairy. You have to make changes on the fly, likely even recooking parts of the meal to accommodate this new information in order to satisfy your guests. If you just kept trucking along with your original plan, you’d end up with a lot of hungry diners and possibly even a few sick ones.

So is it a waste to make those changes, even if it means redoing some of the cooking? Or is it a way to nimbly adjust to the needs of the diners as new information presents itself? Which approach is going to result in the best dining experience for everyone? 

That’s how I view software design and development. You have a plan until you don’t. 

Of course, you don’t want to blow up budgets or timelines with senseless churn and change for its own sake. It needs to come from somewhere — a new user requirement, a faster way around a technical constraint, or even just a stroke of creativity halfway through the project. But shutting down the possibilities of those things because you’re afraid of “rework” actually results in a less successful product. 

Rework should be viewed as a positive thing — you learned something new, and now you’re taking the opportunity to improve what you’re building. There’s no “waste” involved in that. 

Natalie Kurz (she/her) is Head of Product Design at Postlight. Get in touch at natalie.kurz@postlight.com.