Comment by lukan | Hacker News Reader

Comment by lukan | Hacker News Reader

Parent Full thread

"Any code that does a lot of useful and complex things must be an arcane, barely maintainable mess that can only be understood by deep study."

"Every code base I have ever worked on was a legacy nightmare. Every "greenfield" project I joined turned into a legacy nightmare within weeks"

I am sorry to say this, but it really sounds like you were either really, really unlucky, or part of the reason why it became a mess.

Complicated things are complicated. Nothing can ever change that and it requires study to understand it.

But it still does matter a lot, how one organizes the whole thing. How it is structured, documented(!), refactored. Are there competent people in charge who understand it all and kick peoples asses if they make even a temporary mess or forget to document, or do random people make changes wherever they see fit, because a deadline is ticking?

Modularisation is usually the key. Small modules do one thing and are as seperated as much as possible with as little side effects as possible.

And if one has to ship things, it is not always possible to keep it pure and if the code is not intended to live forever then this is often fine. But if the codebase is supposed to stay, then there needs to be the time to clean up the hacks. Or don't and then you end up scared touching anything.

That being said, the technologies you mentioned, I would not like to touch either..

I think that's a bit cruel. Usually mess happens because lots of people with different ideas about the future needs and best structure meet up in the code - and it's hard to develop a consistent culture.

Also codebases get too large for any one person to refactor them into shape in the time they have each day. So you end up needing people who are responsible just for keeping things in shape.

Well, that is why I said with those words it sounds like this to me, not that he or she was in fact responsible. (at least this is what I meant)

"Also codebases get too large for any one person to refactor them into shape in the time they have each day."

Which is why modules, or subprojects were invented. Or however you want to call it, if one person is only responsible for a small part and not everyone for everything. And yes, there is also the non trivial problem of time management.

yup, but the style of the modules starts to diverge as different people maintain them.

IMO one does want people whose fulltime job is to looking at a codebase orthogonally to those who are just implementing a feature. People who make sure it builds fast, is secure tries to be consistent to some degree etc.

Many companies call teams/indivuduals like this a "cost centre" and disparage it because they are dolts.

If those code checkers are experienced programmers, who do not annoy people with arbitary guidelines and standards, then yes, this might also work. But I do not think they are always necessary as a seperate full time role, if everything works normal otherwise. And with working normal, I mean there is enough time to refactor and document and clean up and is actually done.

> Modularisation is usually the key. Small modules do one thing and are as seperated as much as possible with as little side effects as possible.

I think the key aspect is a bit different: understandability. That is, if you open two pages of random code, then can you roughly understand and follow what it roughly does?

Everything in a single package/module/directory can be quite understandable. It doesn't necessarily need to be modular, but it often does help. "Understandability" is more broad though, and also includes things such as not having weird hard to understand functions nested 8 levels deep, and things like that.

It also means not over-engineering things. "Our code is hard to understand, therefore, we need more architecture" is a fallacy I've seen a few times. The code wasn't hard to understand due to lack of modularity or architecture, but because it was just badly written unclear code.

"It also means not over-engineering things. "Our code is hard to understand, therefore, we need more architecture" is a fallacy I've seen a few times. The code wasn't hard to understand due to lack of modularity or architecture, but because it was just badly written unclear code."

For sure, if I have 10 tightly separated micro modules, just for the sake of it, then this is not helping clarity.

But if everything is an entangled mess of spaghetti code, then modularisation helps, so I do not have to look into 10 places to get what a certain function is doing.

> Modularisation is usually the key. Small modules do one thing and are as seperated as much as possible with as little side effects as possible.

100% agree. The nuance I find is that a lot times, people want to draw the lines of the module along something that's more immediately intuitive, but results in longer-term complexity.

Yes, the hard part is to define what goes inside one module. There are rules of thumb, but lots of exeptions. Taking any advice too literally can also make things awkward.

Reply on news.ycombinator.com