A Legacy Code Retreat Session, part 1 - Introduction
Links to other parts of this series:
A Legacy Code Retreat Session, part 1 - Introduction
A Legacy Code Retreat Session, part 2 - Heads up and Preparations
A couple of days ago it was agreed upon at the software shop I am working in that the developers should have some sort of training session before the holidays. One of the reasons was that the management aims to give the developers the opportunity to better themselves during work hours, another was that the client demand is lower before the holidays, so there is more time to do some sort of learning session at this time of the year, and finally, people are tired of work by now, so it's a good idea to just let them work on something else, and let some steam off.
We recently had a short clean code presentation, that ended on the note of having a legacy code retreat session, as we all have legacy code in our daily job (you know the classic definition, legacy code is any code that another developer wrote or code that you wrote, but more than a few days ago), thus this seemed to be an idea that made sense to schedule for this training slot. As I have already led two LCR sessions previously, I was asked to lead/moderate this one as well.
However, an LCR is a demanding session, so you certainly cannot organize one without some preparations. The attendees are working with a rather small codebase, but as it is rather messed-up and entangled, so they will surely have a hard time. Most developers who have no experience with legacy codebases and/or have not read Michael Feathers' excellent book, "Working Effectively with Legacy Code", generally have some seriously hard time with extracting static dependencies, writing good system tests, using the dependency inversion principle to make the code unit-testable, finding good names, extracting good classes, and generally, keeping up with the constant pressure an LCR is putting on the attendees.
What I will try to cover in the following couple of posts is some preparations for an LCR, along with source code in different stages, some nitty-gritty details of assignments, some ideas about what sessions might be revolving around, and some clues on how non-development personnel (business analysts, product owners, testers) could be involved in an LCR.
By the nature of an LCR, half the fun is lost if you know the source code or the session goals in advance. Should you be a participant in an LCR, I recommend you not to read these posts before attempting the LCR, but you might want to read it after the session, to get some sort of summary and ideas on a few sessions your specific LCR might not have had. You might even want to keep working on the code you finished your session with, just to have a feeling of accomplishment.
Should you be an organizer/mentor preparing to host an LCR, feel free to pick up any ideas from here, or to share your own insights in the comments.
A Legacy Code Retreat Session, part 1 - Introduction
A Legacy Code Retreat Session, part 2 - Heads up and Preparations
A couple of days ago it was agreed upon at the software shop I am working in that the developers should have some sort of training session before the holidays. One of the reasons was that the management aims to give the developers the opportunity to better themselves during work hours, another was that the client demand is lower before the holidays, so there is more time to do some sort of learning session at this time of the year, and finally, people are tired of work by now, so it's a good idea to just let them work on something else, and let some steam off.
We recently had a short clean code presentation, that ended on the note of having a legacy code retreat session, as we all have legacy code in our daily job (you know the classic definition, legacy code is any code that another developer wrote or code that you wrote, but more than a few days ago), thus this seemed to be an idea that made sense to schedule for this training slot. As I have already led two LCR sessions previously, I was asked to lead/moderate this one as well.
However, an LCR is a demanding session, so you certainly cannot organize one without some preparations. The attendees are working with a rather small codebase, but as it is rather messed-up and entangled, so they will surely have a hard time. Most developers who have no experience with legacy codebases and/or have not read Michael Feathers' excellent book, "Working Effectively with Legacy Code", generally have some seriously hard time with extracting static dependencies, writing good system tests, using the dependency inversion principle to make the code unit-testable, finding good names, extracting good classes, and generally, keeping up with the constant pressure an LCR is putting on the attendees.
What I will try to cover in the following couple of posts is some preparations for an LCR, along with source code in different stages, some nitty-gritty details of assignments, some ideas about what sessions might be revolving around, and some clues on how non-development personnel (business analysts, product owners, testers) could be involved in an LCR.
By the nature of an LCR, half the fun is lost if you know the source code or the session goals in advance. Should you be a participant in an LCR, I recommend you not to read these posts before attempting the LCR, but you might want to read it after the session, to get some sort of summary and ideas on a few sessions your specific LCR might not have had. You might even want to keep working on the code you finished your session with, just to have a feeling of accomplishment.
Should you be an organizer/mentor preparing to host an LCR, feel free to pick up any ideas from here, or to share your own insights in the comments.
Comments
Post a Comment