22 ms·

> introduce frameworks without so much as "apparently it's quite good, so let's use it" And if they all want to use it - let them use it. The productivity gain

by jlg23 11y ago

> introduce frameworks without so much as "apparently it's quite good, so let's use it" And if they all want to use it - let them use it. The productivity gained by agreeing on a framework usually outweighs the performance loss over the "best" solution. Yes, my native JS implementation of a gallery app is much faster than the React version (reviewed by an experienced React-dev and judged "good") but if that project goes public and other people have to work on it I'll be damned if I make them learn my way of doing things. I'd expect these devs to implement a feature quickly and that means they use the framework they are most comfortable with. If it is good enough, it is good enough. Aiming for perfection killed way too many projects, accepting that the productive path is not always the nicest or cleanest (according to some arbitrary metric) is what makes projects succeed. e.g.: Writing perl code is definitely not the best thing to do, performance wise (when counting clock cycles), but it does (did) allow some folks to be incredibly successful. See this awesome essay of this very site's founder: http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html

exodust 11y ago
Good point. Team unity and shared understanding of the methods, I'm all for that. Personally I consider everything and don't rule anything out. I wouldn't rule out be-spoke is my main argument. It's just that, you know, life can be more rewarding if you not only aim for perfection or near-perfection, but achieve it. There's a philosophical angle here that may be more suited to the start-ups thinking and dreaming big and original, vs the company who just wants "something that works/MVP".
- jlg23 11y ago
  > life can be more rewarding if you not only aim for perfection or near-perfection, but achieve it I do that with my own software in my spare time, but from an economic point of view I cannot justify to spend that time when working for someone else. And since projects are always evolving also in requirements "perfection" is a moving target.
fsloth 11y ago
" I'd expect these devs to implement a feature quickly " Isn't that basic sin of software development - weighing speed of implementation (which is just a tiny part of the lifetime cost of software) over anything else. I'm not arguing against 'good enough', I just don't think this is a particularly strong argument for that. It's like surgeon not washing his hands and sterilizing his equipment because that way implementing the surgery takes less effort.
- jlg23 11y ago
  "lifetime cost of software" means what? 99% of the software we write is obsolete within 2 years. We should not confuse big enterprise, long term support software with modern web development. IMHO, if you want to invest into software viable on the long term, rather spend your time writing functional tests and good documentation so the current implementation can easily be replaced with a new one that uses the then hip framework. EDIT, to make my point clear: The surgeon comparison is not valid because a surgeon deals with a much longer lifetime than not only the average but most software projects.
  - zeemonkee3 11y ago
    > "lifetime cost of software" means what? 99% of the software we write is obsolete within 2 years More like, developers change jobs that often. So it's no longer your problem.
    - fsloth 11y ago
      Personally, I have terrible pangs of guilt if I know I leave a mess behind me. I've had to suffer fixing enough of someone elses messes to know what a timebomb of anger and frustration that is.
  - fsloth 11y ago
    Sure, if the software gets totally junked in a couple years then lifetime costs of the implementation become less of an issue. I work in an environment that's quite lean, but where deployment can take up to a year and lifetime is measured at the decade level so in my case the more traditional 'implementation is 10% of total costs' actually applies.
sgmarks 11y ago
As an end user, I don't see that the framework craze has any positive impact. Many websites that were highly usable around 2004 have degraded into a bloated mess. Amazon is an example, but there are many others.
- g4k 11y ago
  You can build proper apps and not just websites with the help of frameworks.
developer2 11y ago
>> The productivity gained by agreeing on a framework This is a false dichotomy. This only applies once the developers have real experience with the framework. Throwing a brand new framework at the devs without at least a month to play with it - play, not work! - is doomed to failure. Expecting first-time use of a framework on an actual project to go well is a horrible mistake. There is a lot to learn with any reasonably sized framework. Making devs use an unknown framework without time to learn it will result in a project that doesn't use that framework properly. Thousands of lines of code will be written... to duplicate functionality the framework already provides, but that the devs don't know exist. The rush of deadlines means that the devs skip reading documentation or researching the "right way" to do every task, and you wind up with a project that technically uses the framework... except that the entire project will be written in a way that someone with previous experience with that framework would never have allowed to happen. Some frameworks have so much to learn that it's essentially equivalent to having to learn a new programming language. Would you ever expect someone to learn C in a week? Java? Python? No...? Then please don't expect devs to pick up a new framework on the spot with no time to self-train on it.
- developer2 11y ago
  (I should point out that this isn't a direct counter-argument to the parent I replied to. Just a clarification on that single point. It doesn't apply to most of their comment.)
- jlg23 11y ago
  You are quoting me but I am not sure you are responding to my comment. >> if they all want to use it - let them use it >> they use the framework they are most comfortable with. > Then please don't expect devs to pick up a new framework on the spot with no time to self-train on it. I never said I did.
  - developer2 11y ago
    Haha. I thought of that and posted a sub-reply, according to timestamps, just 5 mins before you posted this. I read your whole comment, and just intended to clarify that the very act of choosing a framework does not necessarily mean increased productivity, if the devs don't know the framework in question. A tangent based solely off the quoted part, for something I've seen time and time again over the years (new framework, no time to learn it, rushed deadlines).
devishard 11y ago
> And if they all want to use it - let them use it. The productivity gained by agreeing on a framework usually outweighs the performance loss over the "best" solution. I totally disagree, and not because of performance; choosing a framework based on its performance would be premature optimization. Your argument breaks down here: > I'll be damned if I make them learn my way of doing things. I'd expect these devs to implement a feature quickly But that's exactly what a lot of projects using a framework end up doing. Between Ember, Angular, React, Backbone, Dojo, Prototype, and GWT, there is a ton of competition in this space, and you would have a hard time finding a team of professionals who all know the same framework. So at least some of your team will be learning the framework, and that learning will not pay off compared to just using vanilla JS. You can't argue that familiarity outweighs the complication added by a framework because people aren't familiar with the same frameworks. Vanilla JavaScript is the lowest common denominator: almost everyone is familiar with it.

by jlg23 11y ago

exodust 11y ago

Good point. Team unity and shared understanding of the methods, I'm all for that. Personally I consider everything and don't rule anything out. I wouldn't rule out be-spoke is my main argument. It's just that, you know, life can be more rewarding if you not only aim for perfection or near-perfection, but achieve it. There's a philosophical angle here that may be more suited to the start-ups thinking and dreaming big and original, vs the company who just wants "something that works/MVP".

jlg23 11y ago
> life can be more rewarding if you not only aim for perfection or near-perfection, but achieve it I do that with my own software in my spare time, but from an economic point of view I cannot justify to spend that time when working for someone else. And since projects are always evolving also in requirements "perfection" is a moving target.

fsloth 11y ago

" I'd expect these devs to implement a feature quickly " Isn't that basic sin of software development - weighing speed of implementation (which is just a tiny part of the lifetime cost of software) over anything else. I'm not arguing against 'good enough', I just don't think this is a particularly strong argument for that. It's like surgeon not washing his hands and sterilizing his equipment because that way implementing the surgery takes less effort.

jlg23 11y ago
"lifetime cost of software" means what? 99% of the software we write is obsolete within 2 years. We should not confuse big enterprise, long term support software with modern web development. IMHO, if you want to invest into software viable on the long term, rather spend your time writing functional tests and good documentation so the current implementation can easily be replaced with a new one that uses the then hip framework. EDIT, to make my point clear: The surgeon comparison is not valid because a surgeon deals with a much longer lifetime than not only the average but most software projects.
- zeemonkee3 11y ago
  > "lifetime cost of software" means what? 99% of the software we write is obsolete within 2 years More like, developers change jobs that often. So it's no longer your problem.
  - fsloth 11y ago
    Personally, I have terrible pangs of guilt if I know I leave a mess behind me. I've had to suffer fixing enough of someone elses messes to know what a timebomb of anger and frustration that is.
- fsloth 11y ago
  Sure, if the software gets totally junked in a couple years then lifetime costs of the implementation become less of an issue. I work in an environment that's quite lean, but where deployment can take up to a year and lifetime is measured at the decade level so in my case the more traditional 'implementation is 10% of total costs' actually applies.

sgmarks 11y ago

As an end user, I don't see that the framework craze has any positive impact. Many websites that were highly usable around 2004 have degraded into a bloated mess. Amazon is an example, but there are many others.

g4k 11y ago
You can build proper apps and not just websites with the help of frameworks.

developer2 11y ago

>> The productivity gained by agreeing on a framework This is a false dichotomy. This only applies once the developers have real experience with the framework. Throwing a brand new framework at the devs without at least a month to play with it - play, not work! - is doomed to failure. Expecting first-time use of a framework on an actual project to go well is a horrible mistake. There is a lot to learn with any reasonably sized framework. Making devs use an unknown framework without time to learn it will result in a project that doesn't use that framework properly. Thousands of lines of code will be written... to duplicate functionality the framework already provides, but that the devs don't know exist. The rush of deadlines means that the devs skip reading documentation or researching the "right way" to do every task, and you wind up with a project that technically uses the framework... except that the entire project will be written in a way that someone with previous experience with that framework would never have allowed to happen. Some frameworks have so much to learn that it's essentially equivalent to having to learn a new programming language. Would you ever expect someone to learn C in a week? Java? Python? No...? Then please don't expect devs to pick up a new framework on the spot with no time to self-train on it.

developer2 11y ago
(I should point out that this isn't a direct counter-argument to the parent I replied to. Just a clarification on that single point. It doesn't apply to most of their comment.)
jlg23 11y ago
You are quoting me but I am not sure you are responding to my comment. >> if they all want to use it - let them use it >> they use the framework they are most comfortable with. > Then please don't expect devs to pick up a new framework on the spot with no time to self-train on it. I never said I did.
- developer2 11y ago
  Haha. I thought of that and posted a sub-reply, according to timestamps, just 5 mins before you posted this. I read your whole comment, and just intended to clarify that the very act of choosing a framework does not necessarily mean increased productivity, if the devs don't know the framework in question. A tangent based solely off the quoted part, for something I've seen time and time again over the years (new framework, no time to learn it, rushed deadlines).

devishard 11y ago

> And if they all want to use it - let them use it. The productivity gained by agreeing on a framework usually outweighs the performance loss over the "best" solution. I totally disagree, and not because of performance; choosing a framework based on its performance would be premature optimization. Your argument breaks down here: > I'll be damned if I make them learn my way of doing things. I'd expect these devs to implement a feature quickly But that's exactly what a lot of projects using a framework end up doing. Between Ember, Angular, React, Backbone, Dojo, Prototype, and GWT, there is a ton of competition in this space, and you would have a hard time finding a team of professionals who all know the same framework. So at least some of your team will be learning the framework, and that learning will not pay off compared to just using vanilla JS. You can't argue that familiarity outweighs the complication added by a framework because people aren't familiar with the same frameworks. Vanilla JavaScript is the lowest common denominator: almost everyone is familiar with it.