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

31–40 of 251 posts

Re: Requirements volatility is the core problem of software engineering

#31

Post by artsyca »

29athrowaway wrote: post #26
artsyca wrote: post #10

Earlier quoted context omitted.

That's when done in a factory feature farm where you've already sold your control for the safety of a steady paycheck Try selling a really agile methodology to a client of your own before you jump on the turnip truck When done properly it gives the client immediate results with little up front commitment or risk and gives you all the control you could want as long as you don't mind being untethered from the communal…

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.

You sound like me a couple of years ago until I realized I was the problem the whole while

Why was I contributing to this madness when I knew better?

So I took the show directly to the client and never looked back

I'd love to elaborate but it sounds like you have a journey ahead of you before you can appreciate what I have to say

Re: Requirements volatility is the core problem of software engineering

#32

Post by cjfd »

bryanrasmussen wrote: post #29
cjfd wrote: post #18

Earlier quoted context omitted.

No, they do not come from the software engineers. It is like being a DJ who is taking requests. You are not playing music for yourself but for other people. It the DJs task to make them sound good. On the other hand, one sometimes also needs to clarify what is wanted because the customers will ask for a rock song with a slight edge of metal in it and as the DJ you will need to know what song fits that description.

It seems that when I say that requirements seldomly come from the software engineers you have somehow misunderstood me as meaning that requirements do come from the software engineers?

No, it is just that your post sounded to me like you were saying that it is a problem that the requirements are not coming from the software engineers. My post attempts to say that this is not a problem and that it actually is how it should be.

Re: Requirements volatility is the core problem of software engineering

#34

Post by StreakyCobra »

fouc wrote: post #2

Greg Young described a good way to deal with requirements volatility: optimize from the beginning to be able to delete your code, and structure your code so that any part of it is no bigger than 1 week's worth of coding. So that any part can be re-written in 1 week. https://vimeo.com/108441214

That was an insightful talk, thanks for sharing!

Re: Requirements volatility is the core problem of software engineering

#35

Post by mhotchen »

29athrowaway wrote: post #26
artsyca wrote: post #10

Earlier quoted context omitted.

That's when done in a factory feature farm where you've already sold your control for the safety of a steady paycheck Try selling a really agile methodology to a client of your own before you jump on the turnip truck When done properly it gives the client immediate results with little up front commitment or risk and gives you all the control you could want as long as you don't mind being untethered from the communal…

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 regularly make suggestions that are listened to and I get feedback on my work several times a week. The changes I make are released to users rapidly and regularly and we gain insight from that to make our next decisions.

I also openly discuss the compromises I make in terms of technical debt and I'm given the freedom to clean it up when it makes sense for the business.

The business would not be able to innovate as quickly if it weren't for agile. I would be less empowered and performing suboptimal work if it weren't for agile.

Tech debt "just get it done" style management with egos too sensitive for candid feedback will always exist and the way the work is defined will have little effect. It's unfortunate that you work for such managers, but please don't blame it on agile.

Re: Requirements volatility is the core problem of software engineering

#37

Post by notduncansmith »

asplake wrote: post #3

> Requirements change. Every software engineering project will face this hard problem at some point. > There is really only one answer to this: you need to find a way to match the requirements-development-delivery cycle to the rate at which the requirements change. Honestly, I believe that much of the problem is with the word “requirements” and I so wish we could kill this use of the word. Bottom line, for systems bu…

This absolutely. As understanding evolves, requirements evolve. Some domains are well-understood enough that this process can be done up-front a-la waterfall, but more often these domains are so dynamical that the only way to understand them is incrementally, one dynamic (or metadynamic) at a time.

Re: Requirements volatility is the core problem of software engineering

#38

Post by hliyan »

nineteen999 wrote: post #27
corporateslave5 wrote: post #15

Earlier quoted context omitted.

No agile is just micromanagement. Control every task the developer works on, make them report status on a daily basis.

Ask 10 different developers, Agile salesmen, and product owners and you'll get 10 different explanations of what Agile is. Occasionally you'll come across somebody with a healthy dose of skepticism. https://news.ycombinator.com/item?id=5406384

I think a lot of people are conflating Agility with SCRUM. If you look at the official SCRUM guide, you'll find ZERO references to agility. And if you look at the original Agile Manifesto, you'll find ZERO references to stories, sprints, story points, velocity, standups or any other thing that we consider agile.

For me, the essence of agility is: break down large projects into smaller and smaller projects until the "mini-project" becomes simple enough for you to execute. But each such mini-project must delivery something that works. Also, don't show documents about the software, show the software.

Re: Requirements volatility is the core problem of software engineering

#40

Post by EliRivers »

The 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 be built if you know before you start what it's meant to do, and that doesn't change, is astounding. Truly astounding.

Post reply on HN