4 ms·

Nice points here. I'll have to do a show on "spike and stabilize." This strategy of "late" refactoring and micro testing is something we are forced to do when

Nice points here. I'll have to do a show on "spike and stabilize." This strategy of "late" refactoring and micro testing is something we are forced to do when encountering untested legacy code. So this as part of the "tool kit" to be a master and difficult for someone who is proficient. My perception is that Spike and Stabilize, always takes longer than TDD because: 1) I have to spend time "re-discovering" what the code is supposed to do in order to write the test. 2) If I need to use the debugger or print statements to learn what the code is doing, these temporary diagnostics aren't automatable and the value achieved can't be checked into source code. 3) I have to work harder at bad design decisions that occur when not thinking about unit testing. 4) I find APIs aren't as intuitively crafted because TDD forces you to define your interface to get started (a simple version which evolves as needed) rather than the steps of: "write code, get it working, go back and refactor and test" 5) The costs increase with Spike and Stabilize with the time delta between the moment the code is written to the moment tests are added. 6) Plus Spike and Stabilizes allows people to be pressured into doing the wrong thing: ship it now, worry about test automation later. If you're disciplined, this won't matter because you can simply say no. If you're not, test debt increases. TDD removes this possible risk. Thank you for the suggestion on explicitly adding the TDD "mantra" of red/green/refactor. In episode 22, TDD with a Stack Overflow Master Developer, it explores TDD versus Spike and Stabilize Later in a dramatic presentation: https://agilenoir.biz/podcast/022-tdd-with-a-stack-overflow-master-developer/ https://agilenoir.biz/podcast/022-tdd-with-a-stack-overflow-... This story of a developer going through the challenges of getting his team to do TDD starts with episode 14: https://agilenoir.biz/series/agile-thoughts/ https://agilenoir.biz/series/agile-thoughts/ Thank you for the name, "spike and stabilize." It sounds better than "Test Later Strategy" but I fear it obscures the risky and uncertain future.

eesmith 8y ago
Kent Beck include spikes as part of TDD practice, specifically as a method to reduce risk in an uncertain future. In order to argue your point 1), don't you have to say that spikes are not, or no longer, part of TDD? The difference is that traditional spikes are discarded ... which means you have to spend time "re-dicovering" how the code works anyway, yes? Concerning 2), my point stands that your original statement 'At least a week has passed since when you last used the debugger' is not a key indicator of proficiency at TDD. The rest of your response is advocacy for TDD and "perceived", not a description of how to tell if someone is an expert at TDD, nor necessarily a correct approach for most people. As such, I can only say that my perceptions are different. Your #6 specifically uses TDD as a negotiation tactic, rather than than as a good engineering practice. That is, the "removes this possible risk" you refer to is personal CYA risk. This is different than the business risk. While those are certainly correlated, good engineering considers the overall economic factors. In this respect, TDD is especially useful for programmers as programmers usually have less negotiation experience than their managers, and especially less than managers from marketing and sales (to say nothing of the CEO) who are providing the pressure. Pointing to an external guru who says "TDD is the only professional way to do software development" gives these (usually junior) programmers the leverage to do reasonable testing. Since I am not in that situation, I can choose the development approach which I believe is most appropriate. Which isn't TDD.
- lancerkind 8y ago
  About Spikes: They are a tool to be employed when no one on the team has confidence in how to solve a technical problem. Spikes are used to deliver learning through doing. They are a Plan B. Used when we can't do Plan A--write the tests and the code with TDD. Because it takes longer to write tests later, the Spike is a simple implementation to learn something. Once the learning has happened, then you go into the code and use TDD to develop the product code. The spike code is never meant to be product code. Don't you think it's a misuse if ALL of your development is using spikes? Don't you think that this use of Spikes is a crutch to avoid something you are unmotivated do and haven't invested time to learn?

eesmith 8y ago

Kent Beck include spikes as part of TDD practice, specifically as a method to reduce risk in an uncertain future. In order to argue your point 1), don't you have to say that spikes are not, or no longer, part of TDD? The difference is that traditional spikes are discarded ... which means you have to spend time "re-dicovering" how the code works anyway, yes? Concerning 2), my point stands that your original statement 'At least a week has passed since when you last used the debugger' is not a key indicator of proficiency at TDD. The rest of your response is advocacy for TDD and "perceived", not a description of how to tell if someone is an expert at TDD, nor necessarily a correct approach for most people. As such, I can only say that my perceptions are different. Your #6 specifically uses TDD as a negotiation tactic, rather than than as a good engineering practice. That is, the "removes this possible risk" you refer to is personal CYA risk. This is different than the business risk. While those are certainly correlated, good engineering considers the overall economic factors. In this respect, TDD is especially useful for programmers as programmers usually have less negotiation experience than their managers, and especially less than managers from marketing and sales (to say nothing of the CEO) who are providing the pressure. Pointing to an external guru who says "TDD is the only professional way to do software development" gives these (usually junior) programmers the leverage to do reasonable testing. Since I am not in that situation, I can choose the development approach which I believe is most appropriate. Which isn't TDD.

lancerkind 8y ago
About Spikes: They are a tool to be employed when no one on the team has confidence in how to solve a technical problem. Spikes are used to deliver learning through doing. They are a Plan B. Used when we can't do Plan A--write the tests and the code with TDD. Because it takes longer to write tests later, the Spike is a simple implementation to learn something. Once the learning has happened, then you go into the code and use TDD to develop the product code. The spike code is never meant to be product code. Don't you think it's a misuse if ALL of your development is using spikes? Don't you think that this use of Spikes is a crutch to avoid something you are unmotivated do and haven't invested time to learn?