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

211–220 of 251 posts

Re: Requirements volatility is the core problem of software engineering

#211

Post by artsyca »

29athrowaway wrote: post #183
artsyca wrote: post #31

Earlier quoted context omitted.

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

What you describe makes me think that you pivoted from an engineering role into a product role in order to make agile to work for you. This only reaffirms what I said, because if agile really empowered you as an engineer that transition would not have happened.

No. I went directly to the client and sold them on the idea of iterative process from first principles

The difference is that the emphasis is on knowledge creation and relationship building

Believe me that there is a way to do the right thing by everyone but most people set themselves up for failure at the outset

It's both way simpler and much more complex than most people can truly appreciate

Re: Requirements volatility is the core problem of software engineering

#212

Post by closeparen »

ctdonath wrote: post #83

The key difference between software vs all other engineering: building it is instant & free & repeatable, vs expensive & slow & singleton. If bridges could be replaced in minutes for pennies, we’d build them iteratively too.

Exactly. Design is code, construction is compilation.

Re: Requirements volatility is the core problem of software engineering

#213

Post by closeparen »

crgwbr wrote: post #150
mrdoops wrote: post #148

This, along with the cost of development, is why I have a pet-peeve for hard-coded business logic directly in the code (in most cases). I.e. when a frequently changing business process like a finite state machine for an approval procedure is only change-able by a developer that means there's always the cost of that developer's "need-to-know" for a straight forward change in the business operations. The cost of a give…

> This, along with the cost of development, is why I have a pet-peeve for hard-coded business logic directly in the code (in most cases). I’ve built systems both ways. Requiring a developer to make changes definitely has costs, but it does have benefits as well. Systems configured in data rather than code will almost invariably be untested and prone to configuration bugs. Overall, I’ve spent probably double or triple…

One cool trick here is to use a restricted subset of a programming language as your rules configuration format. That way it still feels accessible to stakeholders, but you also have access to the other software development paraphernalia (tests, static analysis, version control, etc) if you want it.

Re: Requirements volatility is the core problem of software engineering

#214

Post by artsyca »

29athrowaway wrote: post #183
artsyca wrote: post #31

Earlier quoted context omitted.

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

What you describe makes me think that you pivoted from an engineering role into a product role in order to make agile to work for you. This only reaffirms what I said, because if agile really empowered you as an engineer that transition would not have happened.

By the way the word pivot is largely misunderstood

It means to change the approach while maintaining the vision and values

My values have always been on teamwork and knowledge creation and I pivoted in the sense of changing the approach but not in the sense of changing the vision

Re: Requirements volatility is the core problem of software engineering

#215

Post by tempodox »

legulere wrote: post #67
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?".

At the new Berlin airport they decided after beginning construction that the airport should have two floors. It’s still not finished.

If the people responsible had to pay with their own money, they would have thought twice about that. It's so much easier to burn taxpayer's money.

Re: Requirements volatility is the core problem of software engineering

#216

Post by 32gbsd »

32gbsd wrote: post #61

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!"

Oh and lets not forget the project managers themselves that blame the client/users instead of their own inability to meet the requirements; http://owensoft.net/v4/item/2368/

Re: Requirements volatility is the core problem of software engineering

#217

Post by dkoston »

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…

This was essentially the story of how we built a successful software company at cPanel. Our customers would describe things like “I want a button that does this” or “a script that does that” and we had to make many assumptions about what they really wanted. Finally after determine we were spending massive amounts of time on unused features, we developed everything as a workable “beta” feature. The ones that we got a ton of praise or complaints on kept getting developed. The ones with silence stayed the same.

This was before heat map software and click tracking which can do a great job of augmenting customer feedback.

The key part that we found out is that if you take this approach, you have to couple it with high quality software support. We hired and trained folks who knew the entirety of our business and tech (Linux, DNS, HTTP, hosting, etc). Our tech support reps were paid much more highly than others in the industry but it gave us more benefits than just being able to support customers when beta software was ship to prod, it also gave us a training ground for future software engineers, QA folks, SysAdmins, and Product Managers.

What I think a lot of people forget is that software is one piece of the puzzle in solving a problem, it’s absolutely not the whole solution. If you design a process based around connecting with customers on a regular basis and having feedback flow throughout your company, you won’t have to “make perfect features”.

I’ve only worked with a small number of companies since that have understood this. Most I’ve worked with have created communication silos and sit in rooms trying to dream up the perfect set of requirements.

Re: Requirements volatility is the core problem of software engineering

#218

Post by nradov »

raiflip wrote: post #202
clarry wrote: post #147

Earlier quoted context omitted.

> Didn't we start by trying to plan ahead? There's a reason we have moved to agile. "Everything was waterfall and then came agile" is myth, but yes, it looks like it's fashionable to no longer try to plan ahead. I'm not convinced the reasons are good, and I'm not convinced the craft of planning ahead was ever perfected to the point that anyone could say it doesn't work. Scrum, XP, Agile all date back to the 90s when…

The binary thinking in this thread strikes me as odd. Is it bad to try and plan everything 6 months ahead of time? Yes. Is it also bad to fly by the seat of your pants and only plan 1 week ahead? Also yes. Instead, why don't we plan out by some intermediate time period. Say, 3, 4 weeks ahead of time. Or whatever time horizon ends up being the most efficient.

Yes there is no single correct planning horizon. The optimal horizon is proportional to requirements stability. At the extreme when requirements flux is extremely high then the best approach can be a Kanban process, planning no more than a day in advance.

Re: Requirements volatility is the core problem of software engineering

#219

Post by nradov »

clarry wrote: post #186
moron4hire wrote: post #161

Earlier quoted context omitted.

We tried all that. Formal requirements gathering, modeling tools, the works. It was the SDLC/Six Sigma/ISO9000/vendor-certs-are-substitutes-for-degrees era of the late-90s/early-2000s. And it also didn't work. Often times, it's very easy to determine the functional requirements: "Process this billing statement", "Spit out that report." The complexity doesn't come from the requirements. It comes from the constraints:…

> The complexity doesn't come from the requirements. It comes from the constraints: "We only use this ancient version of this database", "We didn't tell you at the start that the users expect to interface with this system via email". Those constraints sound like requirements: we require that only this ancient version of this database is used. We require that users can interface with this system via email. Different t…

You're missing the point. In the real world some of those requirements are unknowable on any reasonable cost or schedule basis regardless of your analysis process. From an economic standpoint sometimes the best choice is to accept some uncertainty and get moving.

Re: Requirements volatility is the core problem of software engineering

#220

Post by artsyca »

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…

Yes mostly people are engaged in agile theater and then blaming agile as a concept add to that the whole industry of meddlers middlers and muddlers that has sprung up and it's no wonder most of it has devolved into nothing more than a wholly ineffectual circlejerk to put it mildly

If agile is done in such a way to amplify the voices of invested parties then I'm all for it -- starting with the team

Post reply on HN