Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Requirements volatility is the core problem of software engineering

stackoverflow.blog

Post reply on HN
Print view View original

121–130 of 251 posts

Re: Requirements volatility is the core problem of software engineering

#121

Post by austincheney »

kabes wrote: post #45

I 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 a web developer with 20 years experience I would argue that one web SPA project is more similar to the next than comparing two bridges and developers still can’t figure it out.

One difference is that a license is required to practice civil engineering. Most web developers, on the other hand, require large tools to do theirs jobs for them and recoil in irrational fear and disgust when standard DOM methods are used. I still have people argue with me that the DOM is slow even though all the evidence and browser vendors claim updates to the DOM is simply switching a bit in memory. In other words many web developers have utterly no idea how their platform works.

Another difference is that many developers cannot write. Everything about a bridge is planned in extreme detail before work on the ground ever starts. This level of planning is absent in software. Documentation is also largely absent. In most cases everything is an ad hoc mess. In any other industry this would be a cause of numerous lawsuits.

Another difference is that construction is treated as a business project with a dedicated project manager and project budget. Most business software, on the other hand, is treated as an operation. If you cannot discern the difference between a project (temporary) and an operation (living) your software will never be released as a product to a specified level of quality by a specific date.

Re: Requirements volatility is the core problem of software engineering

#123

Post by mobjack »

I change the requirements of my personal projects all the time.

Once I get a prototype working I get lots of ideas of how to improve things. I also see that some of my initial plans did not work I out as I envisioned and have to iterate on them.

If I can't get the requirements right on my own projects, then I have no expectations that others could do so either.

Have the expectation that requirements are wrong on any project. It is better to embrace that these will change rather than try to fight them.

Re: Requirements volatility is the core problem of software engineering

#124

Post by BlueTemplar »

cjfd wrote: post #14
drenginian wrote: post #11

It’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…

Another way to approach the issue of code quality is to just keep throwing the code away until you start to understand the problem...

Re: Requirements volatility is the core problem of software engineering

#125

Post by BlueTemplar »

atoav wrote: post #62
iguy wrote: post #13

Earlier quoted context omitted.

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,…

My problem with that is that it seems to be expected that even a developer without any experience should somehow be able to do this kind of estimation?

Re: Requirements volatility is the core problem of software engineering

#127

Post by physicles »

If requirements volatility is the core problem, the next question to ask is, Why is this the core problem here and not in other engineering disciplines?

I think it stems from a mismatch between the perceived cost and the actual cost of changing software, which one of the first comments on the article captured:

> That’s my take – the perception that software is simple to change, which stems from the lack of understanding of its inherent complexity by users, and the fact that it is, up to a certain point – is what makes requirements volatile.

Part of the problem too is that the actual cost of changing software varies by an order of magnitude or more, depending on how fluent the developer is with the tools they’re using, and how good they are at accommodating change. If that’s not something even we as a profession (if you can call it that) have been able to reliably quantify, expecting a client to understand it is beyond the pale.

I’ve been programming for most of my life, so if I see an app then most of the time I can get a sense for how long it’d take to build. But I still have this nagging feeling that building software — the act of translating what’s in your head into working code — seems to take way longer than it ought to.

Re: Requirements volatility is the core problem of software engineering

#128

Post by DanielBMarkham »

I don't think most people know what they're doing when it comes to managing the delivery of software. The field is full of canards, facile simplifications, and self-referential, circular reasoning. A few examples.

- The problem is requirements. Is the system broken? Yes. Do the requirements say for it to be this way? Yes. Must be broken requirements, right? Since requirements are the "driver" of the process, if the process is broke so must be something about requirements.

- Software is never done. Bullshit. Do I need somebody to reprogram my decades-old mp3 player? I do not. Would it be nice if somebody did? Maybe, but it's not required for me to enjoy the software. The software is written, does its job, and needs no maintenance. It's done. There's plenty of software being updated today for pretty good reasons that for all intents and purposes is done. Just nobody wants to admit it. If it's possible to add stuff or update it, we do. It's what we do.

- FTA, "...Requirements change. Every software engineering project will face this hard problem at some point..." That's true, but woefully incomplete. Your job creating software is not to meet the requirements, it's not to change and add stuff as the requirements change. That's viewing the work, once again, as requirements-driven. No matter what your process or paperwork, the work is ultimately user-driven, not requirements-driven. Your job is to scope a domain, anticipate change in that domain, and provide easy-to-use configurable software that anticipates that change. You do that by knowing the users and the work, not by reading requirements or responding to updated requirements. That kind of thinking removes the key piece of the entire work, the user. By the time somebody gives you a requirement, it's too late. Your design is whack.

How do we make aviation and space travel gear safe? We fly the hell out of it. What's the wrong way to go? Build one-at-a-time and ask for changes and complete reworks for every new project. How do we build software today? Like we used to build rockets; using the wrong metaphor. We need reusable, configurable, capabilities-driven software, not endlessly worked-on huge hunks of bytes from BigCorp feature factories.

EDIT: Just to clarify the rocket metaphor, we'd be far, far better off using COTS tools and writing minimalist, simple code that only does a few things, then pounding the hell out of it with actual usage to figure out which "axes of change" we missed. Instead, more and more everything has some unique tech stack, a byzantine testing and deployment deployment system, the entire thing fun of tons of complex one-of code everywhere ... then we stick on new features one at a time every time there's something a user wants that it doesn't have. From a managing-complexity and managing-cost standpoint, it's actually worse than the Big Project rocket situation we had for decades.

Re: Requirements volatility is the core problem of software engineering

#129

Post by BlueTemplar »

temac wrote: post #54

Just to nitpick, there are counter examples of finished but not abandoned software. As usual, Tex comes to mind. Or they just could. E.g. we could probably take the current Python 3 and freeze it and debug it for 20 years, at which point it would be basically finished, and maintenance could still continue (but way much less would be needed) IMO a good part of requirement volatility is a self inflicted wound. Some are…

I guess that slowing down doesn't pay well in an industry where a startup can get from zero to billion in a few years?

Re: Requirements volatility is the core problem of software engineering

#130

Post by xorcist »

physicles wrote: post #127

If requirements volatility is the core problem, the next question to ask is, Why is this the core problem here and not in other engineering disciplines? I think it stems from a mismatch between the perceived cost and the actual cost of changing software, which one of the first comments on the article captured: > That’s my take – the perception that software is simple to change, which stems from the lack of understand…

> Why is this the core problem here and not in other engineering disciplines?

Software is the blueprint of a process. Software engineering is basically the art of exact specifications.

Once you've unambiguously specified what it is you want, you're done. The rest is pretty much an appropriate language an a compiler but we have plenty of those.

Post reply on HN