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

Re:Ask HN: How to be productive with big existing code base by rjf72 on Thursday February 28, 2019 @12:39AM (#19269193)

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.

[ Parent | on HN ]

Re:Ask HN: How to be productive with big existing code base by aargh_aargh on Thursday February 28, 2019 @04:09AM (#19270064)

Intuitively, I often feel the same.

Joel Spolsky argues against that: https://www.joelonsoftware.com/2000/04/06/things-you-should-...

The Mythical Man-Month as well: https://en.wikipedia.org/wiki/Second-system_effect

[ Parent | on HN ]

Re:Ask HN: How to be productive with big existing code base by Illniyar on Thursday February 28, 2019 @09:39AM (#19271543)

It's worth mentioning that what both of these are talking about are rewrites using a new project in a all or nothing stake. Iterative rewrites are not subject to these caveats.

[ Parent | on HN ]

Re:Ask HN: How to be productive with big existing code base by cbanek on Thursday February 28, 2019 @12:48AM (#19269222)

I agree with both you and the parent that sometimes rewriting the code is best, and you can usually make a superior solution by utilizing lessons learned from the first version, either from rewriting or iterative improvement.

But I think the mindset to approach a codebase with is to be open to it, rather than dismissive of it. Code is such a stylized thing, and everyone has their own style and loves their own style most of all. It's hard and takes time to understand someone else's code (a vastly underrated skill IMHO). The temptation to find some reason to start over when it isn't exactly necessary is usually quite high.

Once you understand what the current code is doing, then you really have to apply your good skills on what parts to save, and what to change, and how that relates to the schedule and cost.

Also in a corporate setting, there can be political / organizational friction to throwing out code or starting over (and it rarely makes you friends with whoever wrote the first version).

[ Parent | on HN ]

Re:Ask HN: How to be productive with big existing code base by gorbachev on Thursday February 28, 2019 @03:13AM (#19269840)

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.

[ Parent | on HN ]

Re:Ask HN: How to be productive with big existing code base by yoz-y on Thursday February 28, 2019 @04:14AM (#19270079)

I'd say that you can make a better design, sure. But the implementation will almost always be worse at least for some time. An old codebase carries tons of bug fixes and workarounds, they may not be elegant, but they make it more stable.

A new reimplementation, albeit cleaner, will almost always be buggier.

[ Parent | on HN ]

Re:Ask HN: How to be productive with big existing code base by alexis_fr on Thursday February 28, 2019 @07:25AM (#19270851)

I think the book « The Pragmatic Programmer » advises to do refactorings twice: First refactor to see what it’s hitting, then rollback. Once you know what you’re hitting, format it and clear it up, commit, then perform the big refactor, and you have much better chances of going smoothly.

[ Parent | on HN ]