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

101–110 of 374 posts

Re: Choose Boring Technology (2015)

#101

Post by ryanbrunner »

threeseed wrote: post #30
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…

Basecamp is a simple app though. Ridiculously simple. That app could have been written in the mid-1990s using WebObjects in just a few months. Technologies like MongoDB, React, GraphQL, Microservices etc exist because modern, real-world apps are generally far more advanced than just a glorified CRUD app. Consumers simply have higher expectations and more demands for what web apps should be able to do.

While this is somewhat true and you can't solve everything with Rails + Postgres, you should ask yourself very, very hard about whether what you're building is in that category (and further, whether every part of what you're building falls into that category).

Far, far too often I think a significant source of complexity is enthusiastically added by engineers themselves assuming that the problem they're solving is sufficiently complex that boring technologies just aren't up to the requirements of their project.

My current gig is writing a very traditional Rails app (we hardly even dabble in Stimulus or Javascript all that much). Prior to that, I worked on a Javascript-backed fully reactive real-time app using the latest and greatest of technologies. My boring old Rails app, IMHO, has a much nicer user experience, far fewer quality issues, and is well loved by customers, where the bleeding edge Javascript app was constantly deried by customers for being difficult to use, buggy and unintuitive. You can go a long way with simple technologies if you design your experiences well.

Re: Choose Boring Technology (2015)

#102

Post by gaogao »

satyrnein wrote: post #88
threeseed wrote: post #36

Earlier quoted context omitted.

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 nee…

Still a 5 second SQL query with Presto or similar and a warehouse.

Re: Choose Boring Technology (2015)

#103

Post by yellowapple »

nhumrich wrote: post #84
hnedeotes wrote: post #22

Earlier quoted context omitted.

Or better, Elixir + Postgresql

Not sure elixir qualifies as "old and boring tech"

Elixir, probably not.

Erlang (and more broadly OTP), however, definitely qualifies IMO, at least depending on point of view. And given that Elixir is just an alternate language targeting OTP on Erlang's VM, there ain't much stopping folks from treating it as exactly that (and sticking with things like Yaws and Mnesia/CouchDB instead of the latest Phoenix hotness).

Re: Choose Boring Technology (2015)

#104

Post by mtrovo »

rachelbythebay wrote: post #28
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…

How about “leaves the industry rather than have to use terrible things at dumb companies”, thus giving a survival bias that selects for shiny. I know I feel that way about a lot of stuff now.

That's a fair point and I can totally relate to it. There's a toxic relationship of startups always trying to one up each other to attract more attention as a great place to work and in general tech stack is just another tool on this fight. As a consequence workers are pushed to the same mindset, where fixing a problem with 10 microservices and a dozen AWS services is the expected and if you prove you can solve the same problem with a single machine running a cronjob with no external dependencies you're the weird one.

Re: Choose Boring Technology (2015)

#105

Post by djoldman »

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…

> So they try to convince their companies their products need to be rewritten in mongodb, react with graphql in a micro service stack and many more state of the art technologies.

I find it interesting that these technologies are considered "state of the art" (SOTA). What does SOTA mean in this context? I could see an argument for postgresql and rails/django being SOTA as I think many believe them to be fairly mature, secure, and feature complete.

Re: Choose Boring Technology (2015)

#106

Post by jermaustin1 »

collyw wrote: post #99
hackerfromthefu wrote: post #79

Earlier quoted context omitted.

and where maintainability and tco matter

I think maintainability is mostly down to developer skill and the ability to abstract to the right level. A good Python dev will likely leave far more maintainable code than an average Java dev.

> A good Python dev will likely leave far more maintainable code than an average Java dev.

And a GOOD Java dev will likely leave far more maintainable code than an AVERAGE Python dev.

Re: Choose Boring Technology (2015)

#107

Post by sdfhbdf »

nickjj wrote: post #68
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…

I think it's helpful if it brings awareness to the situation. I've spoken with 70+ different devs working on 70+ different projects of all sizes on my Running in Production podcast[0] and the choose boring tech phrase came up a whole bunch of times, and especially the idea of using innovation tokens. If it helps folks build and ship their app in a quick and stable way, that seems like a big win to me. [0]: https://ru…

It must have been a weird coincidence but I listened to a few episodes for your podcast and I've actually heard about boring technology in 100% of episodes I listened to

Re: Choose Boring Technology (2015)

#109

Post by ryanbrunner »

the_gipsy wrote: post #94
CamouflagedKiwi wrote: post #37

Earlier quoted context omitted.

He covers this - the operational setup & expertise to scale Memcached already existed because Etsy already used it elsewhere. It would have had to be built and learned (mostly) separately for Redis.

I meant the part where he talks about maintenance later on.

Maintenance is also something that has to be learned (and "built up" in the sense that you're going to accumulate playbooks and processes over time).

If a team already existed that knew the ins and outs of memcached, knew how to resolve any problems it encountered, already had appropriate monitoring / alarms / etc, that's a massive leg up over needing to do all that with a completely new technology.

Re: Choose Boring Technology (2015)

#110

Post by ryanbrunner »

the_gipsy wrote: post #17

I think there's an unfairness angle to it, if someone like the CTO makes the "boring" call. He then hacks maybe a few things here and there, but the one's to "sucker up" are the devs who have to program some "boring" shitty tech every day.

I don't think this has to be true. I've worked in many places (granted, smallish teams of less than 20 or so) where tech decisions were made collectively, without even that much input from the CTO.

Choosing boring technology doesn't have to be a top down thing, although it probably needs to have some mechanism for aligning a whole team (since 10 different "boring technologies" are no longer boring and bring along all the problems of using shiny new toys).

Post reply on HN