If we were doing it for the art, then we'd have less problem, but just having end dates for payment of delivery is why a guy will make h5 bigger than h4 in css: there's no time, we can't break the existing stuff and hope to repair, we Frankenstein and pray no one cares for 10 years.
The thing is that, he's probably vastly exaggerating the effect of this uncleanliness: what matters is to isolate it well enough, make people embrace the problem, reward those who fix it if they can at tolerable cost but not forget that what matters is REALLY the end result. A company can double the cost of maintenance of a beautiful popular interface and still profit well enough EVEN IF, had they spend triple the time with triple the people they could maybe have reached a more logical beautiful internal design... for a bit.
Or: is it better to have a fugly rifle or a beautiful water pistol, if your goal is to survive in the jungle ? Even if the water pistol is more durable, perfectly measured, made by people who never stressed, when it's time to face the bear, it's still a water pistol. And the "middle ground" would be half a gun, that's WHY we always end up either with a beautiful useless system, a fugly useful system, or a fugly useless system transitioning to either.
I think many software developers who love what they do go through that kind of phase in their careers. I got over it after realizing that results come first and written code is not a weightless piece of art. All code is tied directly to the value it provides. The best codebases I worked on were far from perfect but they were owned by teams who had a clear understanding of the tradeoffs needed to be made at different places in the code. Business critical code, subject to continuous new additions/changes, was refactored multiple times per year and kept in a state close to what the poet in me craved in the past. But the value proposition for this was clear for everybody. On the the other hand many places in the code were far from that level because it didn't make any sense to invest that kind of effort everywhere.
> My hunch is this: folks can’t talk about real design systems problems because it will show their company as being dysfunctional and broken in some way. This looks bad for their company and hence looks bad for them.
I guess it's natural that people prefer to present and discuss their successes more than their failures. After so many years reading this types of blog posts my understanding is closer to 'Oh look at a big problem that we had and how we managed to solve it in an elegant way' instead of 'We have no problems whatsoever, we do everything perfect and this is one of those examples'.
> The ugly truth is that design systems work is not easy.
Design systems are basically UI frameworks. Building a framework, keeping it up to date and continuously evolving it is far from a simple task that can be done while also delivering new features on time using said framework. And as the system grows the complexity keeps on rising.
At many companies it's hard to justify the needed level of effort especially if they are not in the business of building frameworks or don't sit on a mountain of cash. A handful of talented people will dream of building something cool and will invest their time (and sanity) into this type of effort but they often bite off more than they can chew.
