Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Codebase at my work is a complete mess, what should I do?

news.ycombinator.com

Post reply on HN
Print view View original

171–180 of 346 posts

Re: Ask HN: Codebase at my work is a complete mess, what should I do?

#171

Post by akavel »

haney wrote: post #104

Start writing tests, change no production code. You need to understand how it works (by reverse engineering its behavior with tests you’ll learn this) and you need to verify your changes don’t accidentally change existing behavior unless the existing behavior is verifiably wrong, and hey, you may find instances of this too, but don’t start making changes until you have a suite of tests that can spot behavior changes.…

I once did a major cleanup at the start of my career. The above advice is closest to what proved successful to us, together with the response by JohnBooty https://news.ycombinator.com/item?id=17825093.

In our case, I think we didn't write a lot of tests, because we didn't know they're so useful then. But much later I did a few ports of FOSS software between programming languages, and comprehensive test suites were absolutely godsend in those cases. So, if you can, try to write tests as first thing indeed.

Other than that, we took a kind of "organism fighting a cancer" approach. In a spaghetti codebase, we tried to find some smallest possible islands of the most isolated code (a lot of detectivistic work). Then try to improve the isolation even more — slowly engulfing the "tumor" in a more reasonable API. Once we had a somewhat acceptable API, with mostly well understood semantics, rewrite the internals of the tumor from scratch. Rinse and repeat.

Notably, as mentioned by JohnBooty, we did talk this with management. It made our product release late by ~1yr. The argument was that there was a particular critical bug, which would result in lost consumer data. This one bug was found very close to original release date, and opened our eyes to the horrors in the codebase (actually, a big part written by a subcontractor).

Sorry if the reply is somewhat chaotic, I didn't have much time to write it.

EDIT: Also, I believe the term "technical debt" is reasonably good when talking with management/owners, as it has correct connotation of an investment at early stage, which however has to be repaid later at a cost.

Re: Ask HN: Codebase at my work is a complete mess, what should I do?

#172

Post by akuji1993 »

Even if I trust you about the code being really bad, I'd still advise you to read this: https://www.joelonsoftware.com/2000/04/06/things-you-should-...

Joel makes it pretty clear that all codebases go through some kind of "maturing" where the quality is lacking, usually. It kind of made me change my opinion and approach to old codebases. Still, I think /u/freetime has the correct idea in not jumping into refactoring the first weeks of your job. Makes you look like a jackass (I made the same mistake at my current job). It might hurt, but I'd also advise to wait with improvements.

Re: Ask HN: Codebase at my work is a complete mess, what should I do?

#174

Post by Animats »

Well, first get everything under source control, if it isn't already. Get the build process organized so anyone can do it.

Start adding comments without changing code. Any time you touch anything, comment that area as you figure it out.

If you find unused code, put something like #ifdef OBSOLETE around it, rather than removing it immediately, and stick in "assert(false)" where something is unreachable.

Re: Ask HN: Codebase at my work is a complete mess, what should I do?

#176

Post by whatupmd »

Stay or go. That is your first decision.

If you stay: After 3 months you should have a good feel for the project. After 6 months you should be able to regularly make small contributions.

After 9 months: Spend 10% of your time documenting the problems you see and the changes that might solve those problems. Spend 10% of your time planning another work project that is unrelated to the main project. Spend 20% of your time honing a skill you want to learn. Spend the remaining 60% doing the work you were hired for.

After a year, if you feel the same way, discuss with mgmt + senior the problems you’ve been documenting and if the changes you suggest are something that should be implemented.

Iterate.

Re: Ask HN: Codebase at my work is a complete mess, what should I do?

#177

Post by groestl »

This thread is full of valuable advice, and you should probably bookmark it and read all of it again at times. But if I had to pick a single advice as the most important one: lose the term "rewrite". It's way to easy to get a deadline or time budget attached, and that's a very bad place to be in, especially if people start to think the rewrite stalls regular development. Improving an existing codebase is not a task, it's a process. You make it part of your everyday routine, deliver features on the way, and your budget for improvement is virtually unconstrained.

Re: Ask HN: Codebase at my work is a complete mess, what should I do?

#178

Post by arendtio »

caymanjim wrote: post #87

Don't fix things just for the sake of fixing them. Let new features, bugs, or necessary performance improvements drive your changes. Keep your changes small and focused. You need to ensure that you're delivering business value with each change, rather than embarking on an overwhelming, open-ended task. This is critical if you want the business to support your effort. It demonstrates pragmatism. It will shrink the sco…

I don't agree with the first part. I have worked enough time on the management side to understand that management is always driven by business value (it's their job). So your point 'Let new [...] drive your changes' is valid to some extent. But business value doesn't always mean that you need new features to justify working on a project. Sometimes it is possible to justify working on something just by explaining technical debt and how much time it will cost in the future (e.g. slow you down).

Working in an unstable environment can drive you crazy as a developer and lower your productivity enormously. So if you don't talk about the issues in the code base with the management, they might wonder why you have lower output then others and classify you as a slow programmer.

Instead, I think you should bring the facts to the table (slow down factor (number of bugs, time to trace them down), risks (likelihood of production issues)), in terms of how much time it costs to work within the current code base and let the management decide on how to proceed (make sure to bring a recommendation). If they are willing to let you spend time on improving the quality, try to modularize it so that if the rewrite will be stopped at any time, the time you spend refactoring it helps you in the future. While doing so, show respect to the programmer that worked with that code base in the past (even if she/he create that mess). You don't know under which conditions she/he had to work, how she/he learned to programme or what her/his life looks like outside the job.

The management basically has these options:

1. just minor changes to the code base: no rewrite, no hidden quality enhancements (might be a valid option if an alternative software is being developed already). 2. hidden improvement: no rewrite, but you are allowed to spend some extra time to improve the parts you are working on. 3. restructuring of the code base and systematically writing tests for different modules (recommendation). 4. complete rewrite: unlikely to happen unless it is cheaper than 2 and 3.

If the management decides to continue with option one or two, do the best you can under the circumstances be pragmatic as caymanjim wrote. Make sure to include option four so that the management sees the full spectrum of options at hand.

Re: Ask HN: Codebase at my work is a complete mess, what should I do?

#179

Post by roel_v »

Here's a hard earned tip. The first few months, nobody's going to expect much from you anyway. Try to stretch the time you're 'getting up to speed with the code' as long as possible. But in that time, write as many tests as possible. Don't tell anyone unless they ask; if there is no testing culture, they'll think you're just wasting your time on it. Then at some point you will be expected to start delivering value. At that point, you can start making changes (refactoring where necessary) without fear. This will let you grow your status in the organisation until you have a reputation of being the guy that can get things done and doesn't complain about how bad everything is and how everything is someone else's fault when he's assigned a task. At that point, you can start making others write and maintain tests while you take control of keeping oversight of improving the code base quality.

Do not be tempted into 'rewrites' because you're setting yourself up for failure.

It's a long play, yes. If you're feeling the way you describe just from the current state, you're probably not senior enough to do it. It requires much more than just technical skills - those are abundant, it's not what you can build a career on. It's a bit Machiavellan, I guess, but in the end, everyone wins - but you need to have the Vision that others are not able to understand, so you have to find ways to make it happen anyway, in adversarial circumstances.

Good luck.

Re: Ask HN: Codebase at my work is a complete mess, what should I do?

#180

Post by alexchamberlain »

Two thoughts came to mind when reading this.

First, remember trust is normally earned, rather than assumed. There is a careful balancing act between getting to know the code base, the culture and the team vs being proactive from day 1. If they're completely lacking tests, write tests for the sections of code you're working on; the sections you fully understand. There's a few books on the subject, but they all boil down to don't try and tackle everything at once. Build an understanding and ensure new code is well tested.

Furthermore, make sure you understand the background. Is this a prototype that has been deployed to production? Is your colleague a "starter"; great at shipping new ideas, but stability and maintenance are not their strong points? Do they simply know no better? Why are things the way they are? The solution varies a lot.

Lastly, age, experience and knowledge are often confused in this industry; try to keep them separate. I manage a team of 6 and I'm the second youngest member (late twenties), but the most experienced in my product. It takes a mix of everything to make a good team.

Post reply on HN