I've invented my own methodology1. It's called "do the right thing". The way this methodology works is, you "do the right thing".
If the build is too slow, [using XP terminology] you don't write a "technical story" to ask the customer for time to speed the build up; you "do the right thing" - if speeding up the build will improve the team's productivity (which it usually does) then you speed the build up. If the code hasn't been refactored then, do the right thing and refactor the code so the team can remain productive - the story isn't finished if the code needs refactoring. If something can be automated, e.g. the deployment process, then do the right thing and automate it. If some functionality doesn't have an automated test, then write an automated test for it. You don't need to ask permission to do the right thing - it's your duty and your right.
I have seen teams that have not done the right thing; a lack of refactoring, a lack of automatation, and a lack of automated tests are major causes of low productivity, low quality and low morale. You don't need to be "given time" to do the right thing - doing the right thing makes your team more productive and saves you time. Do not give in to short term time pressures - successful software2 lasts longer than anyone expects and takes longer to develop than is typically planned for. I have never seen a software project benefit from taking short term decisions. I've never seen a software project be unproductive because too much has been automated or through too much refactoring. I have seen many projects where there has been a direct correlation between not doing the right thing and the areas that have caused "unexpected" problems, taken longer than they should or resulted in production bugs.
1OK - not really invented, not really mine and not really a methodology. Joe Newton, Joe Walnes, W Edwards Deming and Kent Beck have all influenced this article/rant.
2Also known as legacy software.
I'd argue that just because some refactoring is needed/could be done, it doesn't follow that the story isn't complete. You can deliver the business value associated with the story without it, but if you don't do the refactoring you're storing trouble up for later.
Posted by: Sam Newman at July 3, 2005 6:08 PMHi Ivan,
Remember me from Roche? Well I took your advice and started blogging. If you want to know what I've been upt to, take a look you may be surprised.
Anyway, this doing the right thing. Yeah its hard to disagree, but sometimes doing the right thing conflicts with doing what makes you happy. I'm sure you know what I mean. Some tasks are more fun then others and some days you feel to be more disciplined then others.
Surely its' best to find a balance, doing the right thing most of the time and letting yourself off the hook every now and again.
And velocity can't be the sole indicator of success, can it? Surely having "happy campers" counts for something too.
Anyway, what I say is balance in all things.
Before I go, I must mention that the time we spent working together had a real impact on me - since then I really view my work in a new light.
The debt owed to a teacher is a huge one! Thanks.
It would be really nice to here from you.
Bye for now,
Paul.
>it doesn't follow that the story isn't complete.
Whether you consider the story to be complete or not is one thing. Another is whether or not you think that not doing the refactoring is "doing the right thing". In order to be doing the "do the right thing" methodology, if you think that doing the refactoring is "doing the right thing" then that's what you do, independent of whether you think the story can be considered complete or not.
Posted by: ivan at August 5, 2005 12:11 PM>Surely its' best to find a balance, doing the right thing most of the time and letting yourself off the hook every now and again.
Hi Paul,
great to hear from you!
I agree with a lot of your comment. However, I think that keeping yourself and others happy is "doing the right thing".
Nevertheless, sometimes you have to do the right thing even when it's not going to be fun (for me that would include fixing the build process, which I'm doing today because it's the right thing but not one of those things that I enjoy much). If there are too many lapses of discipline then things will turn bad and unhappy.
At Connextra (http://www.connextra.com) we had Gold Cards (http://www.agilealliance.org/articles/articles/InnovationAndSustainability.pdf), which provided a disciplined amount of indiscipline.
Posted by: ivan at August 5, 2005 12:27 PM