5 ms·

Complexity requires structure in order to be maintainable. Its not a "kitchen sink", its scaffolding. If you don't understand then you are either writing huge

by gjolund 10y ago

Complexity requires structure in order to be maintainable. Its not a "kitchen sink", its scaffolding. If you don't understand then you are either writing huge amounts of documentation and test code for your custom solution, or you are acknowledging that your app will be unmaintainable once you leave your position. Both are signs of inexperience.

coldtea 10y ago
>Complexity requires structure in order to be maintainable. Structure is the job of the lead programmer(s), not some third party framework developer. And it should suit the specific job. It's as if we forgotten that programs have to be designed with an overall architecture based on our business, and instead just download off the shelve scaffoldings and try to adapt our business logic around their design. You know that Joe Armstrong quote about OOP? "the problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle" Well, it's the same with frameworks. You wanted a router, a template engine, and a few more pieces, but you go that, a banana, the entire jungle, and a mustachioed dictator telling you how to do things. >If you don't understand then you are either writing huge amounts of documentation and test code for your custom solution, or you are acknowledging that your app will be unmaintainable once you leave your position. It's as if we've forgotten the existence of libraries and APIs, of which there are like 200.000 in npm, and 50 of them are also really good. >Both are signs of inexperience. Some of the most experienced programmers, of 20+ years of career of successful projects, don't trust frameworks (and surely neither the "framework du jour" of JS, nor the "framework that ate Cincinnati" approach of J2EE of yore).
- gjolund 10y ago
  >Complexity requires structure in order to be maintainable. A competent lead programmer will choose a structure that adheres to common best practices and is maintained by a community. Also known as a framework. >If you don't understand then you are either writing huge amounts of documentation and test code for your custom solution, or you are acknowledging that your app will be unmaintainable once you leave your position. 200,000 libraries, 50 of them good. My point exactly. A well written framework has already done the curation for you and has a community of people working to make those components even better for YOUR USE CASE. >Both are signs of inexperience. I guess I won't be hiring you then. If a candidate comes in and says "I don't trust frameworks because they are complex", I say "Thanks for your time."
  - tobltobs 10y ago
    Are you are replying to yourself? You are quoting yourself.
    - gjolund 10y ago
      Way to avoid adding any more the conversation.
  - coldtea 10y ago
    >and has a community of people working to make those components even better for YOUR USE CASE. How did the latter point derive from the former? Frameworks come with prepackaged components and it's usually their way or the highway. A framework might very well have a "community of people working to make those components even better" (period), but surely not "a community of people working to make those components even better for [MY] USE CASE". If anything, a component's community try to make them as generic and all-encompassing as possible. Contrast with libs, where I can cherry pick and use the one closest to my exact use cases. >I guess I won't be hiring you then. People use those kind of "arguments" a lot, as if they prove anything. Depending on what those who say it are arguing against, it could both be a wise decision or the sign of an totally inept boss. There are people who don't like frameworks that can code circles around people who do (and vice versa). If you don't want to hire the former, it's totally fine. Telling strangers who haven't applied to you, and have no intention to do so (and might be making hiring decisions themselves, elsewhere) that you won't hire them shows you in bad light -- trying to beat them into line not with arguments but with "boss" power.
    - bschwindHN 10y ago
      "I wouldn't hire you" is the quintessential Hacker News put down and I see it all the time. It's effectively saying "I disagree with you, and I want to make you feel bad by pretending I'm in a position of power over you." Hilarious, and if a Hacker News bingo exists, it should be the free space.
  - angelofm 10y ago
    I have to say I agree with a lot of your point but your tone comes off really agressive, I think frameworks are good particularly for inexperiences developets that will have a really hard time writing simple and maintainable code, but all people are saying is that in development you cannot just cross out bespoke development altogether there will always be a use case when you need to fine tune your software. Saying that please bare in mind that I love react it's a great tool but like everything it has its place.
Retric 10y ago
Frameworks add complexity not structure. The goal is to cover every relevant base which is complex. The imposed design rarely has any relationship to your problems at best they help manage the framework's needs.
MortenK 10y ago
"Both are signs of inexperience." Case of pot calling the kettle black methinks.

by gjolund 10y ago

coldtea 10y ago

>Complexity requires structure in order to be maintainable. Structure is the job of the lead programmer(s), not some third party framework developer. And it should suit the specific job. It's as if we forgotten that programs have to be designed with an overall architecture based on our business, and instead just download off the shelve scaffoldings and try to adapt our business logic around their design. You know that Joe Armstrong quote about OOP? "the problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle" Well, it's the same with frameworks. You wanted a router, a template engine, and a few more pieces, but you go that, a banana, the entire jungle, and a mustachioed dictator telling you how to do things. >If you don't understand then you are either writing huge amounts of documentation and test code for your custom solution, or you are acknowledging that your app will be unmaintainable once you leave your position. It's as if we've forgotten the existence of libraries and APIs, of which there are like 200.000 in npm, and 50 of them are also really good. >Both are signs of inexperience. Some of the most experienced programmers, of 20+ years of career of successful projects, don't trust frameworks (and surely neither the "framework du jour" of JS, nor the "framework that ate Cincinnati" approach of J2EE of yore).

gjolund 10y ago
>Complexity requires structure in order to be maintainable. A competent lead programmer will choose a structure that adheres to common best practices and is maintained by a community. Also known as a framework. >If you don't understand then you are either writing huge amounts of documentation and test code for your custom solution, or you are acknowledging that your app will be unmaintainable once you leave your position. 200,000 libraries, 50 of them good. My point exactly. A well written framework has already done the curation for you and has a community of people working to make those components even better for YOUR USE CASE. >Both are signs of inexperience. I guess I won't be hiring you then. If a candidate comes in and says "I don't trust frameworks because they are complex", I say "Thanks for your time."
- tobltobs 10y ago
  Are you are replying to yourself? You are quoting yourself.
  - gjolund 10y ago
    Way to avoid adding any more the conversation.
- coldtea 10y ago
  >and has a community of people working to make those components even better for YOUR USE CASE. How did the latter point derive from the former? Frameworks come with prepackaged components and it's usually their way or the highway. A framework might very well have a "community of people working to make those components even better" (period), but surely not "a community of people working to make those components even better for [MY] USE CASE". If anything, a component's community try to make them as generic and all-encompassing as possible. Contrast with libs, where I can cherry pick and use the one closest to my exact use cases. >I guess I won't be hiring you then. People use those kind of "arguments" a lot, as if they prove anything. Depending on what those who say it are arguing against, it could both be a wise decision or the sign of an totally inept boss. There are people who don't like frameworks that can code circles around people who do (and vice versa). If you don't want to hire the former, it's totally fine. Telling strangers who haven't applied to you, and have no intention to do so (and might be making hiring decisions themselves, elsewhere) that you won't hire them shows you in bad light -- trying to beat them into line not with arguments but with "boss" power.
  - bschwindHN 10y ago
    "I wouldn't hire you" is the quintessential Hacker News put down and I see it all the time. It's effectively saying "I disagree with you, and I want to make you feel bad by pretending I'm in a position of power over you." Hilarious, and if a Hacker News bingo exists, it should be the free space.
- angelofm 10y ago
  I have to say I agree with a lot of your point but your tone comes off really agressive, I think frameworks are good particularly for inexperiences developets that will have a really hard time writing simple and maintainable code, but all people are saying is that in development you cannot just cross out bespoke development altogether there will always be a use case when you need to fine tune your software. Saying that please bare in mind that I love react it's a great tool but like everything it has its place.

Retric 10y ago

Frameworks add complexity not structure. The goal is to cover every relevant base which is complex. The imposed design rarely has any relationship to your problems at best they help manage the framework's needs.

MortenK 10y ago

"Both are signs of inexperience." Case of pot calling the kettle black methinks.