"Clarity in thinking is far easier to achieve with language rather than code." This is stated as though it is a universal truth. It is definitely not. Language in general can be far more imprecise...
"Clarity in thinking is far easier to achieve with language rather than code."
This is stated as though it is a universal truth. It is definitely not. Language in general can be far more imprecise than code. Which is a big part of the reason that we still code. Frankly, Capybara is also abstracted towards natural language quite significantly, so arguing for Cucumber over Capybara is a pretty silly hill to die on. If you do want to achieve clarity in thinking, keeping your code complexity low is a huge step towards achieving that, and both of these require an addition of complexity to your codebase in order to get that perceived clarity. The reality is you are just shifting complexity from a non-technical PM to the devs, not actually reducing it.
Honestly, the idea that a "business expert/product owner" or "non technical stakeholder" even has a reason to be parsing through test cases so closely is likely a flawed assumption in the first place. Your developers should be trustworthy enough to translate product requirements in to coded test cases without such heavy handed oversight. If they aren't, you should be having senior devs review their work, not non-technical managers.
I agree about language. The author seems to have made a big large substantial great mighty significant grand hefty giant major mistake regarding precision of computer languages - each instruction...
I agree about language. The author seems to have made a biglargesubstantialgreatmightysignificantgrandheftygiantmajor mistake regarding precision of computer languages - each instruction is comparatively unambiguous compared to natural language and even then context makes it so difficult to reason about code.
Agreed; I think the idea is that they can audit the work being done. This comes up during consulting and contracting where the client says "I want X, Y, Z" and it's up to the developer to show...
Honestly, the idea that a "business expert/product owner" or "non technical stakeholder" even has a reason to be parsing through test cases so closely is likely a flawed assumption in the first place
Agreed; I think the idea is that they can audit the work being done. This comes up during consulting and contracting where the client says "I want X, Y, Z" and it's up to the developer to show that it's been done. If you're working at that high level of abstraction with lots of implicit assumptions, the test case can remain the same and then additional assumptions can be baked in with the client/non-technical stakeholder being able to take a look.
Then again, you can always just not work for micro-managers.
The reality is you are just shifting complexity from a non-technical PM to the devs, not actually reducing it.
That's the reality when you're contracting; client doesn't know anything about Wordpress, PHP or anything else but wants "a beautiful website, with ecommerce and articles, and membership-only pages". Then they want to build custom software and of course they don't know how to do that because off the shelf software configuration is completely different. Cucumber just adds an additional layer of complexity and it's so frequently used incorrectly that it's basically another layer just for developers to understand.
"Clarity in thinking is far easier to achieve with language rather than code."
This is stated as though it is a universal truth. It is definitely not. Language in general can be far more imprecise than code. Which is a big part of the reason that we still code. Frankly, Capybara is also abstracted towards natural language quite significantly, so arguing for Cucumber over Capybara is a pretty silly hill to die on. If you do want to achieve clarity in thinking, keeping your code complexity low is a huge step towards achieving that, and both of these require an addition of complexity to your codebase in order to get that perceived clarity. The reality is you are just shifting complexity from a non-technical PM to the devs, not actually reducing it.
Honestly, the idea that a "business expert/product owner" or "non technical stakeholder" even has a reason to be parsing through test cases so closely is likely a flawed assumption in the first place. Your developers should be trustworthy enough to translate product requirements in to coded test cases without such heavy handed oversight. If they aren't, you should be having senior devs review their work, not non-technical managers.
I agree about language. The author seems to have made a
biglargesubstantialgreatmightysignificantgrandheftygiantmajor mistake regarding precision of computer languages - each instruction is comparatively unambiguous compared to natural language and even then context makes it so difficult to reason about code.Agreed; I think the idea is that they can audit the work being done. This comes up during consulting and contracting where the client says "I want X, Y, Z" and it's up to the developer to show that it's been done. If you're working at that high level of abstraction with lots of implicit assumptions, the test case can remain the same and then additional assumptions can be baked in with the client/non-technical stakeholder being able to take a look.
Then again, you can always just not work for micro-managers.
That's the reality when you're contracting; client doesn't know anything about Wordpress, PHP or anything else but wants "a beautiful website, with ecommerce and articles, and membership-only pages". Then they want to build custom software and of course they don't know how to do that because off the shelf software configuration is completely different. Cucumber just adds an additional layer of complexity and it's so frequently used incorrectly that it's basically another layer just for developers to understand.