Hacker News Reader

Comment by jmathai | Hacker News Reader

The post is promoting building applications in a loosely coupled but highly cohesive manner. It mentions using libraries when appropriate and not duplicating code.

I agree with this but it requires a lead who's good at architecting such a codebase. That person also needs to stay with the company for a long time because they're essentially replacing the "framework" with bespoke human logic.

I think many, maybe most, companies that try to build loosely coupled and highly cohesive code bases end up failing and it ends up being a mess.

Frameworks aren't perfect. But know what's less perfect? Humans. The really big frameworks try and take the human component out and replace it with codified conventions.

View on HN

> I think many, maybe most, companies that try to build loosely coupled and highly cohesive code bases end up failing and it ends up being a mess.

Companies who try to build any type of codebase end up with a mess. Always. No exception.

There is no reason to pretend software development's natural tendency to increase entropy is exclusive to a specific type of software architecture. In fact, some developers even go to the extent of criticising software architects for existing, because they have "rules" and enforce "order" and "organization".

If anything, being mindful of a specific architecture goes already a long way to fight entropy.

> Companies who try to build any type of codebase end up with a mess. Always. No exception.

I love how demonstratively wrong this is

Every single codebase doing anything nontrivial is mess. Show me a code base that you can marvel at it's beauty, elegance, and how neat and tidy everything is organized and one of two things will be true about it.

1. It has never touched the real world, real hardware, or real users.

2. All the mess is hidden in some dependencies that handle the integration points with the outside world.

You cannot escape the fact that the world is full of sharp edge cases, no perfect abstraction exists, all models of the real world are approximate, there is no architecture that survives changes to business requirements, and all assumptions made about the environment where your code runs will eventually be false, which makes a mess out of code that was once nice and tidy.

I’ve worked on a lot of open source projects and large proprietary code bases that I’d call not-a-mess. I’m not sure what that means to you, to me it means well-engineered in terms of quality criteria, rather than aesthetics, as it seems to be the case for many.

You sound very defeatist to me. I’m under the impression you’ve only worked in teams that don’t have an engineering mindset but rather throw-shit-at-the-wall-and-see-what-sticks coding sweatshops. You may want to look for a new company to regain your pride in your work..

I first thought to post some links to code bases that, in my eyes, aptly counter argue your claim.

Then I realised that you have already solidly placed yourself in a corner and are bound to defend that corner no matter what I am going to post. Since there's no objective measure of what constitutes as a mess (in contrast to what is simply not perfect) it's also easy to convince yourself that the statement always remains true.

Alas.

> I first thought to post some links to code bases that, in my eyes, aptly counter argue your claim.

...but then you realized they weren't supportive of your baseless assertion, and arguably were a hot mess as well.

"I really have proof for my argument, I swear, I'm just too petty to provide it, trust me bro". Are you serious?

I am. But the words you so freely attribute to me are not what I wrote or meant, and no amount of quotation marks around them will change that. Bro.

No shit, sherlock.

Instead of continuing the bickering, you could show us the code base, how 'bout that?

I have a truly devastating reply that this website's comment length is too small to contain.

Where do you work?

Probably in a small close-nit team working on something for no more than a year or two that will be impossible to maintain once the authors move on to greener pastures.

Infinite real world edge cases says hello.

You forgot to do the demonstrativeness, just saying it doesn't make it so.

I would love to see some demonstration of how wrong this is.

I'd rather wallow in my own mess than wade through someone else's though

That maybe true but what happens when people, including yourself, switch teams?

At some point we all wade through someone else’s mess. Hell, even your own mess revisited after a period of time is unpleasant.

The more you can do to make your software predictable and boring the less unpleasant it will be for everyone.

I actually got to a point where I don't mind my own code. Even code I wrote years ago feels natural to me when I revisit it.

And about the switching teams part. I much rather take over code that is written for our specific use cases than trying to wrap my head around some huge generic framework.

But this is the point... You don't have to "wrap my head around some huge generic framework" for every project. If you choose the right framework, it's already used in teams, projects and businesses across the world, so hiring and upskilling are far far easier than they would for a custom framework.

Until something is broken, and you need to step through 40 levels of stack (certainly no exaggeration) to try to figure out where something is happening, and where that exception is swallowed. Most often it's not the framework that is broken, but you still need to understand enough of the framework to figure out what is wrong where.

The whole point is that there won't be a mess or at least as much of it if you use a framework. How is this so lost on people here so often!

Perhaps because the framework is hiding the mess from you and you have no idea how it is accomplishing critical portions of your application.

Out of sight out of mind.

Which again is the whole point. I could care less if the auto-generated SQL isn't 100% efficient, as long as it's not getting in my way and I don't have to think about it when I do

  User.add({})

I think you need to better examine what you consider critical and maybe try to further break down the word critical for a better understanding of where to focus your time and energy while coding.

I would like to propose that if your organization has trouble making root cause analysis into usefully actionable information, that their codebase is also a mess. Because at the end of the day I think the same skills at looking at the interface of human and process are required for successful decomposition of logic to soften the interface between human and technology.

because you are flawed, you should just give up on actually owning your software

Reply on news.ycombinator.com