The false dichotomy of Worse Is Better vs. The Right Thing
I'll assume you know about the titular debate, if not here's a decent analysis
. In this post I want to go further and show that both approaches are wrong. None of this should sound original to those who know design but unfortunately few in the developer community do.
Any kind of engineering is ultimately about people, their quirks and limitations. The Worse Is Better side understands the limitations of developers and correctly notes that complex products often don't ship at all because their developers run out of time and money before the first usable version sees the light of the day. Also given the iterative nature of design it makes sense to start small and make incremental advances so that potential users can stay in the loop and provide feedback.
The Right Thing side understands the limitations of end users and deservedly criticizes the WIB side for producing software with user-hostile UX. Because the opensource culture is heavily influenced by Unix the WIB approach permeates it to a large degree. However, at this point the mountain of evidence clearly outweighs whatever arguments the WIB side can offer. For example, the essay
that sparkled the debate mentions the original Unix approach to handling interrupted system calls -- that approach has since been fixed virtually everywhere because it makes system call handling onerous. Or here
now-well-known design expert Don Norman argues that command line experience in Unix is 'horrid'. That article is from 1981, a few years after Unix was released into the wild. Then there's The Unix-Haters Handbook
from 1994 that describes something similar. And finally you can look at modern reports of companies getting pwned because some admin misconfigured an internet-facing server. The WIB side will say that, well, they should've known better, they should've read the manual, but I hope you can see the pattern. Git has a similar story: lots of cowboys ready to jump to its defense but also lots of pain and fucked up repos, and even some analysis
of what exactly is wrong with Git's architecture and UI.
Like I said before, engineering is ultimately about people and here we have two sides: developers and users. Therefore the correct approach is to consider them both. To some extent this is what MVP is about but, as this article
argues, in practice it's often interpreted as producing half-assed products for the sole purpose of getting feedback. The article calls the holistic approach SLC (Simple, Lovable, Complete) meaning that every iteration should be a complete product. This idea that even at 0.0.1 you're building a complete product is quite important. If you are a perfectionist, like myself, this is where to redirect your perfectionism -- at finding the most minimal but complete design at every iteration. When it comes to 'lovable', function-over-form minimalist designs often look attractive and age well, so even if you aren't good at aesthetics you can still do OK if you just keep it simple. Engineering is essentially an art of finding the sweet spot where a product has a high degree of design integrity and a simple mental model for its users but is also approachable for its developers.
What "Worse is Better vs The Right Thing" is really aboutyosefk.com