5 ms·
The post is promoting building applications in a loosely coupled but highly cohesive manner. It mentions using libraries when appropriate and not duplicating co
by jmathai 4y ago
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.
- convolvatron 4y agobecause you are flawed, you should just give up on actually owning your software
- arinlen 4y ago> 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.
- meesterdude 4y ago> Companies who try to build any type of codebase end up with a mess. Always. No exception. I love how demonstratively wrong this is
- Ma8ee 4y agoI would love to see some demonstration of how wrong this is.
- Spivak 4y agoEvery 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.
- jstummbillig 4y agoI 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.
- RamblingCTO 4y ago"I really have proof for my argument, I swear, I'm just too petty to provide it, trust me bro". Are you serious?
- deleted 4y ago[deleted]
- jstummbillig 4y agoI 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.
- RamblingCTO 4y ago
- singron 4y agoWhere do you work?
- soheil 4y agoProbably 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.
- langsoul-com 4y agoInfinite real world edge cases says hello.
- soheil 4y agoYou forgot to do the demonstrativeness, just saying it doesn't make it so.
- 8n4vidtmkvmk 4y agoI'd rather wallow in my own mess than wade through someone else's though
- Lio 4y agoThat 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.
- Ma8ee 4y agoI 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.
- willsmith72 4y agoBut 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.
- Ma8ee 4y agoUntil 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.
- soheil 4y agoThe 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!
- hinkley 4y agoI 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.