Ask HN: How to be productive with big existing code base • Hacker News Board

Re: Ask HN: How to be productive with big existing code base

#111

Post by rdiddly » Thu, Feb 28, 2019, 8:10 AM UTC

ummonk wrote: post #98

cbanek wrote: post #6

My #1 rule for existing codebases: Just because you wouldn't have done it the way they did doesn't mean they did it wrong. I think it's developer nature to look at a huge pile of code that someone else wrote and immediately think: "This is a pile of crap. I can do better, so the first thing to do is rewrite all of this, my way (which just so happens to be _The Right Way_)." Figure out what you're trying to do, and wh…

I mean it's pretty normal for a long existing codebase to be have had a lot of poor (in hindsight) design / architecture decisions in it and feel that if you got to write it with the benefit of hindsight you'd do a better job. It's only hubris to think you can do it in a week, rather than requiring as much time as the original (but with a better resulting codebase).

If your predecessors were indeed total hacks at programming, you can get all of the above. But it's a dubious pleasure. My head sustained a lot of scratching and smacking and my face was over-palmed.

Re: Ask HN: How to be productive with big existing code base

#112

Post by jamesmus » Thu, Feb 28, 2019, 8:11 AM UTC

fsloth wrote: post #89

marcell wrote: post #9

Earlier quoted context omitted.

I dunno, I've seen quite a few piles of crap in my day as a SWE. The bar is not that high to do better.

The point is "doing better" is pointless unless it serves a specific business value. Beauty is not a sufficient reason to refactor a code base in production - because refactor always has risks, and those risks should be offset always by some tangible expected reward.

Definitely. "Is it good enough for the business?". If yes, then leave it alone. Try to add new features in a safe way with automated tests.

I once worked a contract where it was expressly forbidden by the dev manager to refactor any code unless it was demonstrably necessary to support a new feature. Not much fun for devs at times but I respect the reasons behind the decision (esp. as it was a derivatives trading platfom and it can get pretty expensive pretty quickly when they go wrong).

Re: Ask HN: How to be productive with big existing code base

#113

Post by gorbachev » Thu, Feb 28, 2019, 8:13 AM UTC

rjf72 wrote: post #85

Illniyar wrote: post #84

Earlier quoted context omitted.

I don't think that's the right mindset to approach it. My experience usually is that it is a pile of crap, and I can do better, but I probably would make the dame pile of crap if I was under the same conditions of the original coders (time constraints and scope creep usually) So change it if you can, but respect those who were there before

I'd also add here that hindsight is 20/20. You don't really know what you're creating until it's created. Do it again a second time when you know exactly what you're getting at the end, alongside the challenges you'll face in the process of such, and you'd be able to do it faster, cleaner, and just overall better.

Exactly!

The first version of anything almost certainly ALWAYS sucks. Usually the only way that doesn't happen is if the team developing the solution has prior knowledge of some kind...having built a similar solution before.

I used to always hate consulting for this reason. The company I was working for was always doing greenfield development for clients. We never, ever got to do v2, because the projects always transitioned to clients' teams. I can't remember a single project I was working on that I was happy with.

Re: Ask HN: How to be productive with big existing code base

#114

Post by Jach » Thu, Feb 28, 2019, 8:13 AM UTC

blub wrote: post #103

Jach wrote: post #22

Earlier quoted context omitted.

There's a term for this, Chesterton's Fence: https://en.wikipedia.org/wiki/Wikipedia:Chesterton%27s_fence > let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, "I don't see the use of this; let us clear it away." To which the more intelligent type of reformer will do well to answer: "If you don't see the use of it, I certainly w…

I've managed to finish reading the chapter with the example refactoring from Fowler's book before putting it down as parody. He's part of a design school that likes to pulverise code into tiny functions with the goal of having code that consists only of assignments and function calls, reading like instructions in English to the computer. Whoever was indoctrinated by Robert Martin, Martin Fowler & co should read Ouste…

Thanks for the pointer to Ousterhout, I don't think I've heard of him before but a lot of the Tcl people have put out good stuff.

Uncle Bob and friends definitely form their own "school". I think they call the "functions and assignment" style "Newspaper style", since for them it's kind of like reading a newspaper. Following it you can actually get a long way towards the dream of "self documenting code". I'm happy when people who believe in some specific school of thought get it to work for them, and even if I disagree on things at least there's consistency.

It's still never as clear as a literate program, though. And while Uncle Bob has been upgrading by learning Clojure, a lot of that school's work has assumed OO-in-the-style-of-Java5/C++98 environments. And to be fair that's a lot of the mass of legacy code we unhappily get saddled with. I think their work is less applicable and there are other schools to listen to when you have different languages or programming methods (FP, declarative, OO with a MOP, etc.).

I read the Clean Code book finally not too long ago, and while I've never argued with a book so much, there is value in it, and some programmers would do much better than their current flailing to follow its approach exactly. But these guys aren't my personal programming heroes, I'd rather be like a Norvig than a Jeffries (even if the latter is a perfectly acceptable engineer). But I can usually find value in all their works; philosophically I'm aligned with Bruce Lee, I'll take what I think is valuable and discard the rest.

Re: Ask HN: How to be productive with big existing code base

#115

Post by cc81 » Thu, Feb 28, 2019, 8:14 AM UTC

crimsonalucard wrote: post #83

cbanek wrote: post #6

My #1 rule for existing codebases: Just because you wouldn't have done it the way they did doesn't mean they did it wrong. I think it's developer nature to look at a huge pile of code that someone else wrote and immediately think: "This is a pile of crap. I can do better, so the first thing to do is rewrite all of this, my way (which just so happens to be _The Right Way_)." Figure out what you're trying to do, and wh…

Sometimes the initial design truly was a mistake.

Yes, and sometimes the people are fully aware of that as well. But even a shitty designed piece of code that has been running in production for year will have ironed out most of its bugs. There might be other designs that would be more maintainable but refactoring to reach that might be an investment that the company is not willing to make.

Re: Ask HN: How to be productive with big existing code base

#116

Post by speedplane » Thu, Feb 28, 2019, 8:15 AM UTC

rdiddly wrote: post #111

ummonk wrote: post #98

Earlier quoted context omitted.

I mean it's pretty normal for a long existing codebase to be have had a lot of poor (in hindsight) design / architecture decisions in it and feel that if you got to write it with the benefit of hindsight you'd do a better job. It's only hubris to think you can do it in a week, rather than requiring as much time as the original (but with a better resulting codebase).

If your predecessors were indeed total hacks at programming, you can get all of the above. But it's a dubious pleasure. My head sustained a lot of scratching and smacking and my face was over-palmed.

Sometimes a very dubious pleasure. I work at a company where another product team decided to rewrite the entire product from Angular 1 to Angular 2 because it was so much better. I was shocked and dismayed, but didn't say much because I didn't feel like starting a fight I would lose, and it would suck me into a project that wasn't my primary focus.

Re: Ask HN: How to be productive with big existing code base

#117

Post by walterstucco » Thu, Feb 28, 2019, 8:19 AM UTC

Jtsummers wrote: post #66

beachy wrote: post #43

Earlier quoted context omitted.

The counterpoint to Chesterton's Fence is the psychology experiment with the monkeys, the stairs and the banana. This is long but very pertinent to the "that's just how we do things around here" attitude: > This human behavior of not challenging assumptions reminds me of an experiment psychologists performed years ago. They started with a cage containing five monkeys. Inside the cage, they hung a banana on a string w…

I don't see how that's a counterpoint. Chesterton doesn't say "don't change it, that's how it is and shall be." He's saying, "Question why it's present before you attempt to change it." Looking around, there were no obvious livestock or other reasons for the fence. But perhaps they're only there six months out of the year. Ok, make the fence a gate, and not a fence, so it can be opened more easily. Maybe it's no long…

Because usually if you're working on someone else's giant legacy codebase that is completely new to you, it's because the original maintainer(s) is not there anymore to help, for whatever reason.

It becomes nearly impossible to understand what's going on and why without breaking something.

I've been doing this for the past 5 years as a consultant in banks and insurance companies.

The only way to know "what's is its use?" is remove it and wait for someone to call for a problem.

Most of the times this trick doesn't work, because stuff breaks all the times and it's really hard to tell if you broke it or if it was broken in the first place.

Like the monkeys, users of the software have changed over time and they kept doing things "the way we always done it", sometimes a new monkey comes in, does something differently and discover a bug that's been there for years, unnoticed, because no one else climbed the stairs anymore.

Re: Ask HN: How to be productive with big existing code base

#118

Post by fsloth » Thu, Feb 28, 2019, 8:21 AM UTC

Based on my years of experience in working with a millions-of-locs over decades codebase:

Be aware of the abstraction fallacy: developers are often guided by this insane notion that they can get rid of accidental complexity by wrapping it away behind an abstraction layer. You can't. It's better to suck up to the complexities of the existing system, and prefer explicit, procedural copy-and-pasting than trying to invent your own abstraction layer on top.

The problem with the after-the-fact abstraction layer is that if the original team members are not available, you are likely not in possession of the whole theory of the software. Hence it is not likely you can in the beginning choose the right abstractions.

The correct way - if possible - to simplify existing code is to refactor the code itself.

The specific anti-pattern you will reach by following the false abstraction strategy is the lasagna architecture: https://herbertograca.com/2017/08/03/layered-architecture/

Two literary works that helped me enormously to grok working with legacy code and programming in particular:

* Peter Naur's paper "Programming as theory building" - this was an amazing eye opener to me. It specifically highlights several problems that may arise when working with legacy code when the original developers have left the building.

* Michael Feathers: Working Effectively With Legacy Code - not to be read necessarily as a "how to" recipe book, but rather as a collection of philosphies and techniques to utilize when faced with a huge in-production codebase. It can be read as a recipe book if the examples match your situation, but that's not the point.

Re: Ask HN: How to be productive with big existing code base

#119

Post by dvlsg » Thu, Feb 28, 2019, 8:29 AM UTC

nisa wrote: post #17

I have a similiar problem like you, except it's Java and more like 15 years old... What helped? Using a debugger and stepping through the code was useful, it's more a less a REST-API here (build ontop of the system, before it was SOAP, etc.pp) and I've just used some heavily used endpoints and stepped through all the way... Another huge boost in understanding was using flamegraphs (not sure what's hip for nodejs mayb…

I've been using flamebearer to get flame graphs from node. It was silly how easy it was to use. Highly recommend it.

https://github.com/mapbox/flamebearer

Re: Ask HN: How to be productive with big existing code base

#120

Post by rdiddly » Thu, Feb 28, 2019, 8:33 AM UTC

It's not exactly a guiding principle, just more of an analysis & learning technique: Get ahold of a big piece of drafting paper, or a whiteboard, or one of those big-ass pads of paper they're always putting on an easel for silly brainstorming sessions. Something physical, big, writable, and not a computer. Set it up or pin it up or tape it up, semi-permanently, and use it daily to diagram and map out each new thing you learn about the system and its interrelationships. I'm assuming here that you have the space to set something like that up. If you don't, you're in a 3rd world programming situation and you have my sympathies, but you can always do something graphical within the computer, too, especially if you have a big screen or multiple screens. I just have always found it quicker to do it in a physical medium.