Requirements volatility does not fully explain the frequency with which basic security flaws keep reappearing, long after they have been recognized and documented.
Requirements volatility is the core problem of software engineering
101–110 of 251 posts
Re: Requirements volatility is the core problem of software engineering
#102Earlier quoted context omitted.
> instead of sitting down and figuring out the actual requirements first like any real engineering job If it were so easy, then we would have done it already that way for the last seven decades. The simile topples over upon further contemplation: civil engineers: • client is not a domain expert • to an overwhelming part, client needs are easy to transport into the mind of c.eng. • can employ a wealth of standard solu…
I agree it's not easy, but instead of trying harder to become good at it, it seems like this industry in its proverbial baby shoes threw a tantrum and decided that it doesn't want to learn at all. So instead of pushing for more effort & skill for up-front planning and modelling of the requirements and design (and trying to employ modelling tools & formal methods), we're just like fuckit nah let's just implement somet…
Companies are more than happy to churn through staff, losing millions in accumulated human knowledge, just to keep it out of the hands of employees.
My company just shut down an entire office, they offered three out of four critical employees the opportunity to move to Atlanta. They didn’t want to move, opting to retire instead. Company just shrugged their shoulders rather than letting them work remote, gave them like a month to transfer knowledge and that’s that.
Re: Requirements volatility is the core problem of software engineering
#103I often hear people say that software engineering is a joke compared to civil engineering or other kinds. But they forget that when a civil engineer designs a bridge he doesn't start with: "We don't know exactly what weight it should support yet, but just start building the bridge already". And he doesn't finish with a: "Ah, turns out we wanted a tunnel instead of a bridge, can we change that next sprint?".
> I often hear people say that software engineering is a joke compared to civil engineering ... I think your example points out exactly why some think software engineering is a joke: they rush ass first to implement something (and they implement the wrong thing) instead of sitting down and figuring out the actual requirements first like any real engineering job would have you do. And it looks like everyone is pushing…
Having worked on government projects, agile is definitely better than waterfall. The specs will change, better accept that early on and work with it, instead of trying to nail down the wrong thing.
Re: Requirements volatility is the core problem of software engineering
#104I often hear people say that software engineering is a joke compared to civil engineering or other kinds. But they forget that when a civil engineer designs a bridge he doesn't start with: "We don't know exactly what weight it should support yet, but just start building the bridge already". And he doesn't finish with a: "Ah, turns out we wanted a tunnel instead of a bridge, can we change that next sprint?".
> I often hear people say that software engineering is a joke compared to civil engineering ... I think your example points out exactly why some think software engineering is a joke: they rush ass first to implement something (and they implement the wrong thing) instead of sitting down and figuring out the actual requirements first like any real engineering job would have you do. And it looks like everyone is pushing…
> figuring out the actual requirements first like any real engineering job would have you do
There are no "actual" requirements for most software projects. Software is generally co-evolved with the audience.
Bridge designers can work like they do because bridges are hard to change and fundamentally pretty similar. But because software infinitely changeable and infinitely copyable, our field is different. If you're going to build 500 highway overpass bridges, you'll need engineers looking at each one, because local conditions and needs vary. But in software if we need to serve 500 users, we build one product, give each user a copy, and just keep adding features to solve the local problems.
A big reason we think software can be like bridges is that in the early history of our profession, we were tackling problems that almost worked in a waterfall context. That's because we were taking existing paper processes and automating them. But the hard part of requirements discovery via process coevolution had been done for us by people tinkering with paper and human working relationships.
That era is past. Today if the requirements for something are perfectly knowable, that's because it's either trivial or it's copying an existing piece of software. Any real product is discovering what's possible. It's growing along with its users' needs. It's solving new problems created by other people and groups.
I know of no significant piece of software that, like a bridge, hit 1.0 and just stayed there for a decade while getting plenty of use because the requirements were perfectly foreseen. Not one. To me that's a sign that perfect foreknowledge is, if not impossible, at least incredibly rare. So I think the thing to do is to figure out how to build excellent software with the expectation that needs will change.
Re: Requirements volatility is the core problem of software engineering
#105I often hear people say that software engineering is a joke compared to civil engineering or other kinds. But they forget that when a civil engineer designs a bridge he doesn't start with: "We don't know exactly what weight it should support yet, but just start building the bridge already". And he doesn't finish with a: "Ah, turns out we wanted a tunnel instead of a bridge, can we change that next sprint?".
> I often hear people say that software engineering is a joke compared to civil engineering ... I think your example points out exactly why some think software engineering is a joke: they rush ass first to implement something (and they implement the wrong thing) instead of sitting down and figuring out the actual requirements first like any real engineering job would have you do. And it looks like everyone is pushing…
The problem is that you cannot figure out the actual requirements. In every non-trivial application project I had so far, the requirements (and there were lots of them) were simply not correct. The requirements the actual users created, that is. They _think_ they know the workflow. They don’t.
If you don’t even ask the users, it’s even worse.
But that’s okay. It is simply not possible to accurately judge how something will work until you get to use it. That goes for the creators, too. That’s why we iterate.
Re: Requirements volatility is the core problem of software engineering
#106"Requirements volatility" is just another word for: A/B testing software :). Let's get used to it
Re: Requirements volatility is the core problem of software engineering
#107The only software project I ever worked on in which the customer didn't report so much as a single bug had the requirements done properly, up front, and agreed all round. Of the thousands of identified requirements, I think less than ten changed over the lifetime of the project, and each change underwent significant examination for consequences. The project was waterfall all the way. The quality of software that can…
I have worked on huge government projects that has been specced and planned for years before arriving at my team's desks. It takes a few days before we will have questions. Things not defined good enough, inconsistencies, glaring holes etc. I think having all reqs upfront is a utopia that will not happen. Those projects I was involved in would have been better if the reqs and scope was done in conjunction with us imp…
The fact that you immediately had questions of the requirements means they were not properly thought out and/or not well-defined (regardless of how many years they spent in the planning/gathering stage). Both of those (well defined, thought-out requirements), along with reasonable people evaluating them, would have yielded a much better outcome overall.
Just like spaghetti programming, you get spaghetti requirements analysis & process-engineering. And even then, they hardly consider some of the things that developers do.
Almost as if the developers that encode the rules in a "hard format" such as a program/system need to be the ones dictating the processes/requirements. I would definitely see that as separate to "reqs and scope done in conjunction with devs developing them".
Re: Requirements volatility is the core problem of software engineering
#108I am reminded of how linguists, when trying to document a language from one of the last living native speakers, don't just ask them to tell them the rules of it. They have to task questions like "how would you say this?" Then they try to reverse-engineer the grammar, syntax, etc.
In most cases, the people who are giving the requirements either: 1) don't actually know them (e.g. they are in upper management but the software will be used by line workers) 2) have internalized the details of the process so long ago that they are essentially subconscious now. They would tell you the real requirements if they could, but they just can't, they will instead tell you what they think the requirements are. Then, once you build it and they try to use it, like the native speaker of a language hearing you speak a sentence in it using the grammar rules they just told you, they will immediately know that it's wrong.
So, the best way to find the _real_ requirements for the software, is to build the software, and have them try to use it. Stop planning and endlessly documenting someone's fantasy or best guess at what the requirements are; the only way to really discover the requirements is to build the thing.
Re: Requirements volatility is the core problem of software engineering
#109I often hear people say that software engineering is a joke compared to civil engineering or other kinds. But they forget that when a civil engineer designs a bridge he doesn't start with: "We don't know exactly what weight it should support yet, but just start building the bridge already". And he doesn't finish with a: "Ah, turns out we wanted a tunnel instead of a bridge, can we change that next sprint?".
I think there is more to it than process. I'm not an engineer, but I know in the US you usually have to pass the PE exam to be a real certified engineer, plus there is the reality that if your bridge collapses, you are liable, might go to jail, etc. I'm unaware of any similar licensing process in software engineering or liability realities. Even when software kills people, it is usually not prosecuted and the devs ar…
Indeed. Especially since design choices might have real world consequences.
Re: Requirements volatility is the core problem of software engineering
#110It’s not a problem of software engineering, it’s a property of software engineering.
Yes, that is very true. If changing and complex requirements are a problem, you are doing it wrong. This is the main reason why code quality must be as high as possible. It is the best chance there is to be able to accommodate new and changing requirements in a reasonable time frame. It is also the reason why automated tests are a necessity. Otherwise it is way to easy to satisfy one requirement while not noticing th…
Focusing too much on code quality can backfire handling changing requirements at the same time.
Many times I had a clean elegant abstraction break with a change in requirements.