Hacker News new | ask | show | jobs
by sverhagen 1198 days ago
Isn't that often the fate of Cucumber(-like) projects: you start with the promise of high abstractions that the whole company can work with or reason about, you invest a bunch of time to bridge the gap to the underlying implementation, then it turns out that those business folks aren't really interested in it, so developers hold the bag, and bridging the abstraction gap becomes a cost with little benefit?
4 comments

The same thing happens with BI platforms. Everyone asks for a tool that business folks can use, developers go through all the effort in creating data integrations, then they turn around and ask the developers to just make the reports they wanted anyways. If that's how it was going to be, there's a lot of simpler solutions than a full blown BI platform...
I have seen this repeated a lot here on HN. Since my industry is at least 10 years behind everyone else we are now getting these directives. Execs/managers say we want to put the tools directly in the hands of the users. The project is going to be failure in that sense though because nothing is oriented to do that. Everything from our change control process to the UI is a blocker. The execs keep shouting "it needs to be simpler!" on a process that's decidedly not simple. I'm not interested in leading a paradigm shift destined to fail from my small underfunded department at a megacorp so I switched projects :/
i think this has been the outcome every time i have seen BDD applied. when the only people maintaining the BDD suite are the developers, the situation can be improved by throwing away the human readable BDD layer and allowing the developers who are maintaining the test suites to use a real programming language with abstractions and composability.

that said, writing acceptance style tests directly in a real programming language with an appropriate layer of test-support library abstractions in that language, customised to whatever component is under test, can often be quite pleasant and productive.

I find that the "gherkin" syntax is not really expressive enough to express requirements in a way that is interesting for the business.

The business therefore always loses interest.

It is great for removing ambiguity, but business executives don't want to think on that level any more than they have to.

It is terrible for simplifying things. Most people really know "I want ta safe self driving car", they don't want to figure out when it is acceptable to hit a kid on the road (think gory video games were people throw babies in front of your car for one case where it would be acceptable).

Disambiguation is precisely what it's not great at, I think. I would often see stories like "Given a logged in user..." and the details of what kind of user it was would be buried in a step definition somewhere.

The restricted nature of the language encouraged this "dumbing down" of the high level requirements to the point where you couldn't really have intelligible conversations about gherkin scenarios without referring to step definitions, so the whole exercise becomes kinda pointless.

If your software scenarios had even slightly complex preconditions/steps then most people would just shove that complexity in a definition and paper over it.

Those should be I don't care about it now - it should work for anyone.

The idea is to get to what is different about this user. Security is important enough that you always want to specify a logged in user, but most details you don't care about and shouldn't ambiguous is good because it says I don't care.

>then it turns out that those business folks aren't really interested in it

It's weird how business folks can just go "nope not doing that" to a process that was created to give them more say and doesn't make sense without them.

I guess they're used to getting their way regardless of whatever language they express it in. After all, "holding the bag"? Developers are certainly holding one kind of bag, but since we're already talking about Cucumber, I don't think that expression necessarily means the same thing to all people.
That would mean they are accountable to something and that is dangerous to both incompetent and lazy people