Surviving Legacy Code
We all have legacy code, meaning profitable code that we’re afraid to change. It doesn’t matter who wrote it, in which language, nor when. It matters that we feel the fear now and need to deal with it. Rewrite or refactor? How do we write useful tests? There’s so much to change; how do we get started? When do we stop? Will it ever get any easier?
In the typical programmer’s day job, there’s no time to learn how to do this. We’re already behind schedule and the cost of fixing the legacy code is crushing us. We need a way to learn how to do this safely, correctly, and eventually, even quickly. That’s what Surviving Legacy Code is about.
Any programmer forced to deal with code that they feel afraid to change. That is, all programmers, eventually.
- When to refactor and when to rewrite, and how to do that safely.
- How to resolve the central conflict of legacy code: I need tests to refactor safely, but I need to refactor to write tests effectively.
- How to have some of the safety of tests even before you can write tests.
- Techniques that make it easier to see where exactly to break things apart right now and then to do that systematically and with less risk.
- Architecture and design principles that allow you to make progress while you’re building your understanding of the code you need to change.
- Slow down the pace at which you write new legacy code.
- Planning the delivery of new features while you rescue legacy code.
- Dealing with the increased emotional intensity of working with legacy code.
- Work on a diabolical-but-fun code base (available in at least 30 programming languages).
- Practise microcommitting, a key technique to changing difficult code safely.
- Apply the lessons from the training code base to your project. (Available only in private engagements.)
- Practise a handful of refactoring and testing exercises that develop the most essential legacy code rescue skills and disciplines.
Participants need the following to attend this course.
- A working software development environment in your preferred programming language, including a personal version control system, such as git.
- Something to write with, and something to write on. I suggest index cards or sticky notes and a notebook.
- Access to a project code base in which you’d like to practise. (Only for private engagements.)
Remote Training Preparation
Please do the following at least one day before the course is scheduled to start.
- Upgrade Zoom to the most recent version.
- Check audio, video, and screen sharing on Zoom.
Live/Remote Private Course
The standard course runs as 4 sessions of 1/2 day each scheduled within a 2-week period. The course is suitable for groups up to 20 people. Larger groups should run the course multiple times.
Add team working sessions to your course in order to better support teams working together during the course. During the 1/2-day team working sessions, we practise the techniques of the course using ensemble/mob programming. In these sessions, teams have the opportunity to rescue their legacy code with my guidance and support.
It is also recommended to add follow-up working sessions to be scheduled 1 month, 3 months, and 6-12 months after the course ends, as a way to support the group as they apply what they’ve learned to their daily work.
Start the booking process for your live/remote course.
Join a Public Course
Browse the upcoming course calendar to see which public courses are currently available. You’ll be able to subscribe there to be notified when new courses are scheduled.
This course is available for online self-study, with bulk-purchasing options available if you’re purchasing on behalf of a group.
Live Support Package
Some clients use the online self-study course to learn the fundamentals on their own, then schedule live working sessions with me for guided practice, design review, and to get their questions answered. This schedule gives you an idea how you might use this approach with your group:
- Week 1: participants complete the course individually or as a group
- Week 2: question and answer session plus 1 or 2 team working sessions in the style of ensemble/mob programming
- 2 weeks of regular work
- Week 5: question and answer session plus 1 or 2 team working sessions in the style of ensemble/mob programming
- 1-2 months of regular work
- question and answer session plus 1 or 2 team working sessions in the style of ensemble/mob programming
After this point, the group schedules additional live working sessions as needed.
Request a quote for your self-study live support package.