8 ms·

This seems to be written from the "Engineers are monkeys" perspective. As if they spend their time flinging poo and you really need "solid" boing technology th

by MCRed 12y ago

This seems to be written from the "Engineers are monkeys" perspective. As if they spend their time flinging poo and you really need "solid" boing technology that's already well designed so the poo doesn't mess it up. You shouldn't choose node.js or MongoDB because they are "innovative"-- but because they are poorly engineered. (Erlang did what node does but much better, and MongoDB is poorly engineered global write lock mess that is probably better now but whose hype way exceeded its quality for many years.) The engineers are monkey's idea is that engineers can't tell the difference-- and it seems to be supported by the popularity of those two technologies. But if you know what you're doing, you choose good technologies-- Elixir is less than a year old but its built on the boring 20 years of work that has been done in Erlang. Couchbase is very innovative but it's built on nearly a decade of couchdb and memcache work. You choose the right technologies and they become silver bullets that really make your project much more productive. Boring technologies often have a performance (in time to market terms) cost to them. Really you can't apply rules of thumb like this and the "innovation tokens" idea is silly. I say this having done a product in 6 months with 4 people that should have taken 12 people 12 months to do, using Elixir (not even close to 1.0 of elixir even) and couchbase and trying out some of my "wacky" ideas for how a web platform should be built-- yes, I was using cutting edge new ideas in this thing that we took to production very quickly. The difference? Those four engineers were all good. Not all experienced-- one had been programming less than a year-- but all good. Seems everyone talks about finding good talent and how important that is but they don't seem to be able to do it. I don't know. I do know is, don't use "engineers are monkies" rules of thumb-- just hire human engineers.

AlisdairO 12y ago
My take tends to be not that 'innovation' is bad, but that there are a couple of risks: - The weaknesses of new tech may not be fully understood. A lot of new tech solves existing problems, while re-surfacing problems that the old tech solved. Everyone thinks it's great until they've used it for a bit longer, and run into those issues. - New tech runs a higher risk of disappearing/becoming unsupported. If you plan to support your product for a long time, that's a valid risk factor. For myself, I'm wary of having very new tech as a fundamental underpinning of any piece of work I need to stick around. I'll likely adopt frameworks or database systems cautiously, unless their superiority is overwhelmingly obvious. On the other hand, I'd be a lot more willing to take risks on a simple library. With a smaller, simpler piece of tech, it's easier to replace if something goes awry, and it's easier to evaluate in its totality prior to taking the risk.
- arenaninja 12y ago
  I agree with this. That being said, the author of the post seems to knock 'the right tool for the job', but I recently built two scrapers: one that scrapes an API (one time thing) and one that scrapes some websites (will probably be used once a month). The API one runs on PHP and auto-refreshes with a <meta> tag -- boring, but it works. The one that scrapes websites I did with Node since some sites are multi-steps and the latency of a single scrape, plus the database latency could've turned this into a multi-week run with PHP
- wdewind 12y ago
  It's not only that, it's also that if you have two languages in your codebase you now need two ways to deploy, two types of application servers, two types of testing frameworks/QA setups etc. If having the two languages means you can create a product only marginally faster/better then it is not worth all of that overhead. As mentioned in the article, there are places where the cost becomes worth it, for instance faceted searching is done in Java via Solr at Etsy. But for the most part fitting your problem into the existing infrastructure is a lot better for the organization than bringing in the perfect technology.
exelius 12y ago
Individual humans are smart. Groups of humans are dumb. When you're hiring people that you will personally work with, you can filter for smart. When you have to work with another group of humans, it's safer to assume that they are stupid.
- nostrademons 12y ago
  ...or, without resorting to labels: Groups are a low-pass filter on the abilities of the individuals that compose them. To teach something to a group, you have to communicate it to every member; this communication is naturally bound by the ability to understand of the person who is least familiar (or least enthusiastic) about the particular tech. You can often cut the time needed for a complex project in half simply by cutting the team in half and telling each group to work on it independently. The problem is that now you have two problems - or rather, two solutions. If you try to integrate them together, you end up reintroducing all the communication hassles and more. If you throw one out, you'll alienate and probably lose all the developers who worked on it. If you bring both to market, you confuse your customers and lose brand equity.
- cubano 12y ago
  > Individual humans are smart. Groups of humans are dumb. Actually, you have that exactly wrong[1]. "Behavioural economists and sociologists have gone beyond the anecdotic and systematically studied the issues, and have come up with surprising answers. Capturing the ‘collective’ wisdom best solves cognitive problems. Four conditions apply. There must be: (a) true diversity of opinions; (b) independence of opinion (so there is no correlation between them); (c) decentralisation of experience; (d) suitable mechanisms of aggregation." [1] http://www.diplomacy.edu/resources/books/reviews/wisdom-crowds-why-many-are-smarter-few http://www.diplomacy.edu/resources/books/reviews/wisdom-crow...
  - nostrademons 12y ago
    "Crowds" != "Groups". In a crowd, the individuals behave independently; each person makes their own judgment as to the best course of action and pursues it. In a group, the individuals are constrained to come to a collective decision and implement it. That difference is crucial. Markets function based on the wisdom of crowds; they work because if one person has the right information but everybody else is dumb, the one iconoclast stands to make a lot of money and force out all the dumb people. Statistics function according to the wisdom of crowds; it works because errors contribute little to the mean, while most people, arriving independently at their conclusion, tend to be closer. Groups all have to agree on the same conclusion. When this condition occurs, the only conclusion that they can agree on is one that can be communicated to all members of the group, which is necessarily limited by the ability of the weakest group member to understand it.
wdewind 12y ago
Having come from Etsy and witnessed the success of this type of thinking first hand, I think you missed the point of the article and I think you are using a tiny engineering organization (4 people) in your thinking, instead of a medium to large one (120+ engineers). The problem isn't "we are starting a new codebase with 4 engineers, are we qualified to choose the right technology?" it's "we are solving a new problem, within a massive org/codebase, that could probably be solved more directly with a different set of technologies than the existing ones the rest of the company is using. Is that worth the overhead?" and the answer is almost always no. Ie: is local optimization worth the overhead? Local optimization is extremely tempting no matter who you are, where you are. It's always easy to reach a point of frustration and come to the line of reasoning of "I don't get why we are wasting so much time to ship this product using the 'old' stuff when we could just use 'newstuff' and get it out the door in the next week." This happens to engineers of all levels, especially in a continuous deployment, "Just Ship" culture. The point of the article is that local optimization gives you this tiny boost in the beginning for a long term cost that eventually moves the organization is a direction of shipping less. It's not that innovative technologies are bad. > But if you know what you're doing, you choose good technologies No, if you know what you are doing you make good organizational decisions. It matters less what technology you use than that the entire organization uses the same technology. Etsy has a great engineering team and yet the entire site is written in PHP. I don't think there is a single engineer working at Etsy who thinks PHP is the best language out there, but the decision to be made at the time was "there is a site using PHP, some Python, some Ruby etc., how do we make this easier to work on?" Of those three python and ruby are almost universally thought of as better languages than PHP, but in this case the correct decision was picking a worse technology because more of the site was written in it, the existing infrastructure supported it more completely and so as an organization and a business we could get back to shipping products more quickly by all agreeing to use PHP. Etsy certainly does not think of its engineers as monkeys, quite the opposite.
- pnathan 12y ago
  Pedantic note: large-scale engineering organizations have an additional two zeros in their order of magnitude: 10,000+ engineers. ;-) But you're quite right. This is part of the reason why Java has been so successful - it's both boring and well supported.
calibraxis 12y ago
Yes, this "boring = good!" trope is frequently weaponized to shut down people's voices. Happened to me. One thing I realized is these blogposts are consumerist. They talk about "Python" and "MongoDB". Very little about underlying ideas like "algorithms", "computational paradigms" or "expressive power". And they have hypersimplified plans about "three innovation tokens". Instead of "risk analysis" or "evaluate tradeoffs". One company shut me down with such blogposts... while it let devs run amok with an architecture which did n^2 (more?) network calls... where each call transfered one RDBMS row at a time. It dragged down the intelligence of everyone who really knew better; they spent "sprints" trying to find micro-optimizations, knowing exactly that the system was fundamentally ridiculous. So I spent a weekend reimplementing it in the Scary Fun Language. Because it was my weekend dammit, and Embracing Boredom damaged my brain too much. Scary Fun was the only way to start mending it. And it succeeded. So of course the first order of business was to rewrite it in the Embrace Boredom language.
- duderific 12y ago
  > where each call transfered one RDBMS row at a time. Surely this is not the fault of boring technology, but rather poor design. You can easily make the same mistake using the latest and greatest.
  - jfb 12y ago
    I think it's more nuanced; certain technologies afford certain designs. There really are differences in languages, and those differences expose users to different misbehaviors -- or the dual, to different optimizations.
  - InclinedPlane 12y ago
    I think the point the parent was making was that using terminology like "scary" or "boring" for technological choices is fundamentally an abrogation of responsibility. It's cargo cult programming. Good programming, intentional engineering, is one where people are cognizant of the risks and other tradeoffs of different languages, frameworks, designs, etc. It shouldn't be surprising that an organization that opted out of a discussion on technology stacks would also ultimately opt out of discussing algorithmic complexity as well, it speaks to a lack of sophistication and maturity at the institutional level.
fullwedgewhale 12y ago
I'll throw another one down your way. An organization I worked with had a about 5 million lines of COBOL in one system (they had several more and this one systems was only about 15% of their total transactional workload). It used a proprietary pre-relational database that allowed users to do both queries (of a sort) and do things like the value from the query result + 1500 bytes. They tried re-writing pieces in Java at a cost of tens of millions of dollars. Java was the new hotness. In addition, they built out a Java hosting environment using expensive, proprietary Unix hardware to reach the same production volume as the mainframe. However, it was grossly under-utilized because the Java code couldn't do much more than ask the COBOL code what the answer was to a question by using Message queues. More millions of dollars went to keep up licenses and support contracts on essentially idle hardware. They tried moving it to Windows, using .NET and MicroFocus COBOL. But the problem was they would still be tied to COBOL, even though they (conceptually) had a path to introduce .NET components or to wrap the green-screen pieces in more updated UIs. But that in itself was a problem because all their people knew the greenscreen UI so well it was all muscle memory. Several workers complained because new GUI actually made them slower at their jobs. They were stuck because they had no way to reverse engineer the requirements from the COBOL code, some of it going back 25+ years. Of course it wasn't documented, or if it was, the documentation was long gone. For the most part they were tied to that COBOL code because no one understood everything that it did and there were only a handful of COBOL programmers left in their shop (I think 6) and they were busy making emergency fixes on that + several other millions of lines of code in other systems. They were, however, looking for an argument to retire COBOL and retire the mainframes. The cheapest solution would have been to stick with COBOL. Hire programmers. Teach them COBOL (because it was painfully difficult to find any new COBOL people and for various reasons they could not off-shore the project). Continue to develop and fix in COBOL (especially before the last remaining COBOL programmers died or retired). If you cleaned up or fixed a module, maybe move it to Java when possible. The long story short is the decision to introduce a new technology, even in the face of an ancient, largely proprietary (since it's really about IBM COBOL on mainframes), and over-priced solution can actually lead to a worse outcome. Had they stayed with boring technology. Had they in-sourced more of their COBOL workforce. They might not have felt happy, but they would have been in a much strong, better position. Instead they were paying for a mainframe, and a proprietary Unix server farm, and software licenses on both Unix and z/OS. When I last was there they were buying a new solution from Oracle which was supposed to arrive racked up and ready to go. Several weeks in they essentially said it would take months before the first of the new Oracle servers would be ready for an internal cloud deployment on which to try to re-host some software. I'm not even sure what they think they would be re-hosting but they talked about automatic translation of COBOL to Java.
hackerboos 12y ago
> Elixir is less than a year old Just a small correction. Elixir was started in 2012. I assume you mean less than 1 year since version 1.0?

by MCRed 12y ago

AlisdairO 12y ago

My take tends to be not that 'innovation' is bad, but that there are a couple of risks: - The weaknesses of new tech may not be fully understood. A lot of new tech solves existing problems, while re-surfacing problems that the old tech solved. Everyone thinks it's great until they've used it for a bit longer, and run into those issues. - New tech runs a higher risk of disappearing/becoming unsupported. If you plan to support your product for a long time, that's a valid risk factor. For myself, I'm wary of having very new tech as a fundamental underpinning of any piece of work I need to stick around. I'll likely adopt frameworks or database systems cautiously, unless their superiority is overwhelmingly obvious. On the other hand, I'd be a lot more willing to take risks on a simple library. With a smaller, simpler piece of tech, it's easier to replace if something goes awry, and it's easier to evaluate in its totality prior to taking the risk.

arenaninja 12y ago
I agree with this. That being said, the author of the post seems to knock 'the right tool for the job', but I recently built two scrapers: one that scrapes an API (one time thing) and one that scrapes some websites (will probably be used once a month). The API one runs on PHP and auto-refreshes with a <meta> tag -- boring, but it works. The one that scrapes websites I did with Node since some sites are multi-steps and the latency of a single scrape, plus the database latency could've turned this into a multi-week run with PHP
wdewind 12y ago
It's not only that, it's also that if you have two languages in your codebase you now need two ways to deploy, two types of application servers, two types of testing frameworks/QA setups etc. If having the two languages means you can create a product only marginally faster/better then it is not worth all of that overhead. As mentioned in the article, there are places where the cost becomes worth it, for instance faceted searching is done in Java via Solr at Etsy. But for the most part fitting your problem into the existing infrastructure is a lot better for the organization than bringing in the perfect technology.

exelius 12y ago

Individual humans are smart. Groups of humans are dumb. When you're hiring people that you will personally work with, you can filter for smart. When you have to work with another group of humans, it's safer to assume that they are stupid.

nostrademons 12y ago
...or, without resorting to labels: Groups are a low-pass filter on the abilities of the individuals that compose them. To teach something to a group, you have to communicate it to every member; this communication is naturally bound by the ability to understand of the person who is least familiar (or least enthusiastic) about the particular tech. You can often cut the time needed for a complex project in half simply by cutting the team in half and telling each group to work on it independently. The problem is that now you have two problems - or rather, two solutions. If you try to integrate them together, you end up reintroducing all the communication hassles and more. If you throw one out, you'll alienate and probably lose all the developers who worked on it. If you bring both to market, you confuse your customers and lose brand equity.
cubano 12y ago
> Individual humans are smart. Groups of humans are dumb. Actually, you have that exactly wrong[1]. "Behavioural economists and sociologists have gone beyond the anecdotic and systematically studied the issues, and have come up with surprising answers. Capturing the ‘collective’ wisdom best solves cognitive problems. Four conditions apply. There must be: (a) true diversity of opinions; (b) independence of opinion (so there is no correlation between them); (c) decentralisation of experience; (d) suitable mechanisms of aggregation." [1] http://www.diplomacy.edu/resources/books/reviews/wisdom-crowds-why-many-are-smarter-few http://www.diplomacy.edu/resources/books/reviews/wisdom-crow...
- nostrademons 12y ago
  "Crowds" != "Groups". In a crowd, the individuals behave independently; each person makes their own judgment as to the best course of action and pursues it. In a group, the individuals are constrained to come to a collective decision and implement it. That difference is crucial. Markets function based on the wisdom of crowds; they work because if one person has the right information but everybody else is dumb, the one iconoclast stands to make a lot of money and force out all the dumb people. Statistics function according to the wisdom of crowds; it works because errors contribute little to the mean, while most people, arriving independently at their conclusion, tend to be closer. Groups all have to agree on the same conclusion. When this condition occurs, the only conclusion that they can agree on is one that can be communicated to all members of the group, which is necessarily limited by the ability of the weakest group member to understand it.

wdewind 12y ago

Having come from Etsy and witnessed the success of this type of thinking first hand, I think you missed the point of the article and I think you are using a tiny engineering organization (4 people) in your thinking, instead of a medium to large one (120+ engineers). The problem isn't "we are starting a new codebase with 4 engineers, are we qualified to choose the right technology?" it's "we are solving a new problem, within a massive org/codebase, that could probably be solved more directly with a different set of technologies than the existing ones the rest of the company is using. Is that worth the overhead?" and the answer is almost always no. Ie: is local optimization worth the overhead? Local optimization is extremely tempting no matter who you are, where you are. It's always easy to reach a point of frustration and come to the line of reasoning of "I don't get why we are wasting so much time to ship this product using the 'old' stuff when we could just use 'newstuff' and get it out the door in the next week." This happens to engineers of all levels, especially in a continuous deployment, "Just Ship" culture. The point of the article is that local optimization gives you this tiny boost in the beginning for a long term cost that eventually moves the organization is a direction of shipping less. It's not that innovative technologies are bad. > But if you know what you're doing, you choose good technologies No, if you know what you are doing you make good organizational decisions. It matters less what technology you use than that the entire organization uses the same technology. Etsy has a great engineering team and yet the entire site is written in PHP. I don't think there is a single engineer working at Etsy who thinks PHP is the best language out there, but the decision to be made at the time was "there is a site using PHP, some Python, some Ruby etc., how do we make this easier to work on?" Of those three python and ruby are almost universally thought of as better languages than PHP, but in this case the correct decision was picking a worse technology because more of the site was written in it, the existing infrastructure supported it more completely and so as an organization and a business we could get back to shipping products more quickly by all agreeing to use PHP. Etsy certainly does not think of its engineers as monkeys, quite the opposite.

pnathan 12y ago
Pedantic note: large-scale engineering organizations have an additional two zeros in their order of magnitude: 10,000+ engineers. ;-) But you're quite right. This is part of the reason why Java has been so successful - it's both boring and well supported.

calibraxis 12y ago

Yes, this "boring = good!" trope is frequently weaponized to shut down people's voices. Happened to me. One thing I realized is these blogposts are consumerist. They talk about "Python" and "MongoDB". Very little about underlying ideas like "algorithms", "computational paradigms" or "expressive power". And they have hypersimplified plans about "three innovation tokens". Instead of "risk analysis" or "evaluate tradeoffs". One company shut me down with such blogposts... while it let devs run amok with an architecture which did n^2 (more?) network calls... where each call transfered one RDBMS row at a time. It dragged down the intelligence of everyone who really knew better; they spent "sprints" trying to find micro-optimizations, knowing exactly that the system was fundamentally ridiculous. So I spent a weekend reimplementing it in the Scary Fun Language. Because it was my weekend dammit, and Embracing Boredom damaged my brain too much. Scary Fun was the only way to start mending it. And it succeeded. So of course the first order of business was to rewrite it in the Embrace Boredom language.

duderific 12y ago
> where each call transfered one RDBMS row at a time. Surely this is not the fault of boring technology, but rather poor design. You can easily make the same mistake using the latest and greatest.
- jfb 12y ago
  I think it's more nuanced; certain technologies afford certain designs. There really are differences in languages, and those differences expose users to different misbehaviors -- or the dual, to different optimizations.
- InclinedPlane 12y ago
  I think the point the parent was making was that using terminology like "scary" or "boring" for technological choices is fundamentally an abrogation of responsibility. It's cargo cult programming. Good programming, intentional engineering, is one where people are cognizant of the risks and other tradeoffs of different languages, frameworks, designs, etc. It shouldn't be surprising that an organization that opted out of a discussion on technology stacks would also ultimately opt out of discussing algorithmic complexity as well, it speaks to a lack of sophistication and maturity at the institutional level.

fullwedgewhale 12y ago

I'll throw another one down your way. An organization I worked with had a about 5 million lines of COBOL in one system (they had several more and this one systems was only about 15% of their total transactional workload). It used a proprietary pre-relational database that allowed users to do both queries (of a sort) and do things like the value from the query result + 1500 bytes. They tried re-writing pieces in Java at a cost of tens of millions of dollars. Java was the new hotness. In addition, they built out a Java hosting environment using expensive, proprietary Unix hardware to reach the same production volume as the mainframe. However, it was grossly under-utilized because the Java code couldn't do much more than ask the COBOL code what the answer was to a question by using Message queues. More millions of dollars went to keep up licenses and support contracts on essentially idle hardware. They tried moving it to Windows, using .NET and MicroFocus COBOL. But the problem was they would still be tied to COBOL, even though they (conceptually) had a path to introduce .NET components or to wrap the green-screen pieces in more updated UIs. But that in itself was a problem because all their people knew the greenscreen UI so well it was all muscle memory. Several workers complained because new GUI actually made them slower at their jobs. They were stuck because they had no way to reverse engineer the requirements from the COBOL code, some of it going back 25+ years. Of course it wasn't documented, or if it was, the documentation was long gone. For the most part they were tied to that COBOL code because no one understood everything that it did and there were only a handful of COBOL programmers left in their shop (I think 6) and they were busy making emergency fixes on that + several other millions of lines of code in other systems. They were, however, looking for an argument to retire COBOL and retire the mainframes. The cheapest solution would have been to stick with COBOL. Hire programmers. Teach them COBOL (because it was painfully difficult to find any new COBOL people and for various reasons they could not off-shore the project). Continue to develop and fix in COBOL (especially before the last remaining COBOL programmers died or retired). If you cleaned up or fixed a module, maybe move it to Java when possible. The long story short is the decision to introduce a new technology, even in the face of an ancient, largely proprietary (since it's really about IBM COBOL on mainframes), and over-priced solution can actually lead to a worse outcome. Had they stayed with boring technology. Had they in-sourced more of their COBOL workforce. They might not have felt happy, but they would have been in a much strong, better position. Instead they were paying for a mainframe, and a proprietary Unix server farm, and software licenses on both Unix and z/OS. When I last was there they were buying a new solution from Oracle which was supposed to arrive racked up and ready to go. Several weeks in they essentially said it would take months before the first of the new Oracle servers would be ready for an internal cloud deployment on which to try to re-host some software. I'm not even sure what they think they would be re-hosting but they talked about automatic translation of COBOL to Java.

hackerboos 12y ago

> Elixir is less than a year old Just a small correction. Elixir was started in 2012. I assume you mean less than 1 year since version 1.0?