Hacker News new | past | comments | ask | show | jobs | submit
> Most consumer software in developed under the assumption that features only have a cost when being built. Their maintenance cost, and the combinatorial complexity each new feature adds, is barely considered.

I suppose that's true, but I don't see what it has to do with UI design from a usability standpoint.

> But this doesn't mean the software couldn't still be improved, just that there isn't the resource available to do so.

It's a push and pull from both sides, isn't it? The accretion of process complexity among the developers may increase over time, but so too does the completion of core features and solution of all of the low-hanging-fruit development tasks.

Pretty much every GUI application I've ever used seems to hit a point where the original purpose for which the software was devised is satisfied for essentially all common use cases, but the incentives of the dev team are to keep going, so they move more and more toward gimmicky features, unnecessary bells and whistles, visual changes to the UI, etc. because any real functional improvement is a big investment, but they still need to justify a new release.

UI churn is one of the most common failure modalities here: when you've already picked all of the low hanging fruit in functionality and performance, major UI changes can create the appearance of improvement and innovation without actually having to do any of the hard work to achieve real improvement.

So when I see unnecessary UI changes to an application that still basically does the same things in the same way, at this point I'm conditioned to assume that that application has hit the point of diminishing returns for actual functionality, and the development incentives are now going to be driving more and more churn. And that's when I consider the software "finished".