Comments on: Coding: The guilty bystander http://www.markhneedham.com/blog/2009/08/30/coding-the-guilty-bystander/ Thoughts on Software Development Sat, 11 Feb 2012 23:17:00 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Dave Cameron http://www.markhneedham.com/blog/2009/08/30/coding-the-guilty-bystander/comment-page-1/#comment-21910 Dave Cameron Mon, 31 Aug 2009 15:15:43 +0000 http://www.markhneedham.com/blog/?p=1594#comment-21910 Thinking about this more today, my opinion on it comes from a pretty specific context. It was a project where we were aiming for monthly releases, had only unit tests but no functional automated tests, a large code base with a lot of features, and generally high code quality. Changes required manual test effort from a team that was half the size of the total development team. The team was fairly enthusiastic about improving the code base; technical activities were not tightly controlled by management. Probably in another context, more cleanup or more effort to clean up would be a good thing. In either situation though, I think TODOs are pretty counterproductive. I agree with Evan, they are usually more of an order or command but without a defined person actually being commanded. I would rather people experiment with quick scratch refactorings to see how the code could be improved. A scratch refactoring should take 10 minutes or less. The time will come when the refactoring makes good sense in the context of a story being played and one of the ideas generated from the scratches can be done and committed. Thinking about this more today, my opinion on it comes from a pretty specific context. It was a project where we were aiming for monthly releases, had only unit tests but no functional automated tests, a large code base with a lot of features, and generally high code quality. Changes required manual test effort from a team that was half the size of the total development team. The team was fairly enthusiastic about improving the code base; technical activities were not tightly controlled by management. Probably in another context, more cleanup or more effort to clean up would be a good thing.

In either situation though, I think TODOs are pretty counterproductive. I agree with Evan, they are usually more of an order or command but without a defined person actually being commanded. I would rather people experiment with quick scratch refactorings to see how the code could be improved. A scratch refactoring should take 10 minutes or less. The time will come when the refactoring makes good sense in the context of a story being played and one of the ideas generated from the scratches can be done and committed.

]]> By: Mark Needham http://www.markhneedham.com/blog/2009/08/30/coding-the-guilty-bystander/comment-page-1/#comment-21881 Mark Needham Sun, 30 Aug 2009 13:28:59 +0000 http://www.markhneedham.com/blog/?p=1594#comment-21881 @Dave - I think you've articulated better than I have the idea of 'The first opportunity' - the next time you use it seems to work quite nicely as a rule of thumb although I guess it would depend a lot on when that next time was. If it was while doing a production fix then I imagine we probabably wouldn't want to do the refactoring at that stage since there's a chance of introducing another problem into the code. Which then links to your idea that we can introduce bugs at any time when we change code. I don't think I quite understand when we will and when we won't experience gains by choosing to refactor an area. There are certainly smells in code that are really easy to see that indicate something should be done but like you say if we go and refactor an area that noone is currently working on then it might be pointless anyway. I wonder if we should look to spend more time refactoring code that is in the core domain or inside the green house to use the Eric Evans analogy? @Evan - I think like you I'd prefer the default to err on the side of overdoing the refactoring but being aware that we have that tendency so we can work out when we've gone too far instead of choosing the easy way and ending up with a code base that's really difficult to work with. I'm not sure of my thinking of TODO - what you say makes a lot of sense & in our current code base we have so many TODOs it's ridiculous. I think maybe it's more a team discipline thing to make sure we do go and fix the code around the areas that are important to our progress. @Dave – I think you’ve articulated better than I have the idea of ‘The first opportunity’ – the next time you use it seems to work quite nicely as a rule of thumb although I guess it would depend a lot on when that next time was. If it was while doing a production fix then I imagine we probabably wouldn’t want to do the refactoring at that stage since there’s a chance of introducing another problem into the code.

Which then links to your idea that we can introduce bugs at any time when we change code.

I don’t think I quite understand when we will and when we won’t experience gains by choosing to refactor an area.

There are certainly smells in code that are really easy to see that indicate something should be done but like you say if we go and refactor an area that noone is currently working on then it might be pointless anyway.

I wonder if we should look to spend more time refactoring code that is in the core domain or inside the green house to use the Eric Evans analogy?

@Evan – I think like you I’d prefer the default to err on the side of overdoing the refactoring but being aware that we have that tendency so we can work out when we’ve gone too far instead of choosing the easy way and ending up with a code base that’s really difficult to work with.

I’m not sure of my thinking of TODO – what you say makes a lot of sense & in our current code base we have so many TODOs it’s ridiculous.

I think maybe it’s more a team discipline thing to make sure we do go and fix the code around the areas that are important to our progress.

]]> By: Evan Bottcher http://www.markhneedham.com/blog/2009/08/30/coding-the-guilty-bystander/comment-page-1/#comment-21880 Evan Bottcher Sun, 30 Aug 2009 13:16:22 +0000 http://www.markhneedham.com/blog/?p=1594#comment-21880 There's definitely a high risk of a yak shaving escapade if you set off to clean up everything that you find while coding - it's a judgement call to choose how far to go. I think more often than not teams I work with by default choose the easy option and do not shave enough yak. I find TODO comments a symptom of this - a colleague of mine once said that he was annoyed by TODOs, that they're a statement of 'I can't be bothered doing this, I want YOU TODO this". I love the 'guilty bystander' analogy btw. There’s definitely a high risk of a yak shaving escapade if you set off to clean up everything that you find while coding – it’s a judgement call to choose how far to go. I think more often than not teams I work with by default choose the easy option and do not shave enough yak.

I find TODO comments a symptom of this – a colleague of mine once said that he was annoyed by TODOs, that they’re a statement of ‘I can’t be bothered doing this, I want YOU TODO this”.

I love the ‘guilty bystander’ analogy btw.

]]> By: Dave Cameron http://www.markhneedham.com/blog/2009/08/30/coding-the-guilty-bystander/comment-page-1/#comment-21878 Dave Cameron Sun, 30 Aug 2009 12:44:22 +0000 http://www.markhneedham.com/blog/?p=1594#comment-21878 I think that taking a mental note of the code that needs improvement and returning to it at the first opportunity is the right thing todo. "The first opportunity" is a subtle thing, however. The very next time the code needs to be touched is the right time to clean it up. As you experienced, not doing so could easily lead to further bugs. There is another reason not to change code besides Silvio's point that there might not be time. Changing code introduces risk. Any change can introduce bugs, even while making the code more flexible. Even code that seems obviously incorrect might be providing a behaviour that the business relies on. If an area is already being changed then there will already be acceptance and regression plans in place. Any clean up efforts can be validated by the same tests. A drive-by refactoring of an area where change is not planned, on the other hand, can easily introduce defects not detected until much later. This will end up slowing the team down when the goal was to go faster. If there is no other work to do besides refactoring it is best to treat it as a scratch refactoring. Try out some wild ideas but the throw the changes away. When the opportunity does come up to change that code, you will probably know exactly the changes you'd like to make. I think that taking a mental note of the code that needs improvement and returning to it at the first opportunity is the right thing todo. “The first opportunity” is a subtle thing, however. The very next time the code needs to be touched is the right time to clean it up. As you experienced, not doing so could easily lead to further bugs.

There is another reason not to change code besides Silvio’s point that there might not be time. Changing code introduces risk. Any change can introduce bugs, even while making the code more flexible. Even code that seems obviously incorrect might be providing a behaviour that the business relies on. If an area is already being changed then there will already be acceptance and regression plans in place. Any clean up efforts can be validated by the same tests.

A drive-by refactoring of an area where change is not planned, on the other hand, can easily introduce defects not detected until much later. This will end up slowing the team down when the goal was to go faster. If there is no other work to do besides refactoring it is best to treat it as a scratch refactoring. Try out some wild ideas but the throw the changes away. When the opportunity does come up to change that code, you will probably know exactly the changes you’d like to make.

]]>