You should read The first 3 chapters of Martin Folwer’s Book on Refactoring. Also, if you have a product owner work with that person so they understand the situation. If you have a lead the week their guidance. Lastly, learn from the last person’s mistake and document the code so you can move to the next project. Likely that part of the code is a mess too...
Ask HN: Codebase at my work is a complete mess, what should I do?
71–80 of 346 posts
Re: Ask HN: Codebase at my work is a complete mess, what should I do?
#72Yah i went to a big name host and found the same thing. I was fooled into joining because I met with a data scientist and an "experienced web developer" without actually looking at their code. Long story short, 2 years later it was the most frustrating experience ever and I left, hating the code the entire time. I was paid a lot and the people were cool so that made me hang around but the culture promoted hanging on…
> I was fooled into joining because I met with a data scientist and an "experienced web developer" without actually looking at their code. Is it typical to be able to look at a company's code before signing up? After having a similar experience, I wish I could make that a standard part of my interviewing process. (Brief backstory: I would never in 1000 years have taken my first development job if I had seen the code…
When we first identify partners or clients, the interview is not unlike a job interview, but one where both parties are the applicant and interviewer. I cannot count the times when someone from the other side tells me about best practices in coding, CI, covering tests and version management, after which, on inspection of their codebases, they actually do none of these things. The guy at the meeting stage was a higher up tech manager/C(TI)O usually who read all the books and articles but the team is not following those same practices because of various reasons (usually intense time pressure).
We now have to demand to see the codebases we are going to work with/against first. Even if we only touch the API in some cases; if the API is built on quicksand then we risk spending a lot of time building something that is not viable but that might not be immediately clear.
Re: Ask HN: Codebase at my work is a complete mess, what should I do?
#73As a system matures it is easy to see common code and abstractions. Don't blame the previous guy.
Don't be tempted to start a new shiny clean system. This almost never works (unless in demise cases) and you'll be playing catch up with features on the original system for the next 10 years.
As others have said. You have to write tests, this will cover your back and you'll understand the codebase back to front once you have - Testing/Interfaces/Simplify/Naming.
Remember, all the business logic is there. At least you don't have to do the hard part... this is a cleanup operation.
Re: Ask HN: Codebase at my work is a complete mess, what should I do?
#74This sounds normal. Back in the 90's and early 2000's, almost nothing had automated tests. Miraculously, things still got done by manually testing. On the other hand, I worked at shops where every getter and setter had a test. Not much got done there.
> Miraculously, things still got done by manually testing.
That is still very normal and not very miraculously considering it happens all the time and very large companies run on this practice.
Although I am a fan of automated tests, I work with enough codebases that are robust and have been working for over 10 years that have no tests and others with a lot of test that are still fragile and miserable to work with. It is not all that black and white but you imply that as well with the getter/setter tests.
Re: Ask HN: Codebase at my work is a complete mess, what should I do?
#75> I started "repairing" the project but there're no tests to check whether my adjustments are correct.
First you need to discover all associated business requirements. You need to create all the missing tests, but you cannot do that without knowledge of the business requirements. Get these requirements and get them in writing. Find them. If you cannot do this stop. Stop now.
> I'm so frustrated and depressed by it.
This is ultimately the difference between a newb, a mid, a senior, and a super duper ninjitsu rockstar.
A newb will just accept bad code and work on top of it with their own flavor of bad code. A newb doesn't know any better and everything is frustrating all the time even if the code were awesome.
A mid has just enough experience to be dangerous. Sometimes a mid suffers from Dunning-Kruger Effect in that their personal perception of the existing code isn't how they would do it and their way is soooooo superior. The mid level developers who don't suck prioritize tests and security above everything else. They know they aren't fabulous architects, but they also have some idea of where code applies known bad practices and known best practices and can work from there. A good mid isn't going to rewrite the code base, because the risk is too high. Instead they will make the most minor of best practice corrections confined to the areas they have to touch anyways.
A good senior understands concepts like automation, graceful degradation, progressive enhancement, scope, recursion, and so forth. They know how to make the code work for them. It isn't about writing a few lines of code to solve a single business requirement. It is about writing a few extra lines of code to allow the current business requirement to scale to the next thing so less work must be performed in the future and less regression occurs when the business direction shifts.
The super awesome developer takes automation to a whole new level. Documentation is automated and therefore always up to date and accurate. Debugging tools are already embedded as part of the validation process so that when validation fails you spend less time on research or resolution. Dependencies are few and well managed, because nothing pisses people off more than corruption from outside the code you own. In the end top developers value the time of other developers more than anything else and will write their code accordingly. It isn't so much about the readability of the code as it is speed of maintenance cycles moving forward.
If your job is actually important to you then you will find an acceptable level of risk that you are willing to own and have the time to practice against. Getting this right shows that you care to do the right thing without making an ass of yourself at the company's expense.
Re: Ask HN: Codebase at my work is a complete mess, what should I do?
#76I moved mostly to real estate after running an IT company for 15 years. You know what they say in this field about 19th century buildings, which are certainly technically inferior to newly constructed houses? „At least these buildings have been standing for a century without collapsing“. IOW, the code you are seeing is at least in production, while many other companies did things differently (perhaps in a prettier or more maintainable way) and failed.
Sorry if this isn‘t helping, but have some respect for a codebase that seems to be working. And write lots of tests before touching it.
Re: Ask HN: Codebase at my work is a complete mess, what should I do?
#77I'd say just double down and have a job for life, https://github.com/Droogans/unmaintainable-code
Re: Ask HN: Codebase at my work is a complete mess, what should I do?
#78I moved mostly to real estate after running an IT company for 15 years. You know what they say in this field about 19th century buildings, which are certainly technically inferior to newly constructed houses? „At least these buildings have been standing for a century without collapsing“. IOW, the code you are seeing is at least in production, while many other companies did things differently (perhaps in a prettier or…
Lindy effect: The Lindy effect is a concept that the future life expectancy of some non-perishable things like a technology or an idea is proportional to their current age, so that every additional period of survival implies a longer remaining life expectancy.
Re: Ask HN: Codebase at my work is a complete mess, what should I do?
#79So you're the new guy that's been assigned to this project...possibly at the request of the current developer who desperately needs help...possibly because it's the project that existing staff don't want to work on...possibly to learn the project so the current developer can be moved to other projects.
Every software company has these projects and many developers have been in your position. As long as the software is still functional and is profitable then management don't care how bad things are under the hood (try explaining it to someone who only sees a working/functional UI). The fact a new resource (you) has been assigned suggests it's still a valuable project.
Unless management are the ones giving the go-ahead on the rewrite then I wouldn't bother. Rewrites are very risky, time-consuming and make no money for the company. However long you think it will take...double it. You're a mid-level developer, a rewrite needs to be planned and led by an experienced senior developer.
Your best bet might be patience...try ride it out and hopefully be moved onto other projects. In the meantime you get experience. It's how you handle the adversity that could prove more valuable.
Re: Ask HN: Codebase at my work is a complete mess, what should I do?
#80Is it buggy? Is it insecure? Is it slow? If the answers to those questions are no. Then you the problem and you should look for employment elsewhere. You are unhappy in that job, and you rewriting the codebase would potentially make the above questions answer to a YES, inflicting damages in the company. Now, if the above questions have yes as an answer. Talk to your manager, explain how it won't scale, how it is hack…
A software project can be fast, reliable, and secure while also being extremely poorly engineered and extremely difficult to maintain and extend.