4 ms·

Also the same is true for the opposite case where a framework would really speed things up but instead you have to wade through special snowflake implementation

Also the same is true for the opposite case where a framework would really speed things up but instead you have to wade through special snowflake implementation marshland leaving your own little trail of destruction for your localized tornado of changes. Safety mitten insanity abounds.

austincheney 8y ago
I encounter this argument a lot from JavaScript developers and often it is due to an irrational fear of the technology[1]. Coupled with limited experience the argument becomes its own internal justification where you MUST use the pet framework, because if you don't everything else will become an alternate framework. If your experience is solely limited to configuring particular frameworks this argument makes sense just if you are a hammer everything looks like a nail. The core motivation, in most cases, is to lower risk and re-calibrate for complexity. There are several problems with this line of thinking. First of all, web technologies are very stable at this point. The risks are not in the standard technologies or so much their implementation. This means the risks are actually all in the developer's implementation and the business. As for business risk the solution is to define policy so that requirements are properly formulated and the code result is properly tested. Secondly, complexity is wildly misunderstood. Complexity has nothing to do with easy versus challenging. Complexity is simply putting things together. Simplicity is the progression towards singularity. A solution that calls for a single ugly 5000 line function is three times more simple than a solution that calls for 3 clean and tiny 10 line functions. Once you understand that much of the stupidity is the result of a lack of confidence you are in a much better place to deliver a solution without the stupidity that slows people down. You have to be honest with yourself and accept that code is only available to achieve automation and is always a liability. Once you accept it and own it you immediately alter your goals to the following: 1. Write less code. The best way to lower your liability is to have less stuff to be liable for. This includes the totality of the coded production from your code, to all the abstractions that you configure, and all the dependencies you bring in. 2. Be better at finding imperfections in the product and not the code. One way to do this is to make failure more clear so that you can account for it before shipping the code off to anybody else. I tell web developers to save their HTML with the file extension XHTML and always conform to WCAG 2.0 AA compliance, because then failure is immediate and you really see it with clarity. I also tell them to not use addEventListener because then they are limited to a single handler per event and if they cannot properly manage their code it will fail and that failure is immediately clear. I also tell them to look closer at the standard DOM methods which are generally faster than other conventions by 50x-16000x unless you are search for elements by attribute name/value which is about 16x slower than using a similar query selector. 3. Spend more time up front writing automation so less time is spent doing manual work. It is nice when the documentation is always up to date because it is dynamically generated from the code. 4. Provide complete test automation but not test coverage. Ensure there are tests for every business requirement, configuration, and collection of competing configurations. Prove the application does all it claims, but don't test for anything else. Testing when done wrong wastes your time. To save time ensure you have very many tests, the results are clearly communicated, and they execute as quickly as possible. After all of that and the code performs correctly it becomes far less effort to extend and to push back on stupidity from poorly considered business requirements, because you know your work is always close to perfect. You know this because you have accepted all the related liabilities and addressed them as directly as possible. [1] https://github.com/prettydiff/wisdom/blob/master/Delusional_Developers.md https://github.com/prettydiff/wisdom/blob/master/Delusional_...
- james_s_tayler 8y ago
  hmmm... I'm thinking from a back-end perspective as I don't work in JavaScript or front-end that much. I can see how you may encounter those types of people working with front-end stuff and I would say, yes, probably you're correct in that maybe they don't have the deep fundamentals of the raw technology outside of the frameworks. My comment is not from that perspective though. I find in back-end land code quality varies wildly. When people get frameworks right on the back-end code quality goes way up. It can be anything from the right choice of an off-the-shelf solution to a stellar design of a bespoke solution. Good frameworks are enforcers. They pre-make a high quality set of choices and don't leave the choice up to the developers to provide wildly inconsistent implementations and sub-optimal choices. In the cases where a framework is needed and one is not in place and instead there is much code which looks the same-ISH, feels the same-ISH, is named the same-ISH, and behaves the same-ISH but is all slightly different and unique - the code quality and speed of development suffers massively. Sometimes it's the right thing to not use a particular toy because you want to or because its cool. I agree, for sure. Hopefully, we can make high quality decisions about our code bases. For me one measure of quality is 'does this way of doing things contain the maximum amount of entropy?' If the answer is yes, then I am very much in favor. Some times there are other considerations, but that one is very, very high on my list. Good frameworks do an amazing job at that. Not all frameworks are good.

austincheney 8y ago

I encounter this argument a lot from JavaScript developers and often it is due to an irrational fear of the technology[1]. Coupled with limited experience the argument becomes its own internal justification where you MUST use the pet framework, because if you don't everything else will become an alternate framework. If your experience is solely limited to configuring particular frameworks this argument makes sense just if you are a hammer everything looks like a nail. The core motivation, in most cases, is to lower risk and re-calibrate for complexity. There are several problems with this line of thinking. First of all, web technologies are very stable at this point. The risks are not in the standard technologies or so much their implementation. This means the risks are actually all in the developer's implementation and the business. As for business risk the solution is to define policy so that requirements are properly formulated and the code result is properly tested. Secondly, complexity is wildly misunderstood. Complexity has nothing to do with easy versus challenging. Complexity is simply putting things together. Simplicity is the progression towards singularity. A solution that calls for a single ugly 5000 line function is three times more simple than a solution that calls for 3 clean and tiny 10 line functions. Once you understand that much of the stupidity is the result of a lack of confidence you are in a much better place to deliver a solution without the stupidity that slows people down. You have to be honest with yourself and accept that code is only available to achieve automation and is always a liability. Once you accept it and own it you immediately alter your goals to the following: 1. Write less code. The best way to lower your liability is to have less stuff to be liable for. This includes the totality of the coded production from your code, to all the abstractions that you configure, and all the dependencies you bring in. 2. Be better at finding imperfections in the product and not the code. One way to do this is to make failure more clear so that you can account for it before shipping the code off to anybody else. I tell web developers to save their HTML with the file extension XHTML and always conform to WCAG 2.0 AA compliance, because then failure is immediate and you really see it with clarity. I also tell them to not use addEventListener because then they are limited to a single handler per event and if they cannot properly manage their code it will fail and that failure is immediately clear. I also tell them to look closer at the standard DOM methods which are generally faster than other conventions by 50x-16000x unless you are search for elements by attribute name/value which is about 16x slower than using a similar query selector. 3. Spend more time up front writing automation so less time is spent doing manual work. It is nice when the documentation is always up to date because it is dynamically generated from the code. 4. Provide complete test automation but not test coverage. Ensure there are tests for every business requirement, configuration, and collection of competing configurations. Prove the application does all it claims, but don't test for anything else. Testing when done wrong wastes your time. To save time ensure you have very many tests, the results are clearly communicated, and they execute as quickly as possible. After all of that and the code performs correctly it becomes far less effort to extend and to push back on stupidity from poorly considered business requirements, because you know your work is always close to perfect. You know this because you have accepted all the related liabilities and addressed them as directly as possible. [1] https://github.com/prettydiff/wisdom/blob/master/Delusional_Developers.md https://github.com/prettydiff/wisdom/blob/master/Delusional_...

james_s_tayler 8y ago
hmmm... I'm thinking from a back-end perspective as I don't work in JavaScript or front-end that much. I can see how you may encounter those types of people working with front-end stuff and I would say, yes, probably you're correct in that maybe they don't have the deep fundamentals of the raw technology outside of the frameworks. My comment is not from that perspective though. I find in back-end land code quality varies wildly. When people get frameworks right on the back-end code quality goes way up. It can be anything from the right choice of an off-the-shelf solution to a stellar design of a bespoke solution. Good frameworks are enforcers. They pre-make a high quality set of choices and don't leave the choice up to the developers to provide wildly inconsistent implementations and sub-optimal choices. In the cases where a framework is needed and one is not in place and instead there is much code which looks the same-ISH, feels the same-ISH, is named the same-ISH, and behaves the same-ISH but is all slightly different and unique - the code quality and speed of development suffers massively. Sometimes it's the right thing to not use a particular toy because you want to or because its cool. I agree, for sure. Hopefully, we can make high quality decisions about our code bases. For me one measure of quality is 'does this way of doing things contain the maximum amount of entropy?' If the answer is yes, then I am very much in favor. Some times there are other considerations, but that one is very, very high on my list. Good frameworks do an amazing job at that. Not all frameworks are good.