The problem with frameworks - Uncle Bob

#frameworks #framework #reactnative #vuejs #springboot #softwaredevelopement #unclebob #cleancode #cleanarchitecture

In this video, Robert C. Martin (Uncle Bob) speaks on the asymmetry between developers and the frameworks they often rely on to do their day to day work.
He brings to mind the level of coupling and commitment that is often encouraged by frameworks, and how these benefit the framework authors while cripling developers in the long run. thoughts?

[LHCB]

No problem, we just make a new framework changing the stuff we don't like. /s Just like everyone else. Now there are so many frameworks that we need to make a new framework for the frameworks.

[gediminasmorkys]

In order to use a framework you have to make a huge commitment to them.
Well, if I write something from scratch, the company is making a huge commitment to me :D

[cloudboogie]

I think lots of people don't get it due to duality of tech industry and difference in work experiences. Some of us are working in multi-year, large scale projects. Others pour their work into startups, that will cease to exist in a year or two. Those two types of developers have different goals, which influences how they choose technologies and how they approach software architecture.

[rafaelanschau]

What he says about frameworks is true for any architecture. You commit to the architecture, it doesn't commit to you. Your code get coupled to the architecture. The framework benefits you in the sense that it gives you ready-to-use architecture. There is always going to be an extra effort you pay in order to have structure, so then your code doesn't become a mess as it grows.

Whether the architecture was explictely made by an architect during project or reused from an existing framework is a minor issue compared to not having an architecture which is almost always the main issue.

The cost benefit of a framework is obvious. You gain a durable structure as the system grows, you pay with extra effort to program within its constraints.

[peterstevens]

It is not bad to use frameworks. But do not select on base of how easy it is to do something simple, but on how easily it supports your most complex thing, so that it does not get in your way. And how easily you can swap it out. Very reasonable.

[toddbu-WKL]

In 35+ years as a software developer, I have discovered that there are two camps. Camp #1 wants to do everything quickly, relying on shortcuts like frameworks to get the job done. While the first 80% is easy, the last 20% is difficult. So they compromise on their software to work around problems. What they end up with is junk and often needs to be replaced because it is not up to the task. Camp #2 recognizes that good engineering takes time, and that junior engineers only become senior engineers with practice. They achieve most of their goals with a good upfront design, and compromises are few and far between. When it comes to cost, Camp #2 is cheaper in the long run because you have skilled people doing quality work with far fewer iterations.

[aytviewer]

FINALLY --I'm a 50+ year old programmer who has been saying this for the past decade. I can start really fast and make a cool demo or prototype, but then Sh!t gets real and you end up either working around it or dumping it altogether.

[yaminhijazi]

Frameworks make us look smarter in the interviews and in the meetings.
We (as developers) are almost never estimated by our analytical abilities, we are judged by the frameworks we claim to know.

[juggernaut]

This is the truth. Frameworks also prevent junior developers from learning the fundamentals and nuances of core web technologies because everything is hidden behind the framework. Having said that, it's not practical any more to write large applications without frameworks because it takes too long, but before you choose a framework, make sure you understand how to combine framework code with non-framework code so you can leverage its power but step outside of it any time you need to.

[shedokan]

"You must commit to them, they do not commit to you"
This is true for any piece of software, not just frameworks.

Also, it is not true that it's more difficult to write code in the future - it depends on what you're building

[stea]

That's true. But if you start with no frameworks, then your development costs will skyrocket and probably won't get clients because they will find another company who does it cheaper with frameworks. And nowadays the "time to market" requirements from companies is usually as fast as possible and if they manage to succeed the following months/years, then they are agreeing to fund further code quality changes and other things. So again, unless you are in a very specific use case, starting projects without frameworks do not make sense development wise or cost wise.

[wknight]

The problem domain that a Framework is trying to solve is "how to build applications like this", while the problem domain that your app is trying to solve is "how to solve this business problem". As framework developers incorporate more use-cases and gain deeper understanding of *their domain*, they will eventually make breaking changes, bump the major version number, deprecate the old versions, remove support from old versions, and *force you to change the way you implement solutions in your domain*. I've seen some extremely painful and expensive framework upgrades, Spring and Angular as two recent examples, where there is no *business need* to update the framework except for managing the liability of a framework outside it's support lifetime. Some libraries and frameworks make transitions a bit easier, but it's never going to be painless because framework code is so foundational.

[stephenkolostyak]

"The problem with frameworks - Uncle Bob"

In my experience the problem with frameworks is that too many people who can't do the work use them to hide that fact.

[karasira]

There is this old saying in the software industry, that ‘If you’re not using a framework, you’re building one.’

[mazhigigikamiludin]

I am not sure what he is trying to say, but the major goal of utilising a framework is to establish a standardised code/file structure that allows multiple developers to contribute and develop it for future expansion. Imagine attempting to decipher the classes and file structure created by a previous developer when everybody has their own habit. Using a framework eliminates the need for project managers to manually create and brief new team members of the standardisation, which can be time-consuming and lead to mistakes.

[dschledermann]

I generally shy away from larger frameworks, but in order to get stuff done you generally have to use a few trimmed packages. I code mainly in PHP and Rust and I maintain a couple of legacy Perl applications. In PHP we've got burned by Laravel, with a project that ended up in a completely unmaintainable state. It eventually proved unfeasible to upgrade the project to a newer version of Laravel. I now have the habit of choosing a few required packages for a given project and integrating them. This method works good for PHP and Rust. I'm not really a JavaScript or TypeScript developer, so I don't really have an experience how feasible that approach is there.

[deceiver]

Arrogant people crying out loud about an old man being old should re-read "Clean Architecture" since this argument about frameworks seems to fly over your heads completely when condensed into a 2-3 minutes video.

[hoangkimthienlong]

Ok I think the statement has some points, so what will we do with this statement? Do I have something to do with it ?

[michaelbrauner]

That's the reason why I love Symfony so much. It consists of components that you can combine as you like.

[erwile]

what's the source to have the full video ?