Timeline for How to measure that a team is doing Test Driven Development
Current License: CC BY-SA 3.0
10 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 12, 2019 at 15:24 | comment | added | Baldrickk | If everything should be tested anyway, then it really shouldn't make much of a difference if you are writing the tests before or after the function. | |
| Feb 5, 2014 at 22:47 | comment | added | combinatorics | I believe that we might be stretching the analogy here but I don't believe it does matter which of the 5 code changes fixes the bug as long as the bug is gone and there is no regression. In fact this is quite a common approach - fix the code to remove the bug and refactor the surrounding code if you've come to a deeper understanding of the problem being solved. The analogy breaks down here. Ultimately you can't unit test your development process - a more holistic approach is needed. | |
| Feb 5, 2014 at 16:23 | comment | added | Alan Shutko | @combinatorics, it's interesting you'd say it wouldn't matter which of the five changes made the difference, because you would never say "I made five changes to the source code, and it really doesn't matter which one fixed the bug." | |
| Feb 5, 2014 at 9:07 | comment | added | combinatorics | @Vaccano For what it's worth I'm in exactly the same position myself right now of having to try and explain these concepts to a manager at the company I work for and I'm not having much luck. Management can often be very metric oriented because that style is very effective in some industries (such as manufacturing). Software engineering is creative and requires (in my opinion) a different style of management - the book "Artful Making: What Managers Need To Know About How Artists Work" is quite good at explaining this. I'm thinking of getting a copy for my bean counter. Best of luck! | |
| Feb 5, 2014 at 8:54 | comment | added | combinatorics | @Vaccano The problem might be that measuring the policy directly is way too fuzzy also. Even measuring the implementation of the TDD policy directly you need to compare the result of that to some externally measurable change (such as fewer bugs) and even then all you get is a correlation - the number of cases where TDD policy was followed went up, the number of cases passing acceptance criteria went down. Did the policy work or was it just a sprint of 'easy' changes? | |
| Feb 5, 2014 at 8:46 | comment | added | combinatorics | @AlanShutko I think it should be left to the developers to decide amongst themselves how to organise to achieve their work. The output of their development process is what matters (to anyone outside the team) - if the dev team make 5 changes to the development process and productivity and quality goes up as a result does it matter which of the 5 changes caused the improvement? Development workflow should be a process of continuous improvement that is left entirely to the dev team to control, with management just caring about quality of output. | |
| Feb 5, 2014 at 7:04 | comment | added | Frank | Did you set the goal of having a friendly and welcoming work environment? good luck measuring that.. there are times when you have to talk sense into bean counters for their own sake. I agree though, that TDD as a goal may not be a good choice, as it is just a means to a more goaly end. | |
| Feb 5, 2014 at 3:26 | comment | added | Vaccano | We (the developers) want to do TDD. It is just the "bean counters" that need a hard measurable thing. "Fewer bugs" is too fuzzy as way too many things can contribute to that. | |
| Feb 5, 2014 at 3:06 | comment | added | Alan Shutko | I agree you should measure the results of those policies, and perhaps the results should be the goals but you should also measure the policies! If you do, you can see whether the policies do anything. If velocity on cases is increasing, but your TDD measure is not, it is clear that you have some other variable changing and should look for it. | |
| Feb 5, 2014 at 0:42 | history | answered | combinatorics | CC BY-SA 3.0 |