5 ms·

As a software developer with 15 years of experience who produces completed software products, I'm wary of this mindset because it's often used as an excuse to t

As a software developer with 15 years of experience who produces completed software products, I'm wary of this mindset because it's often used as an excuse to tolerate or reward incompetence. Software can be considered done with respect to any given set of requirements. Now if the requirements change, then of course, the software may need to be updated - but even then, it should be designed in such a way that the impact of requirement changes are minimal. Software should, to some extent, anticipate requirement changes. Of course this is not easy, but to claim that it's impossible is to admit defeat. You need highly skilled people making those architectural decisions. Some software is subjected to constantly changing requirements and these can be said to never be done but that's far from being the case for all software. Libraries and modules are software too and these should be generic enough to handle requirement changes without code changes since they should not concern themselves with the business domain. I have completed open source projects which did not need to be updated in years and worked just as well. I've worked on other projects which had to be updated because of vulnerabilities found in dependencies but these did not require any code changes on my end. I consider it a huge red flag if some library was working fine for 5 years and then people decided to change its interface in a non-trivial way. I was tolerant when async/await was rolled out to major programming languages; this affected and continues to affect dependencies but it's a meaningful conceptual improvement and helps with future maintainability. I hope that programming standards organizations will slow down after that in terms of changes which affect function interfaces because these decisions have huge flow-on impacts. It's totally possible to produce completed software (especially libraries and frameworks) but the industry has to aim for it and expect it. The current goal of industry seems to be job creation, not the creation of robust working products. Accepting that software can never be done right from the beginning is going to be a disaster. It should only be tolerated in the context of requirement changes.

jasonhansel 4y ago
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!
Gigachad 4y ago
For every program I have ever worked on, the "finished state" is when the tool reads your brain, does all the work for you, and transfers the resulting dollars in to your bank account. Until then, we always have work to do that brings us closer. Imagine Photoshop, they continually add new tools which let you get the intended results with less manual work. The end state of photoshop is you just open the file and it immediately shows you the finished picture you wanted without having to do anything. We are decades away from that.
barbariangrunge 4y ago
What if a requirement is “system is secure from cyber attackers”? I had a discussion the other day about how to tell when a web service can really be considered secure enough for somebody important to store sensitive data on (Eg, medical software); when do you say “the requirement has been met”? Does it become un-met next week when a new exploit is discovered in a package you rely on?

jasonhansel 4y ago

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!

Gigachad 4y ago

For every program I have ever worked on, the "finished state" is when the tool reads your brain, does all the work for you, and transfers the resulting dollars in to your bank account. Until then, we always have work to do that brings us closer. Imagine Photoshop, they continually add new tools which let you get the intended results with less manual work. The end state of photoshop is you just open the file and it immediately shows you the finished picture you wanted without having to do anything. We are decades away from that.

barbariangrunge 4y ago

What if a requirement is “system is secure from cyber attackers”? I had a discussion the other day about how to tell when a web service can really be considered secure enough for somebody important to store sensitive data on (Eg, medical software); when do you say “the requirement has been met”? Does it become un-met next week when a new exploit is discovered in a package you rely on?