Yes... but the company did not use it for long. Large insurance business paid a previous contractor to write up a simple web app to consolidate public rates. So this business could go and answer questions like "how much is my competition charging for XYZ?" This "simple web app" turned into the previous contractor writing his own insane web framework from scratch in Python, because I guess Django or something was not…
Ask HN: Have you ever inherited a codebase nobody on the team could understand?
41–50 of 222 posts
Re: Ask HN: Have you ever inherited a codebase nobody on the team could understand?
#42Yes, on several occasions. Don't do rewrites. Morph the code towards "North." Old code has a reason for existing and being correct: It's there. From an evolutionary and survival of the fittest model, things that are out there already have a lot going for them. The ugly warts are battle scars of nasty edge cases and bugs. This is one of the main reasons I strongly value the skill of reading code in engineers. It's rar…
Re: Ask HN: Have you ever inherited a codebase nobody on the team could understand?
#43Luckily I work in a tech company where the fact that nobody knew this code and it took years to effectively ramp up on was argument enough that it should go away.
Actual removal was a much messier story. It had tangled deeply into adjacent systems so you couldn't "just replace it". We are in the later phases of something like the Strangler Pattern (https://docs.microsoft.com/en-us/azure/architecture/patterns...) where we built higher-level interfaces over the top and gradually re-implemented the underlying functionality without using any of these custom frameworks.
That said, it's a long term project that is easy to lose steam on. It's been very important to regularly revisit our goals and how we're attacking them...AWS has released services that fundamentally changed our approach (for the better) in the years since this effort started and we've probably cut off at least a year from the overall effort by adopting those instead of continuing on the original course.
I wrote up some of these ideas about accomplishing big projects that span years at https://medium.com/@scott_triglia/ask-a-tech-lead-i-have-to-.... The parts about regularly re-evaluating the next steps in your course of action were directly inspired by this project I just described.
Re: Ask HN: Have you ever inherited a codebase nobody on the team could understand?
#44Never rewrite existing code. https://www.joelonsoftware.com/2000/04/06/things-you-should-...
Re: Ask HN: Have you ever inherited a codebase nobody on the team could understand?
#45Re: Ask HN: Have you ever inherited a codebase nobody on the team could understand?
#46Never rewrite existing code. https://www.joelonsoftware.com/2000/04/06/things-you-should-...
It's very sad, but understandable that you're getting down voted. It's understandable because most devs want to put their own stink on a project so rewriting code the "right way" is a way to do it. Problem is, they get 6, 8, 10 months in and figure out the same thing their predecessor did and leave. It's sad, because they don't realize that if a piece of code is out in the field and it's working, then you really shou…
Re: Ask HN: Have you ever inherited a codebase nobody on the team could understand?
#47I'll open by saying I've only ever had bad experiences with complete re-writes and these experiences have impacted my aversion to them. "[Working Effectively with Legacy Code]" by Michael Feathers really helped me get through a situation like this. My recommendation is not to try to understand the code per se, but understand the business that the code was being used in/by. From there, over time, just start writing re…
>> My recommendation is not to try to understand the code per se, but understand the business that the code was being used in/by. I strongly agree with this. I've done at least 4 or 5 successful complete rewrites of old code bases, and I have found, rather than even 'business' the word for this might be 'context'. If you can contextualize a piece of software, it's functionality and operations, you can have a much bet…
Re: Ask HN: Have you ever inherited a codebase nobody on the team could understand?
#48I once inherited a large enterprise system I had to build a full working development environment for and then learn the code base and help bring a team up to speed. The product was essentially made up of 5 code bases in a single repo that built and deployed 5 different executables that worked together. That itself wasn't so bad, it was mostly modern C# and I found it a decent code base to work on. What was bad was th…
Do they not make Virtual Machines where you come from? Or am I missing something?
Re: Ask HN: Have you ever inherited a codebase nobody on the team could understand?
#49I'm speaking from experience, I inherited a project based on TaxiAnytime, aka "Uber App Clone Source Code". What a complete clusterfuck, obviously written in as incomprehensible a style as possible to create attachment sales for customization.
In the PHP/Laravel code three widely used patterns stand out, the "single return statement pattern", which obviously creates the pyramid from hell. In every method. Add to that, the 700+ line methods. Everywhere. And the icing on the cake, I'm going to invent the term "WET" here to describe it. That means the opposite of DRY. Did I say three? WET has the knock-on effect of anti-encapsulation.
I set out to reverse those patterns where I needed to make changes. In about 2 months as a single man team, I had a handle on it and was extending the app. A team of 5 should be able to make short work of it if they can get over the NIH and YUK factors. And yes, beware the rewrite. Coding always seems like it is easy. Until you need a resilient functioning system.
Re: Ask HN: Have you ever inherited a codebase nobody on the team could understand?
#50That was the key actually. At first I diligently tried to understand the code, refactor, rename, move things around... but at some point I crossed a bridge where I suddenly understood, this code is not an asset to be protected and cared for; it's a liability that sucks my time into it and creates not just low, but negative, productivity. And if I don't kill it now, it may suck other victims in. By that time I understood the business processes better and had better implementation ideas anyway, so I began "deleting with extreme prejudice" and rewriting. Even so, I still had to read and understand the code I was deleting or replacing, and was constantly thinking like this: https://www.youtube.com/watch?v=vbr9akNELdc (Yep that's Airplane! and you probably won't recognize the actor who 28 years later would play hitman/bodyguard Mike Ehrmantraut on Breaking Bad.)
Eventually I re-did the important parts and let the rest fall by the wayside. I didn't attempt to duplicate all the functionality embodied in that mess. It took 2 years but I remember the day I finally deleted the last piece of shitcode. Management was behind me all the way, because they were aware of some of the issues with my predecessor, plus over time they've become content for some reason to kind of just take my advice about this and other things almost implicitly. So I was lucky in that way; I was free to tackle it how I saw fit. They didn't really have much choice anwyay though, for the kind of money I was making at the time! (not great)