Lessons Learned from Software Rewrites

Re:Lessons Learned from Software Rewrites by sanderjd on Monday September 05, 2016 @10:29AM (#12430504)

This matches my experience. I used to somewhat blame the business folks for being too lazy and/or pompous to bother with their side of the bargain, but I've come to think it's just generally a solution to the wrong problem. The hard part is correctly translating from what is asked for to what is implemented, and executable requirements don't have anything to say about that step. In cucumber, I can take any arbitrary Given / When / Then statement and implement it in any way, including ways that are completely wrong and (worse) ways that are subtly wrong. The translation code just becomes yet more code that may or may not be correct, and in my experience, it can be a lot of code. When you find yourself wanting to write unit tests for your acceptance test pseudo-english translation layer code, you're deep in a rabbit hole.

[ Parent | on HN ]

Re:Lessons Learned from Software Rewrites by auvrw on Monday September 05, 2016 @10:48AM (#12430589)

i think this (the parent post) is truth: i've had conversations a/b behavior specification where edge cases simply aren't taken into account. so the specification would say, for example

"it does this when anyone clicks a button."

whereas there's often some implicit question, like

"what happens when two people click the button at the same time?"

and that kind of concern -- where the logical implications of requirements -- is not always handled by top-down requirements management... i'm almost certain i saw a fowler article on "conversational" requirements management recently, and that made a lot of sense.

[ Parent | on HN ]

Re:Lessons Learned from Software Rewrites by blowski on Monday September 05, 2016 @11:24AM (#12430782)

In general, BAs should not be writing the stories, but they should be able to read them together with the developers.

I find that it helps, but it doesn't solve the whole problem. The most useful bit is the stories with examples, as those are what are so often missing from specs.

The problem with edge cases is that they are infinite. If there's an edge case that's likely to happen (ideally based on evidence of past behaviour), then it can either be in the spec or just in functional tests.

I like to think that BDD is like writing the documentation first. Would you put the edge case in the documentation? If not, it probably isn't the BA's responsibility to decide what should happen, and it shouldn't have a Gherkin-style story.

But it's not a silver bullet. It's a tool that helps solve some problems on some projects in some teams. Usually, it helps in cases where the domain experts are not very technical and where the domain problem is a fairly simple set of business rules.

[ Parent | on HN ]