Software Is About People, Not Code
Software is about people, not code (2020)
A developer reflects on a career spent perfecting code—style guides, design patterns, even decompiling Java—only to realize that the success of software hinges on people, not code. Code exists to serve human needs, and the most elegant codebase is worthless if it solves the wrong problem. The real challenge is understanding people, their purposes, and whether they'll use what you build.
The most beautiful, well tested, flexible, configurable, documented, future proofed codebase that does the wrong thing is useless.
- randusername
Tired of these absolutes.
Software should be about the code, but not for every person on every project for all parts of that project.
It's great to "wake up" and realize that code doesn't have the intrinsic value you might have assumed, but you can also take that knowledge and go right back to writing beautiful code where it best serves the bigger mission.
- JSR_FDED
When I was a developer I thought “without me all the people in the building have nothing to sell and they can all just go home”.
Then I spent a few years in sales (long story) and flipped 180 degrees. Without salespeople (and the customers they bring in) there would be nobody paying our salaries and we all could just go home.
- knuckleheads
"Software [ought to be] about people, not code"
Related but not quite the same as https://en.wikipedia.org/wiki/Is%E2%80%93ought_problem
- fasterik
John Carmack made a similar point:
"Software is a just a tool to help accomplish something for people - many programmers never understood that. Keep your eyes on the delivered value, and don't over focus on the specifics of the tools"
That said, I don't think Carmack would ever say that software isn't about code. It's more that code should be written and evaluated based on how much net value it delivers to people, not on arbitrary technical metrics.
- agentultra
I think people are one factor. Source does, when done well, communicate intent and implementation precisely to other people. If the language has enough semantic information it can communicate some part of the specification as well. Knowing what to write and ensuring your software does what you think it does is an important part of a project. It takes working with people to build the correct understanding of the specification and requirements.
But to a degree it is also about the code. Sometimes your requirements are: be fast enough. In which case you need to think about code: instructions and data.