I was recently interviewed for a new contract. One of the questions I was asked was this: which would I say was more important: beautiful code or a good, polished UX.
I found it to be a very important question. Paraphrasing, this was my answer:
Beauty is in the eye of the beholder. We should first define what beautiful code is. For me, beautiful code is clean code. It’s maintainable code. It’s easy to understand. It has good test coverage.
And so, I would argue beautiful code is more important.
The reason is quite simple: with clean code, introducing new features becomes easy. You are less likely to introduce regressions. Fixing bugs becomes easier, too.
This all translates to a better product for the end user. And so, by prioritising beautiful code, you gained both goals: beautiful code AND a better UX. Consistently.
The opposite is not true: if you prioritise UX and knowingly neglect code quality, you will soon realise you’ve made a mistake.
Adding features would become a daunting task. New bugs would frequently occur. Fixing new and existing bugs will become a nightmare. The product will become a scary beast.
Eventually, the user experience would suffer. You will end up losing both goals.
And so, my choice would always be to go with beautiful code. I’d rather not meet the beast.
2 thoughts on “Beauty And The Beast”
It gets down to better-faster-cheaper. Choose any two. You’ll never get all 3!
I’d argue the only variable should be scope. Quality should be fixed and high, which also dictates the speed, and scaling quickly is likely to slow you down for a while before offering any gains at the cost of communication complexity.