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

A hierarchy of software engineering discourse

uvwx.github.io

Post reply on HN
Print view View original

51–54 of 54 posts

Re: A hierarchy of software engineering discourse

#51

Post by skybrian »

"Requirements" is an often-misleading word. The danger is putting the customers on a pedestal while at the same time not really listening or understanding.

Supposed "requirements" are sometimes merely design preferences. Customers will often trade them for other things they want more (time to delivery, higher priority features, alternative implementations) if given a chance. Unless you have a good relationship with the customer so you can negotiate these tradeoffs, you may build something that meets requirements but isn't what they really want.

Re: A hierarchy of software engineering discourse

#53

Post by solotronics »

Ididntdothis wrote: post #5
jrochkind1 wrote: post #3

> I wonder if it would actually be better for software teams to build not the thing they want, but rather the thing that makes the thing they want. Sounds so appealing to programmers, so much harder than it sounds. A dangerous fantasy many ships have broke upon. The proposals of "yagni" and the "mvp" are in some sense a reaction to the danger. On the other hand, when it works, it works. I'd say Rails is an example.

Usually you have to first build the thing you want and then you can build the thing that will build what you want. You can’t go straight to the second. You need the experience of having built the thing.

Interesting, I keep building very similar patterns of automation in my systems management programs. Recently have started to think about what it would look like to make a generalized control software for the systems I interact with, to make the automation more uniform. I think this is probably what led to the teams that made ansible or saltstack.
Post reply on HN