331–340 of 550 posts
Earlier quoted context omitted.
"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.
Instead of continuing the bickering, you could show us the code base, how 'bout that?
1. Every sufficiently complex framework-free application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework. 2. If you have a talented team, that half of a framework can be much better than using a one-size-fits-all framework that is popular because it used to be lean and mean with a small surface area, but has grown over time to do everything for everyone, becoming a com…
> 1. Every sufficiently complex framework-free application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework. Of which you are the creator and expert, and have complete control and insight, and can change it in any way you want any time. It is in 100% alignment with your goals at all time. If you use a framework your organisation becomes incredibly complex, because you a…
I broadly agree with GP here, but to round out some of their points:
- Frameworks take care of the parts of your application that aren't special. In the same way garbage collection isn't the value your company provides to customers, HTTP header parsing (or whatever) isn't either.
- Frameworks prevent your team from diving down architecture rabbit holes, or having to read a bunch of books on DDD, or what have you. This sounds like a small point, but if you tracked the number of expensive engineering hours spent disagreeing about where code should go, look like, and work, you would realize it's a pretty big one.
- Frameworks are tested way better than you ever could by thousands of users, actually documented, contain compatibility guarantees, and have security policies. To match this quality, your company would probably spend millions of dollars on eng hours. That's why company-specific frameworks don't match this quality.
- Frameworks make onboarding way easier. Most Python engineers know Django; most Ruby engineers know Rails. By definition, you can't hire engineers that already know your framework (even if you use something like Hexagonal, because no two implementations of this are alike). And again, because your in-house framework will be poorly tested/documented/etc., new hires will struggle. They'll also wonder if this is a career cul-de-sac: "I have 4 years of irrelevant experience in [bespoke framework X]" is not an enticing resume bullet.
> Your software is custom made for your organisation, it's not mass producing identical systems on an assembly line
This returns us to the palace vs. suburbs framing. The software you write is a super small percentage of the code that runs your app, all the way from firmware to CSS libraries. Good engineering is carefully deciding what code you will write yourself, because code isn't just implementation, it's design, buy-in, maintenance, documentation, and liability. Some enterprises are replacing a big chunk of that stack (Oxide or Cloudflare come to mind), but I bet 95% of companies are just building REST/GraphQL servers. That's not special enough to require a custom, in-house framework. You should just build the house the regular way.
"Frameworks are designed to take your project hostage" Wow, that is some enterprise level FUD, and with zero citations to back up that assertion. While one could possibly see 3rd party external dependencies pose a variable cost, service risk, or security issue... a standalone/maintainable site should not have 25 domains for every lame js widget a designer thought looked cool. Those who do not use a good framework, ar…
The wrong framework will harm the maintenance of your software. The right framework will keep it going for decades.
Of course it's not always obvious how a framework will evolve over time (let alone the requirements of your website/app/api), so the safe bet is to stick with the ones that already stood the the test of time.
Earlier quoted context omitted.
> Of which you are the creator and expert, and have complete control and insight, and can change it in any way you want any time. It is in 100% alignment with your goals at all time. And then you change a job and you take 80% knowledge with you and your now-past project is in deep trouble.
If knowledge is on a single person alone, then your ex-company has bigger issues than framework or no framework. Not to mention that the interesting parts of your app should be the domain logic and workarounds and solutions used in it for business issues and historical layers of bussiness logic choices. And that a single person can take with them whether there's a framework or not.
> Not to mention that the interesting parts of your app should be the domain logic and workarounds and solutions used in it for business issues and historical layers of bussiness logic choices.
In my experience this has been a point in favor of OTS frameworks--the code you don't care about is handled by the framework, and you bring the business logic. But also, reading through this, I guess I don't understand your comment. Isn't the business logic in the code? How can a person take it with them?
Earlier quoted context omitted.
> If you find a bug with the adhoc framework you need to convince a busy person in another team to spend time to unblock you. Which is not so difficult, because that busy person is in the same organisation as you, and therefor working towards the same goal. Fixing that bug is much more difficult if that person is in an outside organisation, serving many other customers on the same code base (with possible conflicting…
> Which is not so difficult, because that busy person is in the same organisation as you, and therefor working towards the same goal. {evil laugh.mp3}… Ideally yes but in reality: all teams have bottlenecks, and nearly all teams have assholes. Is fixing your problem on their OKR or whatever. Free / open source code can be fixed by anyone: the volunteer owner (who you could even bribe to fix it), any contractor with e…
To have a fix accepted on an OSS project means fixing it not just for your use case but also for every other user of the project, on every target platform, while aligning with the goals of that project. If you can get anyone to look at the PR in the first place. Assuming you've used the framework to save time, you probably don't have time to go through all that and your deadline will not wait a month or six for your code to make it into a release. Depending on your employer you may well need internal permission and legal sign-off to contribute to an OSS project in company time which is yet another hoop to jump through; though that goes for forking too.
In my 14-15 years of experience in software industry I learned that having framework helps mostly with that - having bunch of "know it alls" rounded up to use the same approach instead of having "I know better discussions".
Where frameworks shine is specifically lowering amount of discussions on technical details that has no relevance to the business but has all kind of opinions from devs.
Someone in the thread claims - if he is hired he has to learn framework - well I am hiring people with knowledge on framework we use, he might not have been looking for a job lately. I have not seen we hire c# or c or java dev - there is always framework in requirements. Just see how frontend devs ads look "react dev to hire"/"angular dev to hire" no one hires "someone who knows html and css", yes it is requirement to know these but you also have to know at least one framework.
Earlier quoted context omitted.
If knowledge is on a single person alone, then your ex-company has bigger issues than framework or no framework. Not to mention that the interesting parts of your app should be the domain logic and workarounds and solutions used in it for business issues and historical layers of bussiness logic choices. And that a single person can take with them whether there's a framework or not.
The advantage is that I wrote it and am the foremost expert on how it works. If it's a matter of training up other people, we're just as well becoming experts in a framework
Earlier quoted context omitted.
That’s why I always start a new app by writing my own operating system for it first. Use frameworks, use libraries. They will save you time, make your code less buggy, make it easier to hire other people. Writing your own ball of mud is great for a hobby but not for business.
I started using a framework for a task at work, was immediately tripped up by an obvious stupid bug in the config files, reported it and it was closed because "too many people already depend on this behaviour". So now I've in-sourced other companies legacy and taken on a huge liability in depending on the evolution of undefined number of other organisations and their code bases. And even worse when these frameworks a…
Thinking about this case more, this is exactly what you want from frameworks: compatibility guarantees. Frameworks break compatibility, but deliberately and slowly. Will your in-house framework do that? Will it announce and well document its intent to deprecate functionality in favor of new features? Will it find all the users of it across your enterprise and work with them on migration strategies? Will it build in deprecation notices for literally years? Will it build in tests for the bridging changes? Django does all of this, for you, for free.
Earlier quoted context omitted.
> 1. Every sufficiently complex framework-free application contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of a framework. Of which you are the creator and expert, and have complete control and insight, and can change it in any way you want any time. It is in 100% alignment with your goals at all time. If you use a framework your organisation becomes incredibly complex, because you a…
Of which you are the creator and expert No, I'm not. The guy who quit 2 years ago was. I've worked with custom frameworks, and while they where both clever and powerful with some quite cool features which would have been tricky to do in a more generic framework, they where also virtually undocumented, fragile, difficult to extend and slow to get people up to speed on.