Requirements volatility is the core problem of software engineering • Hacker News Board

Re: Requirements volatility is the core problem of software engineering

#221

Post by artsyca » Sun, Feb 23, 2020, 12:54 AM UTC

mhotchen wrote: post #35

29athrowaway wrote: post #26

Earlier quoted context omitted.

What comes first, feature creep or agile? I would say that agile has helped create the conditions for the proliferation of tech debt mills, because it empowers product people while disempowering engineers. "Rapid and flexible response to change" is really just bruteforcing ideas leaving a trail of tech debt that makes developers miserable.

This has less to do with agile and more to do with the company culture, processes, and probably the people involved. Agile isn't a cure to these problems, it's a tool used by people who "get it" to communicate effectively and to empower everyone to do their jobs. Thanks to agile I am directly involved in evolving the product I work on and providing information back to the product owner and anyone else involved. I reg…

And the way engineering culture contributes to this toxic ecosystem is by perpetrating the myth of casual professionalism thereby selling ownership by avoiding responsibility and taking perks over substance in the bargain

Re: Requirements volatility is the core problem of software engineering

#222

Post by nradov » Sun, Feb 23, 2020, 1:06 AM UTC

louwrentius wrote: post #78

clarry wrote: post #72

Earlier quoted context omitted.

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

Goddamn, this is exactly the sentiment I have about software development. Because it's not about bridges or tunnels, common sense is thrown out of the window, people start building something they conjure out of thin air. Few people say 'No!', we don't do anything. Anything. Until we have written a clear business case / usecase, a raison d'être for this project. Agile is often abused to not think, not design and just…

Santa Claus isn't going to fly down your chimney and deliver a fully formed business case. Developers share responsibility with other roles for figuring it out. Sometimes it takes multiple iterations of exploration and experimentation. Expecting to be told what to do is just lazy and unprofessional.

Re: Requirements volatility is the core problem of software engineering

#223

Post by nradov » Sun, Feb 23, 2020, 1:09 AM UTC

markus_zhang wrote: post #92

clarry wrote: post #72

Earlier quoted context omitted.

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

Manager and Director are the people who are pushing "agile". They want quick results, and SE can only do what they want. You simply really can't "gather" requirement and finish a feature and do proper testing in a 2-week sprint. I do agree there are a lot of bad practices in SE as well, but let's not blame everything on them.

It is completely possible to deliver a user story within a 2 week sprint provided that the acceptance criteria are reasonably clear. Many agile teams so this successfully.

Features (or epics or whatever) are larger and contain multiple user stories. In most cases features extend over multiple sprints.

Re: Requirements volatility is the core problem of software engineering

#224

Post by tracerbulletx » Sun, Feb 23, 2020, 1:16 AM UTC

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?".

Also, physical engineering is constrained by a set of available materials, technologies, and physics. In software you could build a pretty accurate simulation of an entire bridge, generalize it so that it can represent all possible bridges, model new materials, and rewrite the rules of physics, the complexity space is infinite.

Re: Requirements volatility is the core problem of software engineering

#225

Post by atoav » Sun, Feb 23, 2020, 1:44 AM UTC

BlueTemplar wrote: post #125

atoav wrote: post #62

Earlier quoted context omitted.

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?

I work as a freelancer mostly in film postproduction and there are a lot of times when I have take a wild guess on how long it is going to take. It helps to mentally outline all tasks involved and just take a pessimistic guess on how long each of those will take you. Then just sum them and round up to a full day.

If the topic at hand is really something completely foreign to you, be honest about it and tell them the time in which you will get it done for sure. If they don't agree to it, you wouldn't have made them happy anyways.

However: if you are not just a hobby developer, knowing at least roughly how long things take is key — you have to live from it after all: if you earn 1k for a job that takes you two months you cannot pay your rent. And even if you just do it as a side job, being able to give estimates still helps you to use your time wisely.

I don't think an dev without experience is expected to be able to do that. But a professional who has to live of their profession certainly should, if they want to survive.

Re: Requirements volatility is the core problem of software engineering

#226

Post by atoav » Sun, Feb 23, 2020, 1:57 AM UTC

steve_g wrote: post #84

taurath wrote: post #7

Earlier quoted context omitted.

> Also software (like graphic design) is a field where people without any skill tend to have strong opinions about how things should look or work Business too. You do not have to be a good strategist to “succeed” as a VP in a medium or larger sized organization. In fact, you can be downright terrible.

But when you're writing business software to solve business problems, many more people have a "right" to an opinion. Usually the business people know a lot more about the problem domain than the programmer. They are also the ones who will use the solution. I've been thinking that this is one of the key differences between software and bridges. When you design a bridge, very few people have a "right" to an opinion on…

Agreed, if it is their profession they know it better. The thing I was initially refering to is stuff like people who do a horrible layout in word and ask to to literally do the same thing without having any qualification on the matter. Or people who want you to put a whole page of text nobody will ever be able to read onto a roadside sign.

This feels like if one would ask a electrician to use wires without insulation because they like them better — you can totally have your taste, but some stuff is just plain stupid and won't work as intended.

Graphics e.g. is about communicating certain things, and a graphic designers job is to be aware of what this communication does and how effective it does it. And so just like with a bridge (but arguably less dangerous) there can be design that does the job and design that does the polar oposite of what your customer intended.

Re: Requirements volatility is the core problem of software engineering

#227

Post by swat535 » Sun, Feb 23, 2020, 2:10 AM UTC

rossdavidh wrote: post #108

I 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 so…

> the only way to really discover the requirements is to build the thing.

I totally get what you're saying here and in an ideal world, this would be it.

Unfortunately, we don't live in that world, projects have budgets and need to be delivered within a given interval.

They touch other aspects of the business and are interlinked with marketing, support, legal, financing and so on.

I think it's our job as software engineers to figure out the requirements. One issue we have in our industry is that we do a sub par job of educating people regarding how software works and giving them alternatives instead of binary yes/no answers.

I would say most developers (and I'm generalizing here) lack the communication/social skills to do so.

The key here is to strike a balance between features, budgets and deliverables.

Re: Requirements volatility is the core problem of software engineering

#228

Post by [deleted] » Sun, Feb 23, 2020, 5:01 AM UTC

clarry wrote: post #87

bmn__ wrote: post #86

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

[deleted]

Re: Requirements volatility is the core problem of software engineering

#229

Post by funnybeam » Sun, Feb 23, 2020, 7:28 AM UTC

__blockcipher__ wrote: post #185

tigerlily wrote: post #180

Earlier quoted context omitted.

Then it must be "big old brown cardboard fridge box".

Incidentally that’s exactly how I would have worded the sentence as a native speaker. But only because “big ol’” is a common phrase by itself

To me, also a native speaker (UK if it makes a difference), “big old” implies size alone(fairly large) rather than age, while “old big” would definitely mean old and large

Re: Requirements volatility is the core problem of software engineering

#230

Post by Glawen » Sun, Feb 23, 2020, 9:08 AM UTC

Dahoon wrote: post #193

austincheney wrote: post #121

Earlier quoted context omitted.

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

>One difference is that a license is required to practice civil engineering The world would be a better place if developers (or the company they work for) were as much on the hook for bugs in software as en engineer is for a bug in a bridge. How programming can still be the wild west in 2020 is beyond me. I've read some good thoughts about this topic by Poul-Henning Kamp (Varnish, FreeBSD) but can't seem to find it a…

It is the case for safety critical software (aircraft, factory, automotive, train etc...). Development of these software is very long and costly