Embrace your legacy

Transcript

1. Embracing your legacy Tom Ridge | @tjridge
2. hello.cultureamp.com/jep-2
3. So, about that legacy code. Who here works at a product company? Who here works with legacy code of some description? And who here would describe what they do as architecture?
 
 So I’ve been hearing a lot of hate for legacy code, and it’s not just around my neck of the woods, a cursory search on twitter shows some classic takes, like:e
6. This one’s my favourite.
8. And they’re not entirely wrong, it’s frustrating spending so much time digging through various people’s diversions away from the gospel of Sandi. It generates WTF’s at a rate not yet measurable by any speed camera. On top of that, it makes our jobs harder, worse, can undermine our ability to ensure our applications remain secure.
9. Legacy code has often been written hastily, without any thought or consideration for it’s future maintainers, with naming conventions that make the acquisition of any kind of domain knowledge much harder than it needs to be. Decisions made for short term gain, that have now lead to long, painful untangling of the mess that was made here in the present. Entire sections of our industry have become devoted to helping us tackle the problem of legacy code, and gracefully refactoring it away. We crave advice on how to solve our legacy problem, it’s something that we frequently commiserate over together, apparently, over twitter, meetups or otherwise
10. Sometimes we just sidestep the issue altogether, either through rewrites or entire service extractions, I know, I’ve done this at least twice. As architects of systems, we look upon this code, and the decisions that inspired it, with disdain, we clearly, know better. We would have architected things differently and we would have built legacy systems that last. And perhaps that’s the problem. There’s a certain irony in sitting in our comfortable seats, being paid to cast derision over the code that got us the job in the first place. We imagine ourselves architects, engineers, that when given the opportunity, write graceful, performant, clean code and design impeccable systems. We imagine ourselves overseeing systems that look like this:
11. Sometimes we just sidestep the issue altogether, either through rewrites or entire service extractions, I know, I’ve done this at least twice. As architects of systems, we look upon this code, and the decisions that inspired it, with disdain, we clearly, know better. We would have architected things differently and we would have built legacy systems that last. And perhaps that’s the problem. There’s a certain irony in sitting in our comfortable seats, being paid to cast derision over the code that got us the job in the first place. We imagine ourselves architects, engineers, that when given the opportunity, write graceful, performant, clean code and design impeccable systems. We imagine ourselves overseeing systems that look like this:
12. Rather than this:
13. Our objectives are simple, build features, in a performant, well architected manner, but those constraints are luxuries, luxuries afforded to us by those short-sighted technical decisions that came before us. The decisions made by those before us were driven by the need to deliver value first, and be built “well-enough”. This doesn’t give them a free pass either, often this code is objectively bad, and those short term decisions have consequences on our ability and speed to deliver value now. 
 
 But they did deliver value, else we wouldn’t be employed. They’ve built for us jobs, built for us opportunities, and a great chair to sit on and think about how we go about reconciling this notion of architect when it comes to confronting legacy code.
14. So, I, like a lot of you, happen to work predominantly with a monolithic legacy code base. I’ve spent a bunch of time over the past year, untangling domain knowledge, often with non-existent or incomplete tests or documentation and like the very best case of Stockholm syndrome, despite all of this, despite the constant searching for answers, I’ve come to identify with my captors. Actually, it’s probably more accurate to say that I’ve stopped imagining myself as an architect, but a gardener instead.
15. So, I’m going to digress a bit, before I explain why I think we can be more akin to gardeners, than architects. My lawn and garden for the longest time, have been a travesty. Muck weed, and other weeds have infested it since we got there, and I’ve struggled to really control it since. I used to hate gardening, thinking I could just throw some weed and feed, or weedkiller on it, and the problem would go away on its own, I’d rarely mow the lawn. Every single time it rained, those same weeds would show themselves time and time again. I’d frequently wonder if it was just easier to start from scratch and put some new lawn down.
16. My daughters have gotten into it too, we recently took them to Bunnings, and they’ve now planted their first strawberries, parsley, basil, tomatoes, mint and some flowers. They were absolutely super excited about this, but needing to move the plants to bigger pots, needing to water them everyday has already made them a little bored with the idea, and these plants haven’t even gotten to the stage where more care is needed yet.
17. Gardening requires constant disciplined care, and maintenance. Wins can be hard, and sometimes not very evident that they’ve occurred at all. It’s not exactly glamourous, the sheen of those new seedlings, wears off fast and you’re more often than not, covered in dirt. A garden that has been lovingly tended to, over time is just about as an impressive thing you’ll find on this earth.
18. We are not architects, so much as we are gardeners. Our job is to take a garden, no matter how infested with weeds it is, and help it realise it’s true potential. The job of legacy code is to build a business, our job, is to take that and help it grow. Once we start reframing ourselves in this way, so much more falls into place, to the point at which the dead horse I’m about to beat this analogy on will be ground into dust.
19. “ – Helen Mirren Gardening is learning, learning, learning. That’s the fun of them. You’re always learning Gardeners` embrace a learning culture, they understand that every garden is different, behaves different, receives different amounts of sunlight and rainfall. Similarly every code base is different, it’s customer base is different, the domain is different. Our very craft and ability to debug demands that we are constantly engaged and geared towards learning. Legacy code bases demand that we learn, and are indifferent towards the lack of tests, or domain experts that are no longer present.
20. “ - Alfred Austin There is no gardening without humility. Nature is constantly sending even its oldest scholars to the bottom of the class for some egregious blunder. Gardens teach us what it means to be wrong, in the same way that they embrace a learning culture, they accept failure. Approaching your legacy code base with a gardener’s attitude means a willingness to accept failure as part of the process. Oftentimes our assumptions about how the code should or does work are wrong.
21. “ - Liberty Hyde Bailey A garden requires patient labor and attention. Plants do not grow merely to satisfy ambitions or to fulfil good intentions. They thrive because someone expended effort on them. Gardener’s understand that everything they do, requires patience, time and discipline. A garden takes time to be established. Similarly our code bases thrive from constant attention, constant clearing, trimming, adherence to the camp fire rule. Our code bases thrive when we strive for consistency, when we continue to work towards cleanliness and maintainability, rather than trying to just cut swathes through our code hoping it will be better this time around. My favourite refactoring quote, “Make the change easy, this might be hard, then make the easy change”, elludes to the effort involved in growing a code base in a thoughtful manner.
22. “ - Grandpa Pig A weed is just a naughty plant that has grown in the wrong place. A gardener’s philosophy on weeds and weeding is the most simple analogy towards code that needs refactoring that I could possibly hope for. What is code that needs refactoring other than an idea that needs to be shifted somewhere else, it’s not necessarily malicious, or crap, just misplaced. Our legacy systems are full to the brim with weeds, that just require patience and planning about where that responsibility belongs. We understand that small, gradual changes are what will help shape the system in the direction it needs to go, and what could be more applicable to refactoring than “the more you weed the less you weed”, I’d like to push for this as a replacement to the campfire rule, primarly because it emphasizes refactoring as a repeated, disciplined act upon the code base.
23. “ - Grandpa Pig A weed is just a naughty plant that has grown in the wrong place. And the thing about weeds, is they spread, if not properly addressed, they infest and take over a garden. Just like our legacy code if left untouched, its highly coupled dependencies infect and reach too far through a code base.
24. “ - Thomas Fulle A good garden may have some weeds. Gardeners understand that their gardens may still have some weeds. They understand that sometimes leaving a weed or two in favour of attacking something else is the optimal path. Similarly we as engineers need to understand when enough is enough whilst refactoring, that sometimes that little bit of annoying code is ok and that it’s better to wait until a better solution becomes more obvious, or that we have bigger fish to fry.
25. “ - Luis Barragon In the creation of a garden, the architect invites the partnership of the Kingdom of Nature. In a beautiful garden the majesty of nature is ever present, but it is nature reduced to human proportions and thus transformed into the most efficient haven against the aggressiveness of contemporary life As if I needed any more evidence we’re gardeners here’s one that manages to tie together the architect and the gardener. A well designed garden requires thought and pre-planning, it understands that a well designed garden has a clear separation for plants to grow, takes into account the unique characteristics of the soil, the landscape and the sunlight to determine the best fits for that particular patch of earth. Just as we as engineers, must focus ourselves on striving towards creating clear separation of concerns, and creating solutions, choosing archictecture or languages that best fit the problem at hand.
26. “ - Luis Barragon In the creation of a garden, the architect invites the partnership of the Kingdom of Nature. In a beautiful garden the majesty of nature is ever present, but it is nature reduced to human proportions and thus transformed into the most efficient haven against the aggressiveness of contemporary life It allows room for mistakes, and understands that the legacy that proceeded it, informs the direction it should take now. It understands that our interpretations of the domain knowledge from the outside world is a representation of reality, and that we are the dictators of that reality.
27. “ - Louise Beebe Wilder In his garden every man may be his own artist without apology or explanation. Each within his green enclosure is a creator, and no two shall reach the same conclusion; nor shall we, any more than other creative workers, be ever wholly satisfied with our accomplishment. Ever a season ahead of us floats the vision of perfection and herein lies its perennial charm. I’ve held to a belief for a while now, that it’s generally better to identify desired team outcomes or goals and try and align what we do towards those, rather than be dogmatic about adherence to some defined rule sets, there are exceptions of course, but constantly working towards an outcome, has lead to better results for our team. Gardeners understand that each garden is different, and that theirs is a constant strive towards perfection, always changing, as the situation demands it. As engineers, we must embrace a constant drive towards improving our design, taking into account new information, new facts as we can, and making the best possible decisions given the information and context we have available.
28. “ - Ralph Fiennes Gardeners are good at nurturing, and they have a great quality of patience, they're tender. They have to be persistent. Gardeners are patient. They understand they can’t always make all the changes they want to see. They also understand that good change takes time and effort. They teach, and share their knowledge to the younger generation. They do not reside in ivory towers, waiting to be called down. As engineers, we need to be mindful of having patience to make the changes we want to see in our legacy code bases, we have to be patient when trying to skill up our juniors and understand that everything takes time, particularly when dealing with a domain that has its own history, its own language and nomenclature to understand.
29. “ - Ralph Fiennes Gardeners are good at nurturing, and they have a great quality of patience, they're tender. They have to be persistent. Gardeners are patient. They understand they can’t always make all the changes they want to see. They also understand that good change takes time and effort. They teach, and share their knowledge to the younger generation. They do not reside in ivory towers, waiting to be called down. As engineers, we need to be mindful of having patience to make the changes we want to see in our legacy code bases, we have to be patient when trying to skill up our juniors and understand that everything takes time, particularly when dealing with a domain that has its own history, its own language and nomenclature to understand.
30. “ - William Kent Garden as though you will live forever. Gardeners understand that the garden they inherited, is one that will also be inherited by someone else. In the same way, we must embrace our legacy systems, and help them realise their potential for the next maintainers. We need to treat our code bases with care, and thought for the legacy that we will live behind. A neglected garden does not need stay that way.
31. “ - Luis Barragan I don't divide architecture, landscape and gardening; to me they are one. A well designed garden, is a garden that has been designed, one where failures have occurred but persistent, disciplined action has helped to gradually overcome. The end result are swathes of well orchestrated colour. The legacy code we inherit, can be that way too, and by embracing your inner gardener and coming to grips with your opportunity to shape and mould something in order for it to reach its full potential will give you great satisfaction. So sure, we can be architects too, but when confronting legacy code and refactoring, tend to the garden.