There is a whole industry of people who are in the business of telling programmers what to do but not how to successfully complete a project because they do not know anything about how to actually finish the things they tell people to start. "Just use agile everything will be OK!"
Requirements volatility is the core problem of software engineering
61–70 of 251 posts
Re: Requirements volatility is the core problem of software engineering
#62It is funny to compare that to traditional product design. Let's say your goal is to design a chair. The most important tools in your toolbox are variants and iterations. The worst you could do as a designer is constantly working on one (final) chair. Because every change that goes aginst the initial concept will have you saw pieces away and glue them to other spots till you end up with a completely irrational whole.…
But chairs are made in large runs, 99% of the work is in the factory. So everyone understands that the work of making a prototype is a different thing to the final product. A better engineering example needs to be completely one-off, like building a movie set, a stadium, or maybe an airport. These also have endless problems with the requirements changing during design & construction.
You are right, movie sets are a way better analogy. Things on movie sets only work if all people involved adopt nearly military discipline, if you talk to people within the industry they always prepare for the worst and still try to do so on budget.
As somebody who worked as a freelance DOP as well, I think the software world could learn a lot by looking into other areas, especially when it comes to how requirements, changes in said requirements and the impact of these changes on the whole are communicated. IMO one of the most important abilities of an professional regardless of field is to be able to estimate how long something might take and how much work it might be. And this means also beeing able to say how much impact a change in requirements would have on the quality and deadline for the final product.
I know from experience that this estimation is harder in software than in nearly any other field, because problems that look simple on first glance might turn out to be nearly unsolvable, while other problems that look hard might have fairly straightforward solutions — and without putting time into it, it might be hard to tell beforehand.
Re: Requirements volatility is the core problem of software engineering
#63Developers who believe they can forsee the future are more dangerous than missing business requirements. The problem with missing business requirements are that developers often are either to focused on writing the code instead of actually understanding the business. You cannot build something you do not understand. Understand small and expand your understanding. Code is not the goal, it never is. It's a means to a g…
Nicely put. In my nearly three decades of software development, the most successful of my various colleagues have been the ones motivated by understanding the problem and its wider context, rather than the tech/process/language _de jour_.
This is a multiplier because it allows them to detect and ignore non-problems and work on problems whose solutions _will_ deliver value.
Re: Requirements volatility is the core problem of software engineering
#64I 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?".
Also a civil engineer usually understands exactly what the bridge is supposed to do and how it is going to be used.
In a large corporation, the software engineer expects to be told that there are going to be cars on this bridge, and they are moving at a certain speed from one side to the other and that they will be of a weight between x and y, etc...
Understanding the domain goes a long way to get software done.
Re: Requirements volatility is the core problem of software engineering
#65I 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?".
As someone who has worked in both worlds, it is just a different sort of nonsense that you have to deal with. Typically the physical engineering thing is "we want you to work out why this weird thing is happening, then fix it, without us having to change anything operationally or spend any money." just a different flavor of the same crap.
Re: Requirements volatility is the core problem of software engineering
#66Earlier quoted context omitted.
I often hear people use that logic as a reason why software doesn't qualify as engineering
Do you share the opinion that software doesn’t qualify as engineering? I’ve always thought it is a little bit of a stretch.
Real engineers in north America must write technical and ethical exams, have at least 4 years of continuous and proved experience before they can call themselves engineers.
Is indeed sad that people with no knowledge of thermodynamics or strength of materials can call themselves engineers as well...
Re: Requirements volatility is the core problem of software engineering
#67I 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?".
At the new Berlin airport they decided after beginning construction that the airport should have two floors. It’s still not finished.
Re: Requirements volatility is the core problem of software engineering
#68I 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?".
> We don't know exactly what weight it should support yet
Or where it should be exactly: "It should be easy to move once it is build, right?"
Or what type of vehicles it should handle: "Just build a generic bridge. How difficult can it be."
But the time and monetary budget was already negotiated and written in stone: "Oh btw, you got 2 weeks and $537.25 to finish the bridge."
Re: Requirements volatility is the core problem of software engineering
#69The 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…
We had some good requirements people. Really good. They didn't just write things down. There was a lot of examination and analysis and plotting and so on, and they were good at it. They'd all begun their careers as software engineers and gradually specialised into being really good at requirements.
I think having all reqs upfront is a utopia that will not happen.
What can I say? It happened to me. Only with one company in seven or so worked for so far. I would not be surprised if people worked two dozen jobs and never experienced it.
You do need high-quality customers, though, and they are hard to come by. I've worked for a company that has turned down customers on the grounds that the potential customer just isn't good enough; they worded it differently, but that's what it was.
Re: Requirements volatility is the core problem of software engineering
#70I 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?".
And no civil engineer will ever have to deal with the update to Gravity 2.0 now even better at 10m/s2