I completely agree. The most important lesson I’ve learned in the past decade of software development is:
Good product/UX design can save bad engineering, but it doesn’t work the other way around.
Tackling a real problem > Having a big addressable market > Good product / UX > Great Engineering.
Strictly.
Great Engineering pays back at a much larger time scale and makes for an enabler or a breaker at the critical scaling stage only. You can get surprisingly far with a protoduction service and still build something huge (see Twitter).
Great design is atomic and homogenous. Weak technology leadership ends up in opening up a vacuum that gets filled by Architecture Astronauts (Etsy), every team doing their own thing technologywise (SoundCloud), or at the very worst, some dogmatic homebrew NIH stack (various places I‘ve worked at).
Every unhealty Technology organization looks unhealthy in its own way, but the great ones look all alike: Clean, simple, rather homogenous and logical.
Depends on how "bad". I've seen _many_ counterexamples, where no amount of lipstick could fix the underlying flaws. What good is a pretty website if it's slow, or if it doesn't work at all half the time.
Case in point, all servers were configured to accept a maximum of 5 connections, so when the load balancer got more than x concurrent requests, they started failing.
Instead of fixing the problem, we can just scale the amount of servers (horizontal scalable yay), until the problem goes away.
Now you have tons of 8GB/4C machines sitting (almost) idle, and immense amount of money wasted.
This works if the bad engineering causes a linear increase in scaling costs. If the bad engineering causes an N! increase or a 2^N increase in scaling requirements, then there's a good chance all the servers on the planet aren't enough.
I'd say engineering is no easier to fix by throwing money at it than UX is.
The two most important things are data and UI, the one thing we developers spend all of our time thinking and talking about is code :)
Because data >>> UI >> code.
> Also, business logic is encapsulated in code - if that's borked, no amount of UI will save it.
The assumption here is that the bare minimums are fulfilled. If the software doesn't work at all you have none of the above.