[oddlyaromatic]

Something that helped me a lot was somebody pointing out that it's OK for code not to be 100% DRY - sometimes things are the same at a given point in time only by coincidence, not by some inherent logical connection. It's a mistake to refactor and remove these "redundant" parts because they are not truly redundant. This helps me chill out when deciding when it is useful to add an abstraction or a separate helper function or whatever.

[ACow_Adonis]

Indeed. I don't know if it's my age or my domain, but this is something that comes up a bit on the design of my own projects and code that I try to get younger programmers to think about, and which might look weird to those who have rote learned the "don't repeat yourself" mantra, or the culture of "just import everything from modules". Sometimes it's responsible to repeat yourself if you have good reason to believe things will shift/change in the future.

A lot of young data scientists and analysts (and IT types in general) code in a way that solves the immediate problem.

But with a bit of time you start to realise that the initial brief is anyways part 1, an executive/customer will change their mind 15 times before the end of the project. What seems like the same problem now will not be the same problem in two weeks, let alone two years. Doubly so if you're interacting with entities or sources that aren't software engineers.

Over the long run, excessive modularisation creates what I'll call Frankenstein programs. You've been tasked with making a man, and what you end up with is a shambling golem made from rotting, pulsating, mutating parts all stitched and held together. If you're really unlucky, it will evolve further into the akira/tetsuo program, where you begin to lose control of the mutations until it self destructs under its own complexity.

The interesting part is that the answer to this can also be partly found in nature: you modularise and specialise, but you also make strategic choices where you're deliberately redundant.

Too much redundancy is spaghetti code. Modularisation and structure save you there.

Not enough redundancy leaves you vulnerable to changes in your environment and mutation as the project ages and evolves.

As I've gotten older, I'm placing more and more value on the later. Your mileage may vary...

[jancsika]

> Too much redundancy is spaghetti code.

Well, there's uncooked spaghetti code and cooked spaghetti code. :)

What I mean is that redundancy can be uniform, obvious, and easy to encapsulate later (if need be). Alternatively, it can be unpredictable, baroque, and difficult to reason about.