Code is run more than read
From perspective over the software development cycle
NOTE maintainer > author
Code is a means to an end. Software should have a purpose, it’s supposed to provide a service to some user. It doesn’t matter how well written or maintainable the code is, nor how sophisticated the technology it uses if it doesn’t fulfill its purpose and provides a good experience to the user:
NOTE user > maintainer > author user > dev
When I say “run” I don’t just mean executing a program; I mean operating it in production, with all that it entails: deploying, upgrading, observing, auditing, monitoring, fixing, decommissioning.
When you run your code in production, the KISS mantra takes on a new dimension. It’s not just about code anymore; it’s about reducing the moving parts and understanding their failure modes. It’s about shipping stuff and ensuring it works even when it fails.
NOTE user > ops > dev
NOTE biz > user > ops > dev
The most obvious example is budget: we don’t have infinite resources to satisfy the user needs, so we need to measure costs and benefits. There’s marketing, there’s deadlines.
ROI question
There’s a mismatch between what we thought doing a good job was and what a significant part of the industry considers profitable, and I think that explains the increasing discomfort of many software professionals. And while we can’t just go back to ignoring the economic realities of our discipline, perhaps we should take a stronger ethical stand not to harm users. Acknowledging that the user may not always come before the business, but that the business shouldn’t unconditionally come first, either:
NOTE user > ops > dev biz > ops > dev biz ≹ user