6 ms·

> "They did invest lots of time to learn about all those tools and libraries" Unfortunately that claim doesn't hold up to what I suspect is happening most of t

by exodust 11y ago

> "They did invest lots of time to learn about all those tools and libraries" Unfortunately that claim doesn't hold up to what I suspect is happening most of the time. At least in my experience at work I've seen tech leads or someone similar introduce frameworks without so much as "apparently it's quite good, so let's use it". One case in particular, Angular was chosen and turned out not to be suitable - it ran very slowly with the tasks it was chosen to do in the browser on a particularly busy web page. Learning the limitations of Angular would have gone a long way to avoiding the poor result. Not enough learning, too much embracing shiny new things.

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.
josephcooney 11y ago
Sounds like "Resume Driven Development" http://imgur.com/DQcks8ul http://imgur.com/DQcks8ul
jerf 11y ago
"At least in my experience at work I've seen tech leads or someone similar introduce frameworks without so much as "apparently it's quite good, so let's use it"." I completely agree. Web people quite often commit to frameworks based on their marketing copy and maybe one guy they read on the internet saying "seems pretty AWESOME after I've played with it for two days!" and a testimonial or two. Of course, I've seen development languages chosen that way, NoSQL databases chosen that way, "which Linux variant do we base our company on" chosen that way, bug trackers chosen that way, chat systems chosen that way, devops management chosen that way, VM and/or containerization chosen that way (or, indeed, people just declaring "we need containers" for what appears to be "because we aren't cool if we don't have them")... you know, this may not really be just a "web" thing....
- neppo 11y ago
  Serious question: How else can you adopt a new technology, without investing significant amount of time? It would be nice to exhaustively explore a tech before using it, but that's often simply not feasible due to lack of resources.
  - jerf 11y ago
    There's a range of options between "I watched an hour video and saw a cool demo" and "I invested six months into prototyping and testing the tech before I chose it." I mean, that really ought to answer your question, but to be concrete: Never bet anything but maybe your startup on a tech that you can't find anybody else your size trying out. Try searching "$TECH sucks" and similar queries on the Internet. If you can't find anything, that's not a sign the tech is too awesome to have flaws... it's a sign nobody's using it! Of course, you need to learn how to balance the hype vs. the "sucks" options. The question is not whether somebody has something bad to say, the question is what bad things they say. Are they clearly using it wrong? Are they clearly using it in a use case the software doesn't even claim to support? Or... are they using it in exactly your use case in exactly the way you wanted to use it and encountered fundamental problems? Even once you think you've settled on a choice, what other choices are there? The existence of a "good" choice does not preclude better choices. If you do do a test deployment, don't fall into the trap of deploying at a radically smaller size than you need. If you're going to need the tech to work in clustered mode, for instance, don't deploy it to a single server and deploy three records to it. Deploy it in a cluster mode and load it up with 10-100x times the data you think it's going to have. You can't practically test the complexity of the app you wan to write without actually writing it, but you usually can test the size. Test your most complicated case; if you've got a web app and you want a framework to help you out, don't make the simple "user prefs" page, as soon as you can start working on the most complicated page in the site, which is probably the one that's the payload. Easy things being easy isn't an interesting test; check the hard things. Find someone with a experience-hardened intuition to do this with you. Realize that any tiny issue you experience and can't get through now will become a large issue later. Realize that you generally always end up with some of those issues anyhow, so it's a question of picking which you go with. Don't underestimate the established choices. They're big for a reason, especially if they've been around for years. The new hotness will play up the old guard's flaws while minimizing their own. You can make anything look good by only considering the positives, you can make anything look bad by only considering the negatives. Always look at both for all options. Get that experienced person to help you through it. For whatever task it is you are looking to do, figure out which problems you are most likely to have, and prioritize your analysis to focus on those. Do you know you need total CP consistency? Then you can quickly eliminate entire choices by whether they even claim it, and further eliminate more by checking whether they actually maintain it in the field on their user fora. Do you have price constraints? Bam, entire choices knocked out. I've never personally been in the situation where I got to the point where I needed to start kicking tires and I had a dozen equally-good choices; there was always a clear hierarchy. And, in the end, do consider the joy-of-use of a tech... just don't make it your only consideration. An fun-to-use tech that completely fails to solve your problems rapidly becomes a nightmare-to-use tech anyhow. Ask around you about framework regret; anybody with a few years in should have at least one story of when they expected something to be awesome and it wasn't. Even putting a week into something as important as "what database will we choose" can pay off huge, easily being the difference between project success or failure. You don't necessarily need to work everything out for months.

by exodust 11y ago

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.

josephcooney 11y ago

Sounds like "Resume Driven Development" http://imgur.com/DQcks8ul http://imgur.com/DQcks8ul

jerf 11y ago

"At least in my experience at work I've seen tech leads or someone similar introduce frameworks without so much as "apparently it's quite good, so let's use it"." I completely agree. Web people quite often commit to frameworks based on their marketing copy and maybe one guy they read on the internet saying "seems pretty AWESOME after I've played with it for two days!" and a testimonial or two. Of course, I've seen development languages chosen that way, NoSQL databases chosen that way, "which Linux variant do we base our company on" chosen that way, bug trackers chosen that way, chat systems chosen that way, devops management chosen that way, VM and/or containerization chosen that way (or, indeed, people just declaring "we need containers" for what appears to be "because we aren't cool if we don't have them")... you know, this may not really be just a "web" thing....

neppo 11y ago
Serious question: How else can you adopt a new technology, without investing significant amount of time? It would be nice to exhaustively explore a tech before using it, but that's often simply not feasible due to lack of resources.
- jerf 11y ago
  There's a range of options between "I watched an hour video and saw a cool demo" and "I invested six months into prototyping and testing the tech before I chose it." I mean, that really ought to answer your question, but to be concrete: Never bet anything but maybe your startup on a tech that you can't find anybody else your size trying out. Try searching "$TECH sucks" and similar queries on the Internet. If you can't find anything, that's not a sign the tech is too awesome to have flaws... it's a sign nobody's using it! Of course, you need to learn how to balance the hype vs. the "sucks" options. The question is not whether somebody has something bad to say, the question is what bad things they say. Are they clearly using it wrong? Are they clearly using it in a use case the software doesn't even claim to support? Or... are they using it in exactly your use case in exactly the way you wanted to use it and encountered fundamental problems? Even once you think you've settled on a choice, what other choices are there? The existence of a "good" choice does not preclude better choices. If you do do a test deployment, don't fall into the trap of deploying at a radically smaller size than you need. If you're going to need the tech to work in clustered mode, for instance, don't deploy it to a single server and deploy three records to it. Deploy it in a cluster mode and load it up with 10-100x times the data you think it's going to have. You can't practically test the complexity of the app you wan to write without actually writing it, but you usually can test the size. Test your most complicated case; if you've got a web app and you want a framework to help you out, don't make the simple "user prefs" page, as soon as you can start working on the most complicated page in the site, which is probably the one that's the payload. Easy things being easy isn't an interesting test; check the hard things. Find someone with a experience-hardened intuition to do this with you. Realize that any tiny issue you experience and can't get through now will become a large issue later. Realize that you generally always end up with some of those issues anyhow, so it's a question of picking which you go with. Don't underestimate the established choices. They're big for a reason, especially if they've been around for years. The new hotness will play up the old guard's flaws while minimizing their own. You can make anything look good by only considering the positives, you can make anything look bad by only considering the negatives. Always look at both for all options. Get that experienced person to help you through it. For whatever task it is you are looking to do, figure out which problems you are most likely to have, and prioritize your analysis to focus on those. Do you know you need total CP consistency? Then you can quickly eliminate entire choices by whether they even claim it, and further eliminate more by checking whether they actually maintain it in the field on their user fora. Do you have price constraints? Bam, entire choices knocked out. I've never personally been in the situation where I got to the point where I needed to start kicking tires and I had a dozen equally-good choices; there was always a clear hierarchy. And, in the end, do consider the joy-of-use of a tech... just don't make it your only consideration. An fun-to-use tech that completely fails to solve your problems rapidly becomes a nightmare-to-use tech anyhow. Ask around you about framework regret; anybody with a few years in should have at least one story of when they expected something to be awesome and it wasn't. Even putting a week into something as important as "what database will we choose" can pay off huge, easily being the difference between project success or failure. You don't necessarily need to work everything out for months.