4 ms·

I recall a situation where a manager was pushing for TFD in an Agile environment. What a nightmare, the two just don't mix. The biggest issue isn't the approa

I recall a situation where a manager was pushing for TFD in an Agile environment. What a nightmare, the two just don't mix. The biggest issue isn't the approach itself, but when it hits Buzzword level with the managers who have no idea how development really works.

firepoet 11y ago
This is true. These kinds of changes should come from the professionals -- it is, after all, their reputation on the line. As a software developer and executive simultaneously, I walk a fine line -- usually I adopt a practice myself and show people what it has done for me and the maintainability of my code. Then if people are curious I help. If not, that's fine. They'll come around or go somewhere else where engineering is less rigorous. It's extremely tricky to avoid being threatening as a leader. Your position gives you power nobody else believes you deserve. Even when, sometimes, you do. Not saying I deserve it, but there are those that I've worked with that did, and I only noticed in hindsight. F'ing limbic system.
- abawany 11y ago
  In my scenario, not only was the management mandating TDD, they were also mandating a code coverage minimum, leading to joyless soul-crushing unit tests such as those for getters and setters to boost coverage. The projects ultimately were not successful and this same swarm is I suspect now making some other developers' lives very miserable with the same broken-record absolutist ideologies.
tragic 11y ago
This is a weird argument, since both (Agile & TDD) were codified by basically the same people, or at least two sets of people with a big old overlap.
- andrewclunn 11y ago
  It's a way of offloading more work onto the coders so that the PMs can just go down a checklist instead of having to actually manage. Now instead of just constantly refactoring, you need to write new tests each time first. Then it's sold to us as making us "better coders." It doesn't make us better coders. It makes us easier to manage and puts even more work on our plates.

firepoet 11y ago

This is true. These kinds of changes should come from the professionals -- it is, after all, their reputation on the line. As a software developer and executive simultaneously, I walk a fine line -- usually I adopt a practice myself and show people what it has done for me and the maintainability of my code. Then if people are curious I help. If not, that's fine. They'll come around or go somewhere else where engineering is less rigorous. It's extremely tricky to avoid being threatening as a leader. Your position gives you power nobody else believes you deserve. Even when, sometimes, you do. Not saying I deserve it, but there are those that I've worked with that did, and I only noticed in hindsight. F'ing limbic system.

abawany 11y ago
In my scenario, not only was the management mandating TDD, they were also mandating a code coverage minimum, leading to joyless soul-crushing unit tests such as those for getters and setters to boost coverage. The projects ultimately were not successful and this same swarm is I suspect now making some other developers' lives very miserable with the same broken-record absolutist ideologies.

tragic 11y ago

This is a weird argument, since both (Agile & TDD) were codified by basically the same people, or at least two sets of people with a big old overlap.

andrewclunn 11y ago
It's a way of offloading more work onto the coders so that the PMs can just go down a checklist instead of having to actually manage. Now instead of just constantly refactoring, you need to write new tests each time first. Then it's sold to us as making us "better coders." It doesn't make us better coders. It makes us easier to manage and puts even more work on our plates.