I specialise in legacy code. Not that I'm opposed to doing a greenfield project now and again, but I genuinely enjoy working with legacy code. It's a fun chal

I specialise in legacy code. Not that I'm opposed to doing a greenfield project now and again, but I genuinely enjoy working with legacy code. It's a fun challenge and the "stink of old" on it keeps the must-have-shiny people away for the most part. However, it's always a challenge. For example, sometimes you have subsystems that are begging to be retired. For example, on one system we're maintaining about 20 KLOC of GWT code. For the last 10 years or so, it hasn't really been worth moving away from it, but there will be a day (that is rapidly approaching, I think) where the cost of supporting a mostly abandoned Java framework that compiles into JS outweighs the risk and cost of slowly replacing it. There's a real difference between being pissed off with the choices your predecessors made, or lusting after the new, hot framework and saying: nope... this just isn't viable any more. Planning that transition isn't easy either. Again, it's one of the reasons I enjoy this kind of work. And sometimes, you even just decide that you're going to work with what you've got. Ironically, though, this usually involves more churn, NIH and reinventing the wheel because code written 20 or 30 years ago did not have the facilities that we desire in modern development. You think, I'd love to enjoy the benefits of that new framework, but there ain't no way that we'll be able to use it. How do I get the benefits using the code I already have? Answer: you study what other people are doing and you build the same damn thing in your environment. Nobody builds the new-shiny for old stuff so if you want it, you have to build it yourself. I enjoy bonsai trees. As trees grow, the branches become out of scale with the trunks. You can imagine that if your trunk is the size of a pencil, it doesn't take long for the branches to catch up. So if you want a tree that is in scale, you are constantly having to prune off the branches and grow new ones. There is a saying that a bonsai tree is never finished until it is done. Code is the same way. There is no such thing as avoiding churn -- unless you are truly trying to kill off your project. You always have to prune off branches and grow new ones, otherwise development will slowly grind to a halt -- the challenge of adding functionality without changing the code base getting to be more and more complex. But if you prune your branches before they grow you will end up with a stick in a pot. Or if you decide that you want to grow out every bud that pops out, then you will have an impenetrable mass of confusion. Deciding which branches to grow and which branches to prune, unfortunately requires good taste.