3 ms·

I honestly chafe a little bit at the "requirements" language. I have very rarely built software that has firm requirements. A better fit for my mental model (wh

I honestly chafe a little bit at the "requirements" language. I have very rarely built software that has firm requirements. A better fit for my mental model (which is the language I find myself using constantly at work) is whether something is "useful" or not, constrained by priorities and trade-offs. "If we spend the time to make it do this useful thing, we won't get to that other useful thing until it is no longer as useful as it would be if we did it earlier" or "that change is not actually useful for xyz reason". This is where the agile / iterative method of designing and building software meshes best with my thinking; instead of enumerating requirements, we're discovering useful tools and functionality and iterating toward the most useful set of tools that we can build within all the rest of our constraints. I don't think this is like The One Way or anything, but it's the only thing that makes sense to me. When I hear about people sitting around writing down big lists of "requirements", it just sounds like guesswork and making stuff up to me. But a bit more on topic: Yeah, I'm optimistic that it will still be a primarily human job to figure out what is useful to build, with AI tools playing a very useful supporting role (just like all sorts of other software tools that came before them).

P_I_Staker 3y ago
> "If we spend the time to make it do this useful thing, we won't get to that other useful thing until it is no longer as useful as it would be if we did it earlier" In a discussion regarding process and requirements this type of analysis doesn't always make sense. The team is obligated to follow the process, because someone has determined it's really important. So that's that then. If you work under process with controls, like in safety critical/security systems, which use "safe" software processes, there may be reasons you are completing this work. Those reasons are often legal, or to reduce blame and liability. They might be anticipating that they will need to supply certain information in the case of a lawsuit, or that they will get in trouble for not having completed all the homework, which includes requirements. Even taking this out of the picture and purely looking at merits, there's a reasons we gather requirements. Without deciding what something does, how will we prove that it accomplishes these goals? How do we know what a product actually does? It can also be really valuable tool from an ethics standpoint. Having requirements makes it harder to sneak content in. It should be impossible to add content without consideration. This is actually a massive issue, with scandals and fingerpointing, that arguably shouldn't be possible, because we all agreed on how this will work. There's also some amount of bias built into time management. People are really bad at judging the "usefulness" of something, especially when it requires them to do something they don't like. Why let the developer of an important system decide what makes sense for them, likely based on their own agenda, instead of demanding they decide how everything works, and then prove it? So we decided you need to do this important thing, you decided you thought it wasn't very "useful", and didn't do it; now someone's dead. How do you explain this? Those decisions you made based on "usefulness" look pretty absurd when you're not following the ISO process, as expected.

P_I_Staker 3y ago

> "If we spend the time to make it do this useful thing, we won't get to that other useful thing until it is no longer as useful as it would be if we did it earlier" In a discussion regarding process and requirements this type of analysis doesn't always make sense. The team is obligated to follow the process, because someone has determined it's really important. So that's that then. If you work under process with controls, like in safety critical/security systems, which use "safe" software processes, there may be reasons you are completing this work. Those reasons are often legal, or to reduce blame and liability. They might be anticipating that they will need to supply certain information in the case of a lawsuit, or that they will get in trouble for not having completed all the homework, which includes requirements. Even taking this out of the picture and purely looking at merits, there's a reasons we gather requirements. Without deciding what something does, how will we prove that it accomplishes these goals? How do we know what a product actually does? It can also be really valuable tool from an ethics standpoint. Having requirements makes it harder to sneak content in. It should be impossible to add content without consideration. This is actually a massive issue, with scandals and fingerpointing, that arguably shouldn't be possible, because we all agreed on how this will work. There's also some amount of bias built into time management. People are really bad at judging the "usefulness" of something, especially when it requires them to do something they don't like. Why let the developer of an important system decide what makes sense for them, likely based on their own agenda, instead of demanding they decide how everything works, and then prove it? So we decided you need to do this important thing, you decided you thought it wasn't very "useful", and didn't do it; now someone's dead. How do you explain this? Those decisions you made based on "usefulness" look pretty absurd when you're not following the ISO process, as expected.