3 ms·

It has pretty much nothing to do with your experience level, your familiarity with the project or the language or tooling. When those things matter, they amplif

by mlthoughts2018 8y ago

It has pretty much nothing to do with your experience level, your familiarity with the project or the language or tooling. When those things matter, they amplify this phenomenon, but the baseline effect is already high. It’s a function of requirements being ambiguous by design. Non-engineering stakeholders have a severe need for requirements and specs to be fungible and ambiguous, such that whether or not the state of the project satisfies requirements is fundamentally not codified in any objective document and no test can reflect useful objective measures of it. Tests can only loosely approximate it and the ways to do so are always shifting and changing and up to a subjective interpretation of some non-technical people. Perhaps the only objective measure that non-tech people will agree to be specific about is financial cost, and even then usually only after it becomes a problem. That’s every project in a product-oriented tech company period, and anyone claiming otherwise is full of it. There can be isolated, tiny pockets of maintenance work or last stages dev work once you pass a point of no return when business people can no longer sustainable lobby for requirements to continue to be ambiguous and fungible, and finally you can start proving things with accurately scoped tests, but it’s so late in the game that the idea you could do something like TDD at that point is comical. Instead, becoming a good product-oriented developer means in part learning how to write well factored tests on the fly at the same time you are writing the code to be tested, and keeping testing code clean and set up with fixtures and set up to run in highly automated ways, so that when you’re inevitably ripping stuff out of the implementation for the 18th time due to yet another priority pivot from sales, you can nimbly also update the tests as you go.

l0b0 8y ago
I'm sorry you're going to feel I'm full of it, but I've seen TDD work in three different companies. Of course, TDD is not going to fix broken project management such as blindly trying to second guess vague requirements. Other types of QA are also necessary, including (but not limited to) client UAT and sign-off on features, to make sure you're continuously working towards something the client would want to use.
- mlthoughts2018 8y ago
  I appreciate the comment but for me seeing is believing. I’ve heard many people make claims like yours, but across 5 “enterprise” software jobs at large companies (many thousands of engineers) and 2 jobs at medium startups ~10 yrs old and 300+ engineers, I’ve never ever seen any type of formal methodology make any impact or difference of any kind. I’ve only ever seen non-engineers arguing about process crap and making claims like this, while engineers are forced to learn a bizarre skill set of how to actually solve problems despite this quarter’s latest and greatest new process thingy that’s going to fix it all.
jdlshore 8y ago
I've been using TDD for years (since 2000!) and my experience doesn't match yours. I've used it on countless projects, big and small. I think the disconnect is that you're assuming the tests are about requirements, when in fact the tests people write with TDD are much more tightly focused.
- mlthoughts2018 8y ago
  > “in fact the tests people write with TDD are much more tightly focused.” This usually doesn’t help and sometimes hurts, because if the tests are tighlty scoped yet the requirements are ambiguous, it usually means the tests are very related to the current implementation details, which are going to rapidly change due to scope pivots. TDD simply doesn’t work when you don’t know what tests to write or how to structure tests to accomodate scope and priority changes, which is all the time. Starting out by writing a test then coding to pass that test is baking in an assumption about that test which is almost surely already wrong, and just creates rework to undo a tightly focused test.
  - bethly 8y ago
    When TDDing the tests are going to change a lot, just like the code you are saying you write anyway. I recommend the book Refactoring for the tools so you can make the changes without breaking the test, then clean up the now-unimportant tests, and then clean up the unused code. That way the tests stay green even when making major, breaking changes. Being able to slice projects that way, in terms of functional behavior, is absolutely a skill that requires practice. You are already thinking about what your code needs to do: the practice is to get good at expressing that in terms the computer understand. Once you are in the habit, the tests make it easier to evolve the code rather than harder. It is possible to be a good developer without that skill, but learning and practicing the skill will make you better.

l0b0 8y ago

I'm sorry you're going to feel I'm full of it, but I've seen TDD work in three different companies. Of course, TDD is not going to fix broken project management such as blindly trying to second guess vague requirements. Other types of QA are also necessary, including (but not limited to) client UAT and sign-off on features, to make sure you're continuously working towards something the client would want to use.

mlthoughts2018 8y ago
I appreciate the comment but for me seeing is believing. I’ve heard many people make claims like yours, but across 5 “enterprise” software jobs at large companies (many thousands of engineers) and 2 jobs at medium startups ~10 yrs old and 300+ engineers, I’ve never ever seen any type of formal methodology make any impact or difference of any kind. I’ve only ever seen non-engineers arguing about process crap and making claims like this, while engineers are forced to learn a bizarre skill set of how to actually solve problems despite this quarter’s latest and greatest new process thingy that’s going to fix it all.

jdlshore 8y ago

I've been using TDD for years (since 2000!) and my experience doesn't match yours. I've used it on countless projects, big and small. I think the disconnect is that you're assuming the tests are about requirements, when in fact the tests people write with TDD are much more tightly focused.

mlthoughts2018 8y ago
> “in fact the tests people write with TDD are much more tightly focused.” This usually doesn’t help and sometimes hurts, because if the tests are tighlty scoped yet the requirements are ambiguous, it usually means the tests are very related to the current implementation details, which are going to rapidly change due to scope pivots. TDD simply doesn’t work when you don’t know what tests to write or how to structure tests to accomodate scope and priority changes, which is all the time. Starting out by writing a test then coding to pass that test is baking in an assumption about that test which is almost surely already wrong, and just creates rework to undo a tightly focused test.
- bethly 8y ago
  When TDDing the tests are going to change a lot, just like the code you are saying you write anyway. I recommend the book Refactoring for the tools so you can make the changes without breaking the test, then clean up the now-unimportant tests, and then clean up the unused code. That way the tests stay green even when making major, breaking changes. Being able to slice projects that way, in terms of functional behavior, is absolutely a skill that requires practice. You are already thinking about what your code needs to do: the practice is to get good at expressing that in terms the computer understand. Once you are in the habit, the tests make it easier to evolve the code rather than harder. It is possible to be a good developer without that skill, but learning and practicing the skill will make you better.