5 ms·
I had the misfortune to work on (and re-write) a legacy system in a previous job and I constantly alternated between admiration and horror. In some places the
by InfiniteRand 6y ago
I had the misfortune to work on (and re-write) a legacy system in a previous job and I constantly alternated between admiration and horror.
In some places the web GUI was precisely designed exceptionally well, items placed together precisely, all designed expertly around the specific domain of concern.
On the other hand, there were race conditions, corrupted data, sql injection, mountains of source files that re-implemented the same things, IE6-7 era compatibility issues, etc.
Then there was the mysterious parts of the program which I never understood, like the auto-email capabilities whose scripts could never be located, mysterious mirror servers that I would figure out existed by looking at the ip addresses of odd requests, little bits of domain logic which I would accidentally break and have to cobble back together.
In a lot of ways, many of the problems just stemmed from age, it was an early 90's application in an early-2010's world. There definitely were some not ideal software development practices that contributed to difficulties as well. But I still had a sense that the previous developer had crafted this beautiful, unique, intricately complex and inter-dependent little world.
Sometimes I was sad I had to brush all of that aside even when my changes made things more robust, reliable and compatible with the modern world.
- Teknoman117 6y agoI don't know if I'm unique in this regard, but I actually find it rather fun / interesting to work on the "rewrite the legacy system" projects. I generally find it to be an interesting puzzle.
- gen220 6y agoIt takes a lot of patience but it is oh so rewarding. I like to think of it as "software archaeology". It's fun to gradually discover the model that the programmer was intending to program, then to see where it broke down X months/years later and was fixed with a hack. Then, you get to design a new model that fits both cases elegantly, instead of just a subset. You kind of feel like the scientists in Jurassic Park! :)
- Teknoman117 6y ago"software archaeology" is definitely a way I'd choose to describe it as well!
- userbinator 6y agoI like working on legacy systems too, but not to rewrite them wholesale, as that just tends to cause more problems --- instead, to carefully maintain and extend them.
- njharman 6y agoMy favorite activity (in life really) is to "make order out of chaos". Refactoring from tiny feature to full rewrite is prime example of this. Adding tests, adding documentation, all of it. Loves it! In real life I get "chaos -> order" highs from organizing my collections, tidying up house, doing dishes, etc. If I look around code base or my house and there is chaos I get stress. If everything is "in it's spot", ordered, understood I literally feel wave of "ease" wash over me, I am able to relax.
- kbenson 6y ago> In a lot of ways, many of the problems just stemmed from age, it was an early 90's application in an early-2010's world. There definitely were some not ideal software development practices that contributed to difficulties as well. But I still had a sense that the previous developer had crafted this beautiful, unique, intricately complex and inter-dependent little world. I've had exactly that experience. It was an old Apache mod_perl CGI app that used labels and goto statements for flow control, and for well over a decade nobody wanted to touch it because of that. Once I dived in to change it I realized there was a method to the madness. Mod_perl essentially takes your code and wraps it in a sub (function), so if you have subs in your script and use any sort of globals, those turn into function variables, and their use in the subs causes closures. By emulating function calls with goto and labels this problem was side-stepped. Not how I would have done it (and not something I kept as I revised the script), but what at first appeared to to be complete insanity eventually ended up being based on the environment and the time it was built in. It's a good reminder that often what appears to be stupidity of the prior programmer is actually your own misunderstanding of the problem (and probably poor documenting of the problem as well...)