Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Choose Boring Technology (2015)

boringtechnology.club

Post reply on HN
Print view View original

81–90 of 374 posts

Re: Choose Boring Technology (2015)

#81

Post by user5994461 »

yters wrote: post #52

My internal devops group has this issue. We had a working system on teamcity and the hashicorp stack and linkerd. Now we are working on a brand new system using gitlab and openshift and istio. Highly redundant with, from my perspective, only incremental advantage. At the beginning I spoke out against this, but failed to convince anyone. Progress has been alright because of our new 10x hire who hated the old tech and…

I'm surprised one guy can bring in gitlab, openshift, and istio all by himself. They're not small things to setup and to migrate existing software to.

Typically how this goes, few of the existing software migrate to the new stack (it's too much work to migrate and it doesn't work as well). After the guy is gone, you can deprecate the new stack immediately and don't bother supporting it. I've seen it happen a lot.

What you don't say is how large the company is. For startups and small companies, my experience is that every generation of developers (couple years) will rewrite most of everything. That's just how things go in startup, filled by eager young folks who have no experience and build their resume. That's only possible because there isn't that much code in the first place.

Larger companies can be stuck with multiple stacks because there's too many software to migrate and no sucker to do it. Older projects are stable and have no active developers working on them, they're not going to be rearchitectured. Other departments/developers know that they can't trust the shiny new tool from your department, that's going to be deprecated next year, they don't adopt in the first place (a great example of why large companies resist changes).

It's just the state of the industry I guess.

IMO it's crazy how few people working on tools/frameworks can inflict migrations on a hundred developers/projects (thousands in larger companies), often for no benefits.

I realize this doesn't answer your question, how to help?

No idea. Would be nice to cancel projects early before they reach that stage. It's probably too late now.

What you can improve is your perception. If it makes you feel better, one pro of all this churn is that there are many more jobs, doing rewrites over and over again. It's nice to have a job in the current climate.

Re: Choose Boring Technology (2015)

#82

Post by killingtime74 »

gonzo41 wrote: post #62
killingtime74 wrote: post #53

Does using Java but with native image (compiled to binary) count as using an innovation token due to new packaging or no (due to Java?)

It's a negative 1 because you could have made an EXE jar and run it with standard open jdk on the server.

True enough

Re: Choose Boring Technology (2015)

#83

Post by msvan »

A lot of new technology eventually becomes boring technology, and this is because of adoption in companies exactly in the way the author is discouraging. When the new becomes boring, everyone gets to reap the benefits of the new tech.

The world of software rests on the hard work of others, whether it's open source maintainers spending their free time making libraries for peanuts, or it's people going through the pain of productionizing a new technology. Being in the boring technology club is in a sense also being in the freeloader club, never contributing back to the state of the art.

It's a good article. It makes us aware of the drive many have to use the new thing, and the negative consequences of following this drive blindly. But I'm also happy that people do it.

Re: Choose Boring Technology (2015)

#84

Post by nhumrich »

hnedeotes wrote: post #22
wrnr wrote: post #18

This stack can be radically simplified: Apache: managing open connections. Memcache: holding stuff in memory. Postgresql: Save stuff to disk. Cron: Schedule things. Python: wire the above things together ... or a good reason the pick Go or Java

Or better, Elixir + Postgresql

Not sure elixir qualifies as "old and boring tech"

Re: Choose Boring Technology (2015)

#85

Post by chokeartist »

phendrenad2 wrote: post #2

I always found it funny that companies will go to extreme Herculean lengths to hire the best programmers, and are incredibly fearful and paranoid that they could be making a "bad hire", and yet once hired they don't spend a second making sure engineers aren't completely running the software product off the rails and killing the company internally. The author mentions trying to rewrite Etsy's backend in Scala and Mong…

> The last line of defense against a rogue engineering team is managers who have studied this stuff. How many engineering managers can spot the common situation "the engineers are bored and they're rewriting perfectly-good codebases in Common Lisp and OCAML for funsies"? And how many know what to do about it when they see it?

Also product managers (myself) who hold the P&L bag and tell folks like them to get fucking real when they are smoking dope.

Re: Choose Boring Technology (2015)

#86

Post by usrusr »

nizmow wrote: post #31
tpetry wrote: post #5

The problem with the non-boring technology club is that programmers see what problem FAANG companies are solving and wanting to be on the edge on new technology too. But they don‘t have the same problems. Another problem is they want to show what they can do. If they tell in an interview they are working with rails/django and a postgresql database they fear they look incompetent using those old technologies. So they…

Typically though, FAANGs still solve their problems with boring technologies.

They are big enough to follow all paths concurrently. The F is famously doing their own PHP and while the G was tickling "shiny receptors" all over the world with Go (which ironically could be seen as an example in boring technology enlightenment, considering how it is basically a modern take on 1980ies language features), they were also doing so much plain old java that the parts of the internal tooling they did for maintaining their own sanity published as Guava easily had more impact on the viability of java as a language than everything Oracle has ever released (yes, including Java 8 lambdas).

Re: Choose Boring Technology (2015)

#87

Post by mrweasel »

phendrenad2 wrote: post #2

I always found it funny that companies will go to extreme Herculean lengths to hire the best programmers, and are incredibly fearful and paranoid that they could be making a "bad hire", and yet once hired they don't spend a second making sure engineers aren't completely running the software product off the rails and killing the company internally. The author mentions trying to rewrite Etsy's backend in Scala and Mong…

That's definitely part of it. I also think developer sometimes aren't sufficiently critical when picking technologies and solutions. They fall into the trap of looking at how bigger companies operate, without considering if they actually have the same requirement, budget or even problem.

For example, you need a search feature. ElasticSearch is big in search, there's lots of article about people implementing ElasticSearch. Very infrequently do I meet people who just starts out with the full text search in their database, or maybe just try something extremely simple, like Sphinx, even if it would solve their problem quicker, safer and cheaper.

It's honestly starting to become a bigger and bigger issue. During the last few weeks I've talked to one customer who is think: Kubernetes. They don't have the funds, staff or need for Kubernetes. What they do need to do here and now is to focus on smarter utilisation of their cloud providers features and reduce the reliance on expensive VMs.

Another customer is going all in and wants to implement all the things. We're talking Kubernetes, Kafka, ElasticSearch and more. They'r are currently running on just a small number of VMs. While their stack does need updating, maybe start smaller?

Re: Choose Boring Technology (2015)

#88

Post by satyrnein »

threeseed wrote: post #36
iamacyborg wrote: post #33

Urgh, this feels familiar. Last year I left a company that was just wrapping up a new tech product, everything was microservices and mongodb. Trying to get a simple answer out of the engineering team about something as trivial as “how can I get a list of customers who have purchased product X” was almost impossible. They sure had fun building it though.

What does that even remotely have to do with micro-services or MongoDB ? If your query was exposed as a REST API you could have easily accessed it via a micro-service. And MongoDB has a pretty powerful and easy to use query language. I could've answered your query in about 5s. Sounds more like a business or process limitation.

It seems like you're assuming the data you need is all in one microservice. (In which case, why did you need microservices?)

Let's say the report needs data from across two microservices, one is backed by mongodb and one is mysql, and both services have been crud endpoints but not ones that will give you the full data you need. This is a pretty typical scenario! So you could make new endpoints, but then you still need to "join" the data in code. Or you could set up data pipelines to sync data into into a data warehouse, where you query across everything.

Or you could have kept everything in a monolith, and this would have actually been a 5 second SQL query.

Re: Choose Boring Technology (2015)

#89

Post by tonyedgecombe »

threeseed wrote: post #35
Svip wrote: post #32

This is why I prefer buying 15+ year old cars, you know everything that's wrong with them. OK, it just so happens that three cars I've owned has been over 15 years old when I bought them, but I haven't heard a good car analogy in a while.

Modern cars are far more efficient, performant and easier to drive than a 15 year one. Just like modern web apps are far more scalable, highly-available, secure and performant then they were 15 years ago.

Yes, we just replaced our eleven year old car with a three year old. The same make and model and our fuel bill dropped by 25%. This is nearly half the cost of the car over the period we will own it.

Re: Choose Boring Technology (2015)

#90

Post by m463 »

trestenhortz wrote: post #3

Generalizations like “choose boring technology” are just unhelpful slogans. Truth is you should choose technology given consideration of its pros and cons, not on the basis of some slogan. There are very good reasons to use mature technologies and very good reasons to use current technologies and very good reasons to use absolute cutting edge technologies. When someone comes at your approach wielding a slogan, be ske…

UH, he covered that specific point in the presentation (humorously).
Post reply on HN