3 ms·

This is a complaint I hear a lot, and it's very valid. My question is: which frameworks protect against this "behemoth of tech debt" inevitability that comes wi

This is a complaint I hear a lot, and it's very valid. My question is: which frameworks protect against this "behemoth of tech debt" inevitability that comes with using rails? I've worked with large rails, django, and node apps, and none of them have felt particularly enjoyable to work with from a feature development standpoint once a certain scale is achieved. This doesn't feel like a rails-specific problem to me, but that's just based on my experience.

whalesalad 8y ago
None. This is not a Rails problem or a Django problem. If you're coming to that conclusion you haven't been building software long enough. You can architect clean software in any language. What happens is this: you learn a new framework (or sometimes learn a new framework AND the corresponding language it is build in). You don't know what is idiomatic. You haven't made mistakes yet. You're making progress on your idea and getting shit done though, so it doesn't matter. Long story short: you don't know any better. Hindsight is 20/20! Next time around you try something new and blame your old woes on the framework. This time around you've learned a thing or two about how to properly organize your code. You've been bitten by a third party tool that stopped being maintained. You've grown and learned and become more wise. But... you still blame your past issues on the old framework. At some point you've been doing this for decades and you start to learn about abstract patterns that are not coupled to frameworks: service-oriented design, domain-driven design, CQRS (command driven systems), event buses and event systems, clean architecture, separation of concerns, SOLID principles, etc... ONCE you are at that point, you will begin to realize that NONE of the frameworks are going to solve these issues and NONE of them are more or less prone to causing tech debt. Long story short: keep building software and focus on principles not frameworks. Read up on SOLID. It just takes time to get better and to start building things that don't encourage debt. Another thing to note: tech debt is not bad. People throw that term around all the time and use it as a proxy for "messy code". Nothing in life is free. Everything is a balance. Perfectly architected software vs move fast and prove the business and make a profit? Pick one. You're going to acquire some amount of tech debt along the way. It's like real debt... sometimes you gotta accrue monetary debt to make progress elsewhere.
robbrit 8y ago
This is a software problem, not a Rails or even a Ruby problem. I've seen Java/C++/C# systems collapse under their own weight just as often as Ruby/Python/PHP because they don't invest the time in cleaning up the tech debt as they grow. Parent is definitely right, projects that are "designed right from the beginning" do not exist in reality. Everything has unknowns in the future, and it is better to be flexible and adapt the code base to them as they come rather than trying to plan everything out from day 1. Static typing does help with these adaptations, but it doesn't compensate for a lack of diligence in keeping the code clean as the software grows.
w8rbt 8y ago
I think the concepts built-into Go make building very large programs much more approachable. That was one of the design goals. I'm not sure Ruby, Python, Javascript, etc. were really designed for large scale development (although people use them for that). I think this is the primary reason so many people complain about technical debt, hitting the wall/limit, needing to refactor, etc. And looking for another language. Their tools just were not meant to scale that large. "Go was deliberately designed from the start to support large scale programs implemented by hundreds or thousands of different programmers. Those kinds of programs are written at Google, and Go was designed to be used to write programs at Google." - Ian Lance Taylor More from Ian here - https://www.quora.com/Will-the-Golang-code-become-unmaintainable-for-large-code-bases https://www.quora.com/Will-the-Golang-code-become-unmaintain...
Mc_Big_G 8y ago
which frameworks protect against this "behemoth of tech debt" Yeah, that's basically what invalidates the assertion. There's no language or framework that guards against the complexity of a large code base. Period.
tytytytytytytyt 8y ago
> I've worked with large rails, django, and node apps Something that uses a statically typed language?

whalesalad 8y ago

None. This is not a Rails problem or a Django problem. If you're coming to that conclusion you haven't been building software long enough. You can architect clean software in any language. What happens is this: you learn a new framework (or sometimes learn a new framework AND the corresponding language it is build in). You don't know what is idiomatic. You haven't made mistakes yet. You're making progress on your idea and getting shit done though, so it doesn't matter. Long story short: you don't know any better. Hindsight is 20/20! Next time around you try something new and blame your old woes on the framework. This time around you've learned a thing or two about how to properly organize your code. You've been bitten by a third party tool that stopped being maintained. You've grown and learned and become more wise. But... you still blame your past issues on the old framework. At some point you've been doing this for decades and you start to learn about abstract patterns that are not coupled to frameworks: service-oriented design, domain-driven design, CQRS (command driven systems), event buses and event systems, clean architecture, separation of concerns, SOLID principles, etc... ONCE you are at that point, you will begin to realize that NONE of the frameworks are going to solve these issues and NONE of them are more or less prone to causing tech debt. Long story short: keep building software and focus on principles not frameworks. Read up on SOLID. It just takes time to get better and to start building things that don't encourage debt. Another thing to note: tech debt is not bad. People throw that term around all the time and use it as a proxy for "messy code". Nothing in life is free. Everything is a balance. Perfectly architected software vs move fast and prove the business and make a profit? Pick one. You're going to acquire some amount of tech debt along the way. It's like real debt... sometimes you gotta accrue monetary debt to make progress elsewhere.

robbrit 8y ago

This is a software problem, not a Rails or even a Ruby problem. I've seen Java/C++/C# systems collapse under their own weight just as often as Ruby/Python/PHP because they don't invest the time in cleaning up the tech debt as they grow. Parent is definitely right, projects that are "designed right from the beginning" do not exist in reality. Everything has unknowns in the future, and it is better to be flexible and adapt the code base to them as they come rather than trying to plan everything out from day 1. Static typing does help with these adaptations, but it doesn't compensate for a lack of diligence in keeping the code clean as the software grows.

w8rbt 8y ago

I think the concepts built-into Go make building very large programs much more approachable. That was one of the design goals. I'm not sure Ruby, Python, Javascript, etc. were really designed for large scale development (although people use them for that). I think this is the primary reason so many people complain about technical debt, hitting the wall/limit, needing to refactor, etc. And looking for another language. Their tools just were not meant to scale that large. "Go was deliberately designed from the start to support large scale programs implemented by hundreds or thousands of different programmers. Those kinds of programs are written at Google, and Go was designed to be used to write programs at Google." - Ian Lance Taylor More from Ian here - https://www.quora.com/Will-the-Golang-code-become-unmaintainable-for-large-code-bases https://www.quora.com/Will-the-Golang-code-become-unmaintain...

Mc_Big_G 8y ago

which frameworks protect against this "behemoth of tech debt" Yeah, that's basically what invalidates the assertion. There's no language or framework that guards against the complexity of a large code base. Period.

tytytytytytytyt 8y ago

> I've worked with large rails, django, and node apps Something that uses a statically typed language?