legacy

August 5th, 2007

lexmark was morbidly scared of change. amazon on the other hand couldn’t get enough of it. the mindset at each place was a direct result of overall culture, which i should return to at some point, but for now i want to stick to legacy. what’s good about it, what’s bad, and my current thoughts or lack thereof on how to navigate situations involving large and aging legacy code.

at this point in my career programming isn’t hard, designing and building systems isn’t hard. it takes some time and thought, but it’s not difficult. what is difficult, extremely so for me because i haven’t come up with a way to cope with it, is dealing with legacy systems. i guess i should elaborate b/c it’s more than legacy systems, it’s systems that are complicated, fragile, and stagnate (incapable of agility.) i lose sleep, get depressed, frustrated, exasperated, and just don’t want to touch them. i want to know how to deal with this. in reality i think i just have to quit caring (so much,) but i never seem to be able to do it.

note: when i say legacy i guess i really mean crufty stuff that is a pain to live with, impossible to understand and debug, with that said.

legacy is good because…

it is known, there are probably bugs, but they don’t show up. the bad ones were seen and hopefully corrected long ago. it probably works right now, and in some cases that’s good enough. if it’s not part of your core business function you may not need it to be better. if you don’t deal with lots of request for features and one-off behaviors you may not need to be that agile and might be able to afford a longer dev cycle, but even so who wants things to work that way.

legacy is bad because…

it slows development down. everything takes 3 times longer to do than it should. changing a tiny piece of functionality in one place breaks 4 others and worse yet in subtle ways that are not immediately visible. it’s harder to debug, you can’t tell what’s going on when a system goes wrong. there are two many moving parts. the functions supporting a use case are spread throughout the code and can’t be easily grokked, updated and modified. multiple people can’t work on it without stepping on each other’s toes since pieces are so tightly intertwined. code can’t be reused, every new feature requires changes at every level in the code. the more code in a system the harder it will be to maintain and the longer a system has been around the more code it’s going to have.

it’s not all bad…

legacy is kinda of misnomer, not all legacy is bad legacy (though it seems that way at times.) things can always improve, but the better they are done the less likely it needs or will ever need to be scrapped and redone. if you get nothing else from this essay please take away this: contrary to what people often seem to think it does not take longer to build things right. i can’t tell you how many times i’ve heard it said that it’s this way b/c we were in a hurry and just threw it together. when it’s valid/true it’s partly the broken window principle and the other part building on a shaky foundation. if things were done well from the start it still wouldn’t be taking longer to do things the right way. just as it wouldn’t of taken longer to do things up until this point the right way. the wrong way takes longer, maybe not when extremely short sighted, like days, but anything past that doing things the quick and dirty way always takes longer than the right way, and it’s just as quick. i guess the problem is that you have to know the right way, but …

the right way…

if only there was a right answer. having gone through both lexmark and amazon i can say that amazon was a much more agile and effective environment not to mention pleasant to work in. at the same time you have to be careful, in a small company you can’t always afford to screw up, both amazon and lexmark can. i hear from friends still at lexmark from time to time that they’re slowly starting to come around and see their legacy problem, but still afraid to do what it really takes to address it. so the right way is to do things better/right from the start, but what do you do if it’s not the start and you’ve got negative legacy, hell if i really know. i’d want to ditch it for my own sanity, but that might not always be the best route. maybe i’ll figure it out sometime, if i do you’ll be the first to know.

Interesting Posts