When I was 12, I wasn't very good at cleaning up my room. It wasn't dirty, per se, but had piles of clothes everywhere. My Mom griped and complained about having to "wade" into the room in order to get the laundry. I assured her it was safe, but did caution that she shouldn't show fear - the dirty socks could sense that. She finally gave up, and said that I must take the laundry to the basement myself, which I did.
One day, there was a particular shirt that I just had to wear to school. No other shirt was acceptable. I couldn't find it in my room, and the dirty socks assured me they hadn't seen it. I went downstairs to the laundry room, and there was the shirt, sitting on top of a pile of clothes that had yet to be cleaned. I was furious. What sort of place was this, where you couldn't get clothes cleaned when you needed them?! I was ready to go give Mom a piece of my mind, when a sudden wave of lucidity overcame me. In that brief moment, the potential outcomes of telling Mom that she had been derelict in her duties were clear, and none of them were particularly pleasant.
I decided to use a different strategy - do the laundry myself! There were these interesting symbols on the tags of my clothes, and I had noticed that the washer had a legend for those symbols on the inside of the lid. The instructions on the washer also mentioned something about washing like colours together. So, I tried washing the clothes. It didn't hurt a bit. Neither did drying them.
It was a liberating feeling... I was suddenly no longer dependent on Mom's schedule! I could wash my clothes at will! I did learn that you don't mix a new red shirt with white underwear, or at least you don't wear the resulting pink underwear on a day when you have gym class. Painful clarity does make for easy learning!
Years later when I went to university and lived in an all-male dorm in my freshman year, I was suddenly the person that the other guys asked about how to do their laundry. I helped prevent several pink underwear incidents, sparing floormates the same potential embarrassment I had endured!
Coaching Point
At some point, you have to instil independence in the team you're coaching. As a coach, you really are trying to work yourself out of a job with each team you encounter. Like your children, you want them to mature, become independent and do their own bloody laundry!
Technical Debt in a code base is a prime example of dirty laundry. If you don't keep the code clean by refactoring constantly and writing automated tests as a safety net to enable that refactoring, the team will find itself paralyzed by the fear of breaking something. Like those dirty socks, debt-ridden code can sense fear and will break in seemingly random places in order to perpetuate that fear further.
Leaving that code to a maintenance or sustaining team is the same as me waiting for my Mom to call in a HazMat team to remove the dirty laundry from my room. She didn’t know my ‘schedule’ any more than a separate team knows that the team you’re coaching has to make changes in that crappy code that will break what the maintenance team is doing.
The problem, though, is that you can't clean up the mess yourself because you're only the coach. You have a team that's fully capable of doing its own laundry given a little guidance. You need to provide the equivalent of the tags on the clothes and the instructions for what colours should go with what. This comes in the form of Code Smells to identify what's wrong, and Refactorings to clean it up.
There are other Agile technical practices that help keep your laundry clean, ironed and folded at all times.
Continuous Integration
It’s important to remember that continuous integration means, well, to integrate continuously. It doesn’t mean a build server or the software to perform automatic builds, although those tools do aid in the continuous integration process.
When you have a team of people working together on some software, there are going to be times when they need to work on the same areas of the code. Resolving conflicts between the changes created by multiple developers can be a royal pain and my general advice when something is painful is to do it as often as possible! No, I’m not a masochist, but rather I prefer small instances of pain that fall below the "I never want to do this again" threshold.
If integrating code after the developers have worked for a week or two in their own personal branch (more on that later) takes one or more days and results in many conflicts and errors, why not integrate once per day? There won’t be as many conflicts, because no individual developer will have created or changed that much code. If that works well, why not integrate twice per day? Why not once or twice per hour?
To achieve this, the team needs a very fast build and very fast microtests that allow each individual developer (or pair) to use the following process each time they want to integrate:
This process also eliminates the need for developers to have their own personal branches of the code, and even can lead to the elimination of feature branches. Every developer is working from Trunk, or the main branch of the code. You may need to maintain some branches after a release to support previous versions of the system, but the need for separate development branches all but disappears.
Test-Driven Development (TDD)
This is almost the equivalent of doing your laundry before you wear the clothes, but that's the great thing about analogies - they don't have to perfectly reflect reality! That said, imagine if you had a tiny little washer, dryer and iron combination that had capacity to wash a single outfit - shirt, pants, socks and underwear - and could do it in just a few minutes. You just tossed that outfit into this little machine, and out came your clothes cleaned and pressed and ready to wear again. Would you be more likely to do your laundry more often?
The Lean community has plenty of data regarding the goodness of small batches of work, and software testing certainly follows that rule. TDD takes small batch processing to the extreme - one failing test, just enough code to make it past. Rinse and repeat.
TDD also makes code simpler, more focused on the task at hand and, by definition, more testable. It takes some time to learn, or more correctly to unlearn previous habits, but the benefits are enormous compared to the cost of learning it.
Collective Ownership
Why do everyone else's laundry by yourself? If the whole family pitches in, then the effort of doing the laundry is smaller. Ensure that everyone on the team is responsible for all parts of the code. Islands of knowledge create potential bottlenecks and significant risks - what if the only team member who knows the most important widget in the system leaves for another job?
As a coach, your role is to help the teams with whom you work learn to do their own laundry. You can show them how to identify Code Smells, clean them up with Refactoring, Integrate their work Continuously, write code Test-First and to Collectively Own the code in the system, but you need to ensure that you aren't doing it for them. Using analogies like "Doing the Laundry" can be quite helpful. Essentially, your role becomes teaching the team how to read the funny symbols on the tags, and how to separate colours from whites in order to avoid, um, pink underwear incidents. :)
One day, there was a particular shirt that I just had to wear to school. No other shirt was acceptable. I couldn't find it in my room, and the dirty socks assured me they hadn't seen it. I went downstairs to the laundry room, and there was the shirt, sitting on top of a pile of clothes that had yet to be cleaned. I was furious. What sort of place was this, where you couldn't get clothes cleaned when you needed them?! I was ready to go give Mom a piece of my mind, when a sudden wave of lucidity overcame me. In that brief moment, the potential outcomes of telling Mom that she had been derelict in her duties were clear, and none of them were particularly pleasant.
I decided to use a different strategy - do the laundry myself! There were these interesting symbols on the tags of my clothes, and I had noticed that the washer had a legend for those symbols on the inside of the lid. The instructions on the washer also mentioned something about washing like colours together. So, I tried washing the clothes. It didn't hurt a bit. Neither did drying them.
It was a liberating feeling... I was suddenly no longer dependent on Mom's schedule! I could wash my clothes at will! I did learn that you don't mix a new red shirt with white underwear, or at least you don't wear the resulting pink underwear on a day when you have gym class. Painful clarity does make for easy learning!
Years later when I went to university and lived in an all-male dorm in my freshman year, I was suddenly the person that the other guys asked about how to do their laundry. I helped prevent several pink underwear incidents, sparing floormates the same potential embarrassment I had endured!
Coaching Point
At some point, you have to instil independence in the team you're coaching. As a coach, you really are trying to work yourself out of a job with each team you encounter. Like your children, you want them to mature, become independent and do their own bloody laundry!
Technical Debt in a code base is a prime example of dirty laundry. If you don't keep the code clean by refactoring constantly and writing automated tests as a safety net to enable that refactoring, the team will find itself paralyzed by the fear of breaking something. Like those dirty socks, debt-ridden code can sense fear and will break in seemingly random places in order to perpetuate that fear further.
Leaving that code to a maintenance or sustaining team is the same as me waiting for my Mom to call in a HazMat team to remove the dirty laundry from my room. She didn’t know my ‘schedule’ any more than a separate team knows that the team you’re coaching has to make changes in that crappy code that will break what the maintenance team is doing.
The problem, though, is that you can't clean up the mess yourself because you're only the coach. You have a team that's fully capable of doing its own laundry given a little guidance. You need to provide the equivalent of the tags on the clothes and the instructions for what colours should go with what. This comes in the form of Code Smells to identify what's wrong, and Refactorings to clean it up.
There are other Agile technical practices that help keep your laundry clean, ironed and folded at all times.
Continuous Integration
It’s important to remember that continuous integration means, well, to integrate continuously. It doesn’t mean a build server or the software to perform automatic builds, although those tools do aid in the continuous integration process.
When you have a team of people working together on some software, there are going to be times when they need to work on the same areas of the code. Resolving conflicts between the changes created by multiple developers can be a royal pain and my general advice when something is painful is to do it as often as possible! No, I’m not a masochist, but rather I prefer small instances of pain that fall below the "I never want to do this again" threshold.
If integrating code after the developers have worked for a week or two in their own personal branch (more on that later) takes one or more days and results in many conflicts and errors, why not integrate once per day? There won’t be as many conflicts, because no individual developer will have created or changed that much code. If that works well, why not integrate twice per day? Why not once or twice per hour?
To achieve this, the team needs a very fast build and very fast microtests that allow each individual developer (or pair) to use the following process each time they want to integrate:
- Update the code from source control
- Build
- If the build is successful, execute all microtests
- If the tests pass, commit the changes to source control
This process also eliminates the need for developers to have their own personal branches of the code, and even can lead to the elimination of feature branches. Every developer is working from Trunk, or the main branch of the code. You may need to maintain some branches after a release to support previous versions of the system, but the need for separate development branches all but disappears.
Test-Driven Development (TDD)
This is almost the equivalent of doing your laundry before you wear the clothes, but that's the great thing about analogies - they don't have to perfectly reflect reality! That said, imagine if you had a tiny little washer, dryer and iron combination that had capacity to wash a single outfit - shirt, pants, socks and underwear - and could do it in just a few minutes. You just tossed that outfit into this little machine, and out came your clothes cleaned and pressed and ready to wear again. Would you be more likely to do your laundry more often?
The Lean community has plenty of data regarding the goodness of small batches of work, and software testing certainly follows that rule. TDD takes small batch processing to the extreme - one failing test, just enough code to make it past. Rinse and repeat.
TDD also makes code simpler, more focused on the task at hand and, by definition, more testable. It takes some time to learn, or more correctly to unlearn previous habits, but the benefits are enormous compared to the cost of learning it.
Collective Ownership
Why do everyone else's laundry by yourself? If the whole family pitches in, then the effort of doing the laundry is smaller. Ensure that everyone on the team is responsible for all parts of the code. Islands of knowledge create potential bottlenecks and significant risks - what if the only team member who knows the most important widget in the system leaves for another job?
As a coach, your role is to help the teams with whom you work learn to do their own laundry. You can show them how to identify Code Smells, clean them up with Refactoring, Integrate their work Continuously, write code Test-First and to Collectively Own the code in the system, but you need to ensure that you aren't doing it for them. Using analogies like "Doing the Laundry" can be quite helpful. Essentially, your role becomes teaching the team how to read the funny symbols on the tags, and how to separate colours from whites in order to avoid, um, pink underwear incidents. :)
Comments
These posts are excellent. I'm sending links to a number of friends. :)