5 ms·

bad examples. I don't think microservices, react, functional programming or no sql are examples of 'hype'; I think those are good engineering decisions (depend

bad examples. I don't think microservices, react, functional programming or no sql are examples of 'hype'; I think those are good engineering decisions (depending on the problem domain). I also completely disagree that hackathons are good places to try out new technologies to see what's good for good engineering decisions; hackathons let you dip your fingers in the water and see the shiny cool bits and pieces without having to suffer through any of the long term maintenance or scale issues with the technologies. If you're looking for a bad decision, picking something to run with that 'seems pretty good' after a 2 day hackathon <--- that's your bad decision right there. I mean, I get what the article is saying, yeah yeah, avoid the hype, don't drink the 'webscale' cool-aid... ...but hey, the internet is full of really talented smart people who do excellent engineering work. You'd be stupid to not look at what the best and most successful companies in the world are doing with their engineering teams and take note of it. Even if it means picking up new technology: that's not bowing to the hype; it's being pragmatic. Still, it's super easy to cherry pick some things and go, oh hey, this is a bad idea. Much more interesting would be some examples of good engineering choices.

mgkimsal 9y ago
> I think those are good engineering decisions (depending on the problem domain). The "depending on the problem domain" seems another variant of "choose the right tool for the right job". One could probably add "for the right reason" on the end of that instruction too, and it wouldn't hurt. The problem is the ability to determine "the right tool" and "the right job" - many people simply don't have it. You only get that ability through experience. With new tools few people - even older folks - have enough experience with the tool in question to make accurate/useful assessments. > but hey, the internet is full of really talented smart people who do excellent engineering work. And it's full of even more people who aren't really capable of making those assessments accurately. > You'd be stupid to not look at what the best and most successful companies in the world are doing with their engineering teams and take note of it. You'd be stupid to think that because "Facebook" (or "Amazon" or "Google" or "MS") is using a particular tech stack (which, likely, teams of internal people contributed to for months), it's a great fit for your problem, or your skills, or your team's skills, or your project's timeline, or its budget. Few people have the problems or demands that Facebook/Amazon/Google/etc have. It's great that they share some of their internal tech, but that sharing isn't an automatic determination that their solutions are appropriate fits for your problems.
- shadowmint 9y ago
  This basically what I'm talking about. Ok, if what the smartest and best people are doing isnt the right solution for my problem, what is? Come on; enough vague hand waving. How do you pick the right tech to use then?
  - deleted 9y ago
    [deleted]
  - BaronSamedi 9y ago
    What if your development team is made up of mediocre programmers? What works for the most talented programmers isn't necessarily going to work for your team. In my experience the choice of the right tech is primarily a business decision rather than a technical one. By that I mean it should be based on a number of factors external to the technology. Once you have clearly identified the business problem you are trying to solve, you have to think of the solution in terms of risk. For example, what is the up-front development risk? What are the maintenance risks? Every project exists within a certain environment with its own set of constraints. Picking the right solution means understanding these and doing so from the point of view of the business. If you understand the risks and constraints, and you put the needs of your end-users, the systems administrators, the testers, and the business first you will rarely go off-track.
    - jl6 9y ago
      Not that I really disagree with you, but I find that "risks", "constraints", "end-users", "systems administrators", "testers", and "the business" are six separate forces, each pulling in their own direction, and you can't put them all first.
      - ac2u 9y ago
        Find myself in agreement with both of you. As you say you can't put them all first, however I've found anecdotally that risk and constraints are disproportionally placed last in many orgs. Of course, there's the opposite extreme too, where long time team members and management ivory-tower themselves to micromanage every tech choice and then prescribe it throughout an organisation without much input.
eeZah7Ux 9y ago
> I don't think microservices, react, functional programming or no sql are examples of 'hype'; I think those are good engineering decisions (depending on the problem domain). Hype does not mean that a popular technology should never be used. It's when people overrate and overuse it and try to apply it to the wrong domain. The examples are spot on.
- k__ 9y ago
  Yes, for example NoSQL and MongoDB . Ppl had no idea about relational databases and thought that's a good case for not using them.
  - threeseed 9y ago
    Yes. Google and Facebook who pioneered NoSQL with BigTable, HBase, Cassandra etc have no idea about relational databases. Likewise all of the enterprise companies who have spent tens of millions on relational EDW systems and are adopting NoSQL in droves also don't understand what they are doing. But thankfully we have some no-name developer to save us from all of these mistakes. No use cases for NoSQL. Give us a break.
    - k__ 9y ago
      Oh, so now we're beating strawmen again. Nice!
    - cholantesh 9y ago
      They didn't say the technology itself was poor, but that people have misused it. >we have some no-name developer to save us from all of these mistakes. Both rude and fallacious. Do you presume that every employee at a successful firm is a wunderkind? Do you actually know the level of talent of every HN poster?
    - goatlover 9y ago
      Relational databases have their advantages and disadvantages just like NoSQL. They both make tradeoffs. Taking the trouble to understand which is the right tool for the job instead of following the latest fashion trend is what the article is about.
jsnathan 9y ago
> I don't think microservices, react, functional programming or no sql are examples of 'hype'; I think those are good engineering decisions (depending on the problem domain). > I mean, I get what the article is saying, yeah yeah, avoid the hype, don't drink the 'webscale' cool-aid... I feel like you're shooting right past the author's point here. What he's saying is that hype, as in the shared excitement, obscures the actual tradeoffs involved in adopting the new technology, and makes it harder to make good engineering decisions. I'd like to add that it also obscures the available alternatives - simple and straightforward ways to configure / extend existing technologies to have the same behavior / features as that shiny new thing. And it's not even about what you know ahead of time. I was actually thinking about this earlier today: I often recognize some of the tradeoffs of adopting a new tech early on, but my judgement still often ends up clouded by enthusiasm. A common pattern of rationalization I often have goes like this: "Sure this old thing can be used to do the same as this new thing by using functions X,Y,Z, but this new thing lets you do it with just one function. I mean sure, I could write that function myself in about 10 lines, and I only need to do this once for each project, but this is just easier." I'm not saying that this reasoning is wrong, only that it is biased. Tradeoffs of a technology, and therefore knowing in which problem domain they are most appropriate, consist of both pros and cons. The problem with hype isn't that the technology being hyped is not excellent in its own way, the problem is that (psychologically) hype leads us to ignore the cons, to rationalize them away - and this means we're not really fairly considering the tradeoffs. The author isn't saying that microservices, react, Elixir, NoSQL, etc don't have upsides, but only that (if we are not extra careful) we might not be considering the tradeoffs and alternatives as pragmatically as we think we do.
tigershark 9y ago
These are perfect examples of cargo cult and your comment confirms it. Just because some successful company adopts a technology it doesn't mean that it suits your needs. You could have completely different problems and adopting those solutions can be in the very best case useless and in all the other cases harmful. You need to adopt a solution because it fits your problem, not because "the most successful companies in the world" are using it. It's always a good thing to know that these technologies exists and what are they used for, but jumping on the hype wagon without understanding deeply the original problem that they solve, how the solution works, and most importantly if it applies to your use case trying it with some representative, real work in your project, it is a sure recipe for failure.
- sanderjd 9y ago
  This is not charitable to the comment you replied to. That comment suggested that looking at what companies have had success with is a no-brainer, and you interred they were suggesting "jumping on the hype wagon without understanding deeply the original problem that they solve". Here, I'll quote: > You'd be stupid to not look at what the best and most successful companies in the world are doing with their engineering teams and take note of it. I think you're both saying the same thing. People should look at what others are doing, and analyze the suitability to their own use case. I think this is exactly what people do. I've never seen a tool choice postmortem that concluded, "well we only chose it for hype, and that was stupid". It's always a specific thing that you thought would work better than it did. For example, I came away from a project quite burned by Angular 1.x. It wasn't that we chose it because of hype that it was a poor choice, it was that the directive system did not make it as easy to build modular components as initial prototypes suggested it would be. React was then interesting to us (though we never pursued it on that project), not because of upvotes on HN, but because it scratched that itch better. I guess I just don't see this wild hype cycle that everyone complains about - I just see people trying to scratch itches they have, sometimes making the right choice, and sometimes making the wrong choice.
- v89 9y ago
  I agree, I thought the article was kind of BS-y until it got to the example section which I thought was spot on.
JustSomeNobody 9y ago
> ...but hey, the internet is full of really talented smart people who do excellent engineering work. It's actually not. It's full of average people who do mediocre engineering.
coldtea 9y ago
>I don't think microservices, react, functional programming or no sql are examples of 'hype'; I think those are good engineering decisions (depending on the problem domain). The two are orthogonal. Hype is a marketing force which can be used to tout good and bad stuff. Teams can just as well adopt a good product if its hyped. That doesn't mean their adoption process was based on a "good engineering decision". Just that they lucked onto making one. That said, I find "microservices" or "no sql" as more hype than substance in the domains that most teams apply them. They just reimplement (poorly) a ton of stuff that a monolith or sql would already have, and don't really need either for their use case.
tedmiston 9y ago
I've definitely seen overuse of React, microservices, and NoSQL databases before it makes sense or when it's actually a detriment to complexity. This point from the article however, I agree is a bad example. > Example 2: TDD is dead by DHH The 37signals guys if anything are some of the realest in terms of low fidelity tools and sensible abstractions and building things simply. They've even written two books about their approach to business and web app development (Rework, Getting Reals). Maybe there is concentrated hype around Rails but in general their stuff is well informed and well thought out.

mgkimsal 9y ago

> I think those are good engineering decisions (depending on the problem domain). The "depending on the problem domain" seems another variant of "choose the right tool for the right job". One could probably add "for the right reason" on the end of that instruction too, and it wouldn't hurt. The problem is the ability to determine "the right tool" and "the right job" - many people simply don't have it. You only get that ability through experience. With new tools few people - even older folks - have enough experience with the tool in question to make accurate/useful assessments. > but hey, the internet is full of really talented smart people who do excellent engineering work. And it's full of even more people who aren't really capable of making those assessments accurately. > You'd be stupid to not look at what the best and most successful companies in the world are doing with their engineering teams and take note of it. You'd be stupid to think that because "Facebook" (or "Amazon" or "Google" or "MS") is using a particular tech stack (which, likely, teams of internal people contributed to for months), it's a great fit for your problem, or your skills, or your team's skills, or your project's timeline, or its budget. Few people have the problems or demands that Facebook/Amazon/Google/etc have. It's great that they share some of their internal tech, but that sharing isn't an automatic determination that their solutions are appropriate fits for your problems.

shadowmint 9y ago
This basically what I'm talking about. Ok, if what the smartest and best people are doing isnt the right solution for my problem, what is? Come on; enough vague hand waving. How do you pick the right tech to use then?
- deleted 9y ago
  [deleted]
- BaronSamedi 9y ago
  What if your development team is made up of mediocre programmers? What works for the most talented programmers isn't necessarily going to work for your team. In my experience the choice of the right tech is primarily a business decision rather than a technical one. By that I mean it should be based on a number of factors external to the technology. Once you have clearly identified the business problem you are trying to solve, you have to think of the solution in terms of risk. For example, what is the up-front development risk? What are the maintenance risks? Every project exists within a certain environment with its own set of constraints. Picking the right solution means understanding these and doing so from the point of view of the business. If you understand the risks and constraints, and you put the needs of your end-users, the systems administrators, the testers, and the business first you will rarely go off-track.
  - jl6 9y ago
    Not that I really disagree with you, but I find that "risks", "constraints", "end-users", "systems administrators", "testers", and "the business" are six separate forces, each pulling in their own direction, and you can't put them all first.
    - ac2u 9y ago
      Find myself in agreement with both of you. As you say you can't put them all first, however I've found anecdotally that risk and constraints are disproportionally placed last in many orgs. Of course, there's the opposite extreme too, where long time team members and management ivory-tower themselves to micromanage every tech choice and then prescribe it throughout an organisation without much input.

eeZah7Ux 9y ago

> I don't think microservices, react, functional programming or no sql are examples of 'hype'; I think those are good engineering decisions (depending on the problem domain). Hype does not mean that a popular technology should never be used. It's when people overrate and overuse it and try to apply it to the wrong domain. The examples are spot on.

k__ 9y ago
Yes, for example NoSQL and MongoDB . Ppl had no idea about relational databases and thought that's a good case for not using them.
- threeseed 9y ago
  Yes. Google and Facebook who pioneered NoSQL with BigTable, HBase, Cassandra etc have no idea about relational databases. Likewise all of the enterprise companies who have spent tens of millions on relational EDW systems and are adopting NoSQL in droves also don't understand what they are doing. But thankfully we have some no-name developer to save us from all of these mistakes. No use cases for NoSQL. Give us a break.
  - k__ 9y ago
    Oh, so now we're beating strawmen again. Nice!
  - cholantesh 9y ago
    They didn't say the technology itself was poor, but that people have misused it. >we have some no-name developer to save us from all of these mistakes. Both rude and fallacious. Do you presume that every employee at a successful firm is a wunderkind? Do you actually know the level of talent of every HN poster?
  - goatlover 9y ago
    Relational databases have their advantages and disadvantages just like NoSQL. They both make tradeoffs. Taking the trouble to understand which is the right tool for the job instead of following the latest fashion trend is what the article is about.

jsnathan 9y ago

> I don't think microservices, react, functional programming or no sql are examples of 'hype'; I think those are good engineering decisions (depending on the problem domain). > I mean, I get what the article is saying, yeah yeah, avoid the hype, don't drink the 'webscale' cool-aid... I feel like you're shooting right past the author's point here. What he's saying is that hype, as in the shared excitement, obscures the actual tradeoffs involved in adopting the new technology, and makes it harder to make good engineering decisions. I'd like to add that it also obscures the available alternatives - simple and straightforward ways to configure / extend existing technologies to have the same behavior / features as that shiny new thing. And it's not even about what you know ahead of time. I was actually thinking about this earlier today: I often recognize some of the tradeoffs of adopting a new tech early on, but my judgement still often ends up clouded by enthusiasm. A common pattern of rationalization I often have goes like this: "Sure this old thing can be used to do the same as this new thing by using functions X,Y,Z, but this new thing lets you do it with just one function. I mean sure, I could write that function myself in about 10 lines, and I only need to do this once for each project, but this is just easier." I'm not saying that this reasoning is wrong, only that it is biased. Tradeoffs of a technology, and therefore knowing in which problem domain they are most appropriate, consist of both pros and cons. The problem with hype isn't that the technology being hyped is not excellent in its own way, the problem is that (psychologically) hype leads us to ignore the cons, to rationalize them away - and this means we're not really fairly considering the tradeoffs. The author isn't saying that microservices, react, Elixir, NoSQL, etc don't have upsides, but only that (if we are not extra careful) we might not be considering the tradeoffs and alternatives as pragmatically as we think we do.

tigershark 9y ago

These are perfect examples of cargo cult and your comment confirms it. Just because some successful company adopts a technology it doesn't mean that it suits your needs. You could have completely different problems and adopting those solutions can be in the very best case useless and in all the other cases harmful. You need to adopt a solution because it fits your problem, not because "the most successful companies in the world" are using it. It's always a good thing to know that these technologies exists and what are they used for, but jumping on the hype wagon without understanding deeply the original problem that they solve, how the solution works, and most importantly if it applies to your use case trying it with some representative, real work in your project, it is a sure recipe for failure.

sanderjd 9y ago
This is not charitable to the comment you replied to. That comment suggested that looking at what companies have had success with is a no-brainer, and you interred they were suggesting "jumping on the hype wagon without understanding deeply the original problem that they solve". Here, I'll quote: > You'd be stupid to not look at what the best and most successful companies in the world are doing with their engineering teams and take note of it. I think you're both saying the same thing. People should look at what others are doing, and analyze the suitability to their own use case. I think this is exactly what people do. I've never seen a tool choice postmortem that concluded, "well we only chose it for hype, and that was stupid". It's always a specific thing that you thought would work better than it did. For example, I came away from a project quite burned by Angular 1.x. It wasn't that we chose it because of hype that it was a poor choice, it was that the directive system did not make it as easy to build modular components as initial prototypes suggested it would be. React was then interesting to us (though we never pursued it on that project), not because of upvotes on HN, but because it scratched that itch better. I guess I just don't see this wild hype cycle that everyone complains about - I just see people trying to scratch itches they have, sometimes making the right choice, and sometimes making the wrong choice.
v89 9y ago
I agree, I thought the article was kind of BS-y until it got to the example section which I thought was spot on.

JustSomeNobody 9y ago

> ...but hey, the internet is full of really talented smart people who do excellent engineering work. It's actually not. It's full of average people who do mediocre engineering.

coldtea 9y ago

>I don't think microservices, react, functional programming or no sql are examples of 'hype'; I think those are good engineering decisions (depending on the problem domain). The two are orthogonal. Hype is a marketing force which can be used to tout good and bad stuff. Teams can just as well adopt a good product if its hyped. That doesn't mean their adoption process was based on a "good engineering decision". Just that they lucked onto making one. That said, I find "microservices" or "no sql" as more hype than substance in the domains that most teams apply them. They just reimplement (poorly) a ton of stuff that a monolith or sql would already have, and don't really need either for their use case.

tedmiston 9y ago

I've definitely seen overuse of React, microservices, and NoSQL databases before it makes sense or when it's actually a detriment to complexity. This point from the article however, I agree is a bad example. > Example 2: TDD is dead by DHH The 37signals guys if anything are some of the realest in terms of low fidelity tools and sensible abstractions and building things simply. They've even written two books about their approach to business and web app development (Rework, Getting Reals). Maybe there is concentrated hype around Rails but in general their stuff is well informed and well thought out.