The article is good on the whole but the title "Code is run more than read" seems false in many situations I've been in. A lot of software doesn't have users. O

The article is good on the whole but the title "Code is run more than read" seems false in many situations I've been in. A lot of software doesn't have users. Often the target users don't like the product enough and are just trialing it for you as a favour. In these cases, it's not very meaningful to say it's being "run more than read", because either you should have made the code readable enough for other developers to delete it, modify it or rewrite it until users want to use it, or the code has to be valueless and able to be completely thrown away (the knowledge of how to build it is either written down elsewhere or tacit). I also agree with what somebody else said about the times in which the features/fixes you create aren't seen by users but just benefit a business-to-business sales process. In these cases, you behave differently. You do the work because there's a very clear signal to your company meeting their expectations promptly. I guess one way I would agree with the article is that once something has users/businesses and is somewhat readable you apply your extra effort on polishing the user experience as prioritising the happiness of your core users is generally a good idea.