4 ms·

As a fellow software developer, I respectfully disagree. While a piece of software may satisfy its requirements, it will never satisfy them perfectly or optima

As a fellow software developer, I respectfully disagree. While a piece of software may satisfy its requirements, it will never satisfy them perfectly or optimally. All software contains bugs, unexpected failure modes, and undiscovered security vulnerabilities. I am convinced that there are essentially zero exceptions to these claims. Furthermore, the environment in which software runs must change over time. This causes "bit rot" as (say) dependencies stop receiving security updates or platforms become unsupported. Finally, there's the human factor. When software runs on old technologies, it will become progressively harder for new developers to understand. There will consequently often be a steady decline in available talent. For these reasons, even if the requirements of a piece of software never change, it will always require ongoing maintenance to keep it running, much like a piece of physical infrastructure. (edit: typo)

ebcode 4y ago
> All software contains bugs, unexpected failure modes, and undiscovered security vulnerabilities. I am convinced that there are essentially zero exceptions to these claims. /bin/true (humbly submitted as a non-zero exception to those claims)
jongjong 4y ago
If performance requirements change, then that would count as a change of requirements in my books. It should be possible to decide ahead what an acceptable target is. Also, it's not going to affect every part of the software. About changes in tech and environments. It's possible to build portable software. Whether or not software needs to be portable should be treated as a requirement. I disagree with any argument which suggests that it's not possible to foresee this. It's not always the case that old technologies are harder to understand. This is mostly because software is still a relatively new area in the grand scheme of things. There are some old projects which I find easier to understand. Especially those built with languages which stood the test of time like C/C++, Java, Python, JavaScript...
- closeparen 4y ago
  Requirements aren't from God. They're just a tool for facilitating transactions with contractors. Whatever the software does or is used for, can almost always be optimized further.
  - jongjong 4y ago
    My approach to software development is that the stakeholder is my God and their Requirements are my Commandments.
    - closeparen 4y ago
      Yes and that’s historically a popular way of organizing software development, particularly in enterprise IT. In the more forward-looking parts of the tech world, we tend to see software teams charged directly with the success of their software in the world. Engineers are expected to both come up with and deliver on software changes that advance business goals. Stakeholders participate in shaping and prioritizing, but ultimately you are there to solve their problems, not build to their specs. IMO a better system!

ebcode 4y ago

> All software contains bugs, unexpected failure modes, and undiscovered security vulnerabilities. I am convinced that there are essentially zero exceptions to these claims. /bin/true (humbly submitted as a non-zero exception to those claims)

jongjong 4y ago

If performance requirements change, then that would count as a change of requirements in my books. It should be possible to decide ahead what an acceptable target is. Also, it's not going to affect every part of the software. About changes in tech and environments. It's possible to build portable software. Whether or not software needs to be portable should be treated as a requirement. I disagree with any argument which suggests that it's not possible to foresee this. It's not always the case that old technologies are harder to understand. This is mostly because software is still a relatively new area in the grand scheme of things. There are some old projects which I find easier to understand. Especially those built with languages which stood the test of time like C/C++, Java, Python, JavaScript...

closeparen 4y ago
Requirements aren't from God. They're just a tool for facilitating transactions with contractors. Whatever the software does or is used for, can almost always be optimized further.
- jongjong 4y ago
  My approach to software development is that the stakeholder is my God and their Requirements are my Commandments.
  - closeparen 4y ago
    Yes and that’s historically a popular way of organizing software development, particularly in enterprise IT. In the more forward-looking parts of the tech world, we tend to see software teams charged directly with the success of their software in the world. Engineers are expected to both come up with and deliver on software changes that advance business goals. Stakeholders participate in shaping and prioritizing, but ultimately you are there to solve their problems, not build to their specs. IMO a better system!