7 ms·

Every time I see anti framework posts I am forced to frusteratedly chime in. This mentality makes me fume... not all of us work on massive teams where building

• interactivecode 4y ago
  also typescript apps that haven't had active development in the last 10 years will be a pain to work with again. Toolchains need maintenance and upkeep.
• berkes 4y ago
  > And even then, whats really a "framework"? I've tried to answer that in the article. Anything that I should have clarified even more? Do note that I make an explicit distinction between libraries and frameworks. I'm not expecting a one-man-show to write the SSL libs or even the HTTP routing: there are perfect libs for that. When this HTTP library lives on the side of your app, abstracted away behind e.g. ports&adapters there really isn't any issue. It could be Sinatra, Flask or such. My article wasn't meant to argue against code-reuse, au contraire. It was meant to explain that there's "dangerous" code-reuse, and good code-reuse. That with the wrong re-use of existing code, you'll paint yourself in a corner that might easily prove impossible to get out of. Frameworks, I argue, are such code-reuse. Libraries, used and layed out in architectural patterns is, I argue, the alternative that allows for longer living projects.
  • cbsmith 4y ago
    I'll take advantage of the fact that you commented here to point out something unrelated that I found concerning in the article's reasoning: """ Companies that have.. A team that defines the standards, processes, practices, frameworks or architectures that other teams must follow. ...are amongst the lowest performers. Reversed: companies that lack this, amongst the high performers. In other words: enforced standardising the tech, doesn't pay off. This makes sense: if everyone in a company is forced to use, say, Django, for any project, regardless, there will be a lot of projects where Django is a very poor choice. """ I think that's not too far from presuming you should put armour where you find the most bullet holes in the planes that come back. You have to keep in mind that an implicit trait of all of these companies is that they are still in business, despite having a "low" ranking for the evolution of their tech team. That speaks volumes about what it takes for their business to succeed, and apparently it isn't investing in a high quality technology team. Despite that, they've survived, and it's entirely possible that having "a team defining standards, processes, practices, frameworks or architectures that other teams must follow" is the trick that's staved off their otherwise higher propensity for existential disasters. Of course, that's presuming there's any kind of causal relationship between having such a team and outcomes. In reality, the survey found that 16% of "low" companies had such a team, but 10% of mid and 7% of high companies also did. That's as compared to 15% of "low" companies that had a team that responds to tickets related to infrastructure issues, whereas only 6% of mid-level and 5% of high level issues... or the even bigger discriminant of a team that provides software delivery solutions for many feature teams through self-service APIs, which made up 3% of low teams, but 15% of mid-level teams and 23% of high-level teams. In that context, maybe having a team that defines standards & practices really is driven by factors that at best correlate somewhat with how evolved your tech team is. ...and I think one could argue much the same thing about frameworks, for much the same reason. Realistically, having a team defining standards & practices doesn't actually play out as "if everyone in a company is forced to use, say, Django, for any project, regardless, there will be a lot of projects where Django is a very poor choice." The entire job of centralized teams like that is not to make everyone use one technology for everything, but rather to allow teams to operate independently while avoiding all the inefficiencies that come from teams using different tools that don't actually add much value but certainly subtract value. Take the case of choosing Django. If you don't need anything like Django, of course you shouldn't be using it. That's not what standards are intended for. What they are intended for is cases where using Django may be a perfectly fine tool for what your team is doing, BUT if you used Flask instead it really wouldn't matter that much. There might be a whole ton of other teams using Flask, a lot of tribal knowledge about how to operate it, and a ton of tooling that's already been integrated with it. While it might be better to use Django for your specific project (more often than not, that's not actually the case), in aggregate for the organization, it's way better if you just use the same technology as everyone else... and where things go organizationally overall in the long run is far worse, because with everyone using different technologies and no consideration for how they all interoperate together, you have no common fabric you can plug in to effect systemic change.
• TeeMassive 4y ago
  > And even then, whats really a "framework"? For me a framework is a library that you can't get rid of and adds complexity that transcends language, IDE and compilation.
  • cbsmith 4y ago
    So if it helps, it's not a framework. Kind of like Scotsmen. ;-)