> Don't bother improving your product unless it results in visible changes the user can see, find, and hopefully appreciate.
That's ridiculous and blatantly incorrect. Users may not notice it but that doesn't mean the development team won't find it easier to understand or the support staff won't find it better to troubleshoot. It is possible to write the most convoluted code for any product that functions in the exactly the same way as the the cleanest, most-easy to understand code. The user will not notice the difference but which one would you rather want to be involved in?
Also, there are a lot of code improvements you can do that maybe nobody notices today but will certainly avoid catastrophes in the future. For example, hardening security. Most users won't notice or care about your security policies when you just release your app but once your product starts to gain traction, you should spend time making sure you improve security on a constant basis. Users do not care if you still use MD5 for hashes but you might as well go ahead and rewrite your code to use better hashing algorithm already.
There's also the financial aspect. As the business needs change, maybe you can adapt your code to perform better on cheaper hardware while giving up some potential features that you had planned on. I ran a moderately popular website that could handle 1-2m visitors/day on some beefy hardware but seeing as how most of our traffic came from embeds, I was able to switch hosts and platform and satisfy the critical load using very cheap yet stable hosting. The users did not see any performance or feature change but I saved $700/month.
So yeah, I would definitely improve code if it has more substantial, long-lasting benefits than immediately obvious to end-users.
I think the author is aware of this but his "Don't bother improving..." statement seems to be a result of him trying to add more punch to his post. Seems to be a recent trend with his articles.
I think that if you drop the semantics and take the article for what it's talking about -- new front-end features you specifically want your user to be using, or at least to investigate and become aware -- then he is wholly right, you should give the UI a bump, tiny or big, if you want someone to notice.
Too often a programmer will drop a new button into a list of buttons and then, two weeks later, incredulously ask everyone why they haven't found it yet.
(Of course, A UI bump doesn't always just mean cover it with new gloss. Simply moving elements around, creating spacing, changing up the colors or weighting/priority of items in a list can be all the change you need. Obviously not any one of those things arbitrarily... Any piece of UI, regardless of how pretty or "artistic" it is, should always have an intent, and the intent in this case is to do something that causes people to investigate your new functionality.)
I think the author's Windows calculator example is a great case for this. Over time more functions have been added to that thing, but when its literally another button added to the grid, few people are going to notice it and investigate it. Some will surely come across it because they'll need to perform some mathematical function for the first time, but nobody will actively investigate the calculator for the new stuff because nothing and nobody has told them to.
Conversely, if you crack open calculator for the first time on a new PC or new OS install and see that its appearance has been cleaned up across the board, or that a row of buttons has been newly split out and given its own breathing space in the window layout, you might actually look at them and discover what they do.
I don't think that this article applies to code improvements under the hood, or even really to improvements to existing functions that will streamline the user experience. This is especially true if those user paths are well traveled. If they're already there, you don't need to bump anything to tell them to go there -- they'll figure it out.
It's when new things are added, or when existing-but-underutilized things are beefed up, that adding some new gloss or shifting your design's visual priorities a little bit can go a long way.
That's ridiculous and blatantly incorrect. Users may not notice it but that doesn't mean the development team won't find it easier to understand or the support staff won't find it better to troubleshoot. It is possible to write the most convoluted code for any product that functions in the exactly the same way as the the cleanest, most-easy to understand code. The user will not notice the difference but which one would you rather want to be involved in?
Also, there are a lot of code improvements you can do that maybe nobody notices today but will certainly avoid catastrophes in the future. For example, hardening security. Most users won't notice or care about your security policies when you just release your app but once your product starts to gain traction, you should spend time making sure you improve security on a constant basis. Users do not care if you still use MD5 for hashes but you might as well go ahead and rewrite your code to use better hashing algorithm already.
There's also the financial aspect. As the business needs change, maybe you can adapt your code to perform better on cheaper hardware while giving up some potential features that you had planned on. I ran a moderately popular website that could handle 1-2m visitors/day on some beefy hardware but seeing as how most of our traffic came from embeds, I was able to switch hosts and platform and satisfy the critical load using very cheap yet stable hosting. The users did not see any performance or feature change but I saved $700/month.
So yeah, I would definitely improve code if it has more substantial, long-lasting benefits than immediately obvious to end-users.