Earlier quoted context omitted.
We tried it once and the semi-tech SMEs had no desire to write cucumber code so it ended up being the developers who hated writing in a second language. No real benefit.
The ideas behind BDD are sound, but I've never seen it work out in the real world. In reality we as programmers need to turn what the stakeholders want into code. They will talk in meetings: we better take notes. They will write things down [in English or whatever language they speak], but it won't be code. There will be conflicting requirements, and we as programmers need to understand the topic well enough to make…
Cucumber maintainer has been laid off
61–70 of 81 posts
Re: Cucumber maintainer has been laid off
#62Earlier quoted context omitted.
There is also paranoia. A lot of people believe that a laid off employee will immediately go against the company and do some kind of sabotage or leak secrets.
It's not exactly paranoia given there have been many examples of the fear becoming true.
I have worked at a company that had the policy that any time an employee gave notice that they were leaving, the employee immediately had their access credentials revoked and was walked out of the building by security. The justification for this policy was that the employee might decide to sabotage systems if they were leaving.
While I think it is unnecessary in nearly all cases, I can at least understand the reasoning for a policy of immediately cutting access and walking an employee out after that employee has been informed that they are being fired or laid off. But there is NO sense in having the policy for employees who are choosing to leave. The policy of walking employees out immediately was well known. If such an employee HAD wanted to sabotage systems or plant a back-door, they would have done so after deciding to leave but before informing their managers. The policy served no rational purpose.
Re: Cucumber maintainer has been laid off
#63Earlier quoted context omitted.
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).
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.
Re: Cucumber maintainer has been laid off
#64Earlier quoted context omitted.
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?
>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.
Re: Cucumber maintainer has been laid off
#65I have used Cucumber in various projects, but haven't yet had the pleasure of seeing it all work out. - No one wanted to "collaborate", or check a "documentation" based on the Cucumber code . Yes, it's code, it lives in an IDE, in git, and non-technical folks just generally don't deal with that world. No one in my projects ever even brought such an idea up. Non-technical folks looked at our Cucumber code as in "what…
I think BDD has very bad reputation because people associate it with test automation. And it is actually pretty terrible tool to teschnicall describe tests. What BDD is good at, is defining project requirments, it is a thinking tool. Especially if used correctly, with examples and etc. It is a business not engineering tool.
I think BDD has a terrible reputation because people associate it with Cucumber/Gherkin! And honestly, if that's all they've experienced, I understand and sympathize.
On the other hand, people seem happy with RSpec, Jest, Spek, Scalatest, and other spec-style BDD frameworks. Those still nudge people into thinking about testing use instead of implementation, which is the real value in BDD.
Re: Cucumber maintainer has been laid off
#66The American way of firing people with no notice and cutting off their logins instantly is so strange. Is saving a tiny bit of money that much more important than a smooth handover? Or are employees just not willing to work their notice periods? It sounds like in this case it's actively going to hurt the business.
There is also paranoia. A lot of people believe that a laid off employee will immediately go against the company and do some kind of sabotage or leak secrets.
Re: Cucumber maintainer has been laid off
#67Earlier quoted context omitted.
We tried it once and the semi-tech SMEs had no desire to write cucumber code so it ended up being the developers who hated writing in a second language. No real benefit.
The ideas behind BDD are sound, but I've never seen it work out in the real world. In reality we as programmers need to turn what the stakeholders want into code. They will talk in meetings: we better take notes. They will write things down [in English or whatever language they speak], but it won't be code. There will be conflicting requirements, and we as programmers need to understand the topic well enough to make…
E.g. When a front end team says "we need an API to do X" to backend I dash off a couple of draft example API calls and responses and organize a 10 minute meeting where I show the draft to the front end team and back end team (stakeholders).
That discussion we have in the meeting where we 1) talk about what needs to go in the request and response while looking at it and 2) edit the example scenario and 3) finally lock down a version everybody agrees upon is, essentially, BDD in its purest form.
I'm pretty sure a lot of people do this type of thing without even realizing that it's BDD.
(A lot of people also dont do it and the mismatch in expectations only gets realized and negotiated around once there is code ready to deploy. This is an awful waste of time and effort.)
Re: Cucumber maintainer has been laid off
#68Being off the grid for more than 2 days puts you at a disadvantage if you value your Job, let alone taking long esoteric vacations. there are people working non stop to take all you have. If you value anything enough, protect it at all cost.
Re: Cucumber maintainer has been laid off
#69Earlier quoted context omitted.
There is also paranoia. A lot of people believe that a laid off employee will immediately go against the company and do some kind of sabotage or leak secrets.
Remember that you're balancing the odds of it happening against the possible harm it can cause. If it's super unlikely to happen but the effects can be catastrophic, then it may be worth the cost to prevent it from happening.
Re: Cucumber maintainer has been laid off
#70Earlier quoted context omitted.
There is also paranoia. A lot of people believe that a laid off employee will immediately go against the company and do some kind of sabotage or leak secrets.
It's not exactly paranoia given there have been many examples of the fear becoming true.
So my not wanting to leave my home is not exactly agoraphobia.