4 ms·

> 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 y

> 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.

coldtea 4y ago
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.
- RamblingCTO 4y ago
  It will always happen to a degree anyway. The more people are experts because of specifics to this company, the worse. Using a framework also improves hiring.
- randomsearch 4y ago
  Theory vs reality.
  - coldtea 4y ago
    Exactly. In theory a framework would solve that. But I described the reality.
- 8note 4y ago
  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
  - jarek83 4y ago
    Well, business usually don't have that comfort of spending money on this when there is much cheaper alternative. Aaand they can hire experts in a framework instead of an engineer that would have to be learned the custom stuff and could eventually say that he doesn't like the stack and would build his own...
- soco 4y ago
  I'm not sure why you would describe the entire real world as "problem". Because this is how the real world works, with organizations where the last knowledgeable guy was fired two years ago and now discovers they need to touch that incredibly useful and huge application he wrote ten years ago. I'm aware there's an entire book industry telling how the ideal world should look like but there are also unicorns in every fantasy book yet nobody would judge you for not herding a couple.
- camgunz 4y ago
  These are generally just resource issues. Companies generally won't pay for engineering hours to build really good framework documentation. It's not in the critical path. Companies that know that documentation, as well as tests, compatibility guarantees, security policies, etc. are actually critical components would probably not ever make the decision to take on that engineering burden themselves unless it were a business differentiator, which it almost never is. > 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?
  - spion 4y ago
    > In my experience this has been a point in favor of OTS frameworks Its not guaranteed. I've seen many developers spend lots of time trying to get the framework they're working in to cooperate or dig through bad documentation. Framework authors are fallible too and general-purpose software is really hard to get right.
    - camgunz 4y ago
      Well, my point here is that even if there are little patches against a framework, we're talking something like 5% of the repo's code is framework-y stuff. If you've got your own framework, then... what even is the limit? 50%? 90%? I wonder if some of the disagreements in this thread are just like, people in favor of frameworks used Rails/Django, people against them used Spring/Struts. > Framework authors are fallible too and general-purpose software is really hard to get right. Yeah, I think that's solved by the "market". There was a big explosion of Python frameworks in the aughts: TurboGears, CherryPy, Pyramid/Pylons, Zope, web.py, etc. etc. Lots of stuff. The ecosystem now is Django/FastAPI (Flask/Tornado legacy apps are either stuck or moving to FastAPI IME). Django got it right. But more broadly, what are the odds a bespoke framework will do it right? Will you think up a new way to organize controllers, or to abstract auth, or to manage database sessions, etc. etc. etc. That sounds like a nightmare to me; just let me focus on the business logic please, haha.
- vjk800 4y ago
  > If knowledge is on a single person alone, then your ex-company has bigger issues than framework or no framework. You are both right and also describing every single company I've seen. I haven't worked in a straight up software company, though. Maybe they have things better.
amenghra 4y ago
This. And you’ll feel lost or sub-productive while you ramp up on the new company’s bespoke framework.
slifin 4y ago
Unless you're in a library driven ecosystem like Clojure in which case the majority of interesting code is just calling into a library Yes you still have to know how it's glued together but at least there is still standardisation whilst still being flexible enough to swap individual libraries Not a perfect solution but a good compromise in my experience

coldtea 4y ago

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.

RamblingCTO 4y ago
It will always happen to a degree anyway. The more people are experts because of specifics to this company, the worse. Using a framework also improves hiring.
randomsearch 4y ago
Theory vs reality.
- coldtea 4y ago
  Exactly. In theory a framework would solve that. But I described the reality.
8note 4y ago
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
- jarek83 4y ago
  Well, business usually don't have that comfort of spending money on this when there is much cheaper alternative. Aaand they can hire experts in a framework instead of an engineer that would have to be learned the custom stuff and could eventually say that he doesn't like the stack and would build his own...
soco 4y ago
I'm not sure why you would describe the entire real world as "problem". Because this is how the real world works, with organizations where the last knowledgeable guy was fired two years ago and now discovers they need to touch that incredibly useful and huge application he wrote ten years ago. I'm aware there's an entire book industry telling how the ideal world should look like but there are also unicorns in every fantasy book yet nobody would judge you for not herding a couple.
camgunz 4y ago
These are generally just resource issues. Companies generally won't pay for engineering hours to build really good framework documentation. It's not in the critical path. Companies that know that documentation, as well as tests, compatibility guarantees, security policies, etc. are actually critical components would probably not ever make the decision to take on that engineering burden themselves unless it were a business differentiator, which it almost never is. > 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?
- spion 4y ago
  > In my experience this has been a point in favor of OTS frameworks Its not guaranteed. I've seen many developers spend lots of time trying to get the framework they're working in to cooperate or dig through bad documentation. Framework authors are fallible too and general-purpose software is really hard to get right.
  - camgunz 4y ago
    Well, my point here is that even if there are little patches against a framework, we're talking something like 5% of the repo's code is framework-y stuff. If you've got your own framework, then... what even is the limit? 50%? 90%? I wonder if some of the disagreements in this thread are just like, people in favor of frameworks used Rails/Django, people against them used Spring/Struts. > Framework authors are fallible too and general-purpose software is really hard to get right. Yeah, I think that's solved by the "market". There was a big explosion of Python frameworks in the aughts: TurboGears, CherryPy, Pyramid/Pylons, Zope, web.py, etc. etc. Lots of stuff. The ecosystem now is Django/FastAPI (Flask/Tornado legacy apps are either stuck or moving to FastAPI IME). Django got it right. But more broadly, what are the odds a bespoke framework will do it right? Will you think up a new way to organize controllers, or to abstract auth, or to manage database sessions, etc. etc. etc. That sounds like a nightmare to me; just let me focus on the business logic please, haha.
vjk800 4y ago
> If knowledge is on a single person alone, then your ex-company has bigger issues than framework or no framework. You are both right and also describing every single company I've seen. I haven't worked in a straight up software company, though. Maybe they have things better.

amenghra 4y ago

This. And you’ll feel lost or sub-productive while you ramp up on the new company’s bespoke framework.

slifin 4y ago

Unless you're in a library driven ecosystem like Clojure in which case the majority of interesting code is just calling into a library Yes you still have to know how it's glued together but at least there is still standardisation whilst still being flexible enough to swap individual libraries Not a perfect solution but a good compromise in my experience