This week, my brother and I were comparing home renovation projects. I spent several months of COVID-19 quarantine ripping up carpet and laying a floating hardwood floor. I then spent several weeks measuring, cutting, laying, and nailing in quarter round trim over all the gaps along the edges of the floor. But my house was built in 1913. So you can imagine that a lot of things didn’t line up.
One of the biggest gaps (oof, pun) came at each threshold. There were literal gaps -- the living room floor is almost two inches lower than the kitchen tile. I’ve spent hours tinkering with different solutions (and even hand-made a broad, sloped threshold for one particularly wonky doorway). But none of them are installed. And finishing trim pieces are lying around loose, waiting for the thresholds. And then there’s all the paint work that needs to be done before the floors can be pronounced “finished.” And and and.
My brother (a mechanical engineer by trade, a vintage Mustang owner, and a DIYer to the extreme) said, “Gurl that’s been a minute! Slap some thresholds on there, beat to fit, paint to match, and walk on em!”
Done is better than perfect.
I know that if I can just finish my floors to the degree that there are no gaps and no major sawing/nailing/construction tasks left, a part of my brain will relax, and I’ll get a lot of that mental capacity back to use for other things.
I know that this plays out in agile software development, too.
I’ve worked on teams where the designers are so far behind, tweaking and nudging and perfecting, that the developers are fed up and the customers are bewildered.
I’ve worked on teams where design iteration went round and round and round and where she stops nobody knows.
And I’ve worked on teams where done was good enough for starters. We knew we had something functional to show to customers and from there, we could learn how to improve.
In fact, despite my protests that I am not a designer, I ended up building a software prototype for one team. It was meant to replace an expensive, licensed program. So I spent months shadowing our users, understanding vital functionality, and tracking pain points with the current system.
I built the prototype, and as soon as all the screens were linked up, we tested it. It wasn’t pretty (the users said so!), but it was functional and intuitive and ten times easier than the thing they’d been wrangling (they also said these bits).
Done was better than perfect. From done, we could measure the gaps to user expectation, scope an MVP, and get real code started while a designer fixed the look and feel. From done, we could phase out whole releases of the software and give accurate estimates for when the company could kill expensive licenses. From done, the developers had a solid picture of what they were building, why, in what order, and how customers would likely receive it.
If I were a betting person, I would bet we’ve all been in critiques where someone displays a perfect design that’s taken them months to craft. Don’t get me wrong -- I’m in awe of those skills. But when we then have to spend hours nitpicking functionality and hierarchy and level of detail, all based on hypothesis, you can understand why product gets a little impatient.
What if we built a good enough version from what we knew, and carried a “Let’s test it and see” mindset? What if we lived in “always learning”? What if we declared “done” to be better than perfect and let user feedback guide us to the next version?
I’d have thresholds in my house and would be working on garden plans already, that’s for damn sure.
Photo by Vance Osterhout on Unsplash