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

Choose Boring Technology

boringtechnology.club

Post reply on HN
Print view View original

91–100 of 356 posts

Re: Choose Boring Technology

#91

Post by jerf »

lvh wrote: post #69

Author mentions Clojure a few times as an example of shiny-thing. Ironically, it's one of the few languages that I can reliably do in the browser, on the backend (on real servers or say, Lambdas), and build native binaries for -- which addresses the later "many tools" problem better than a "boring" programming language like Ruby. Unless you don't care about frontend code I guess :-) (Overall this talk is fine! I thin…

Generally, "shiny-things" have some sort of appeal over the "boring" technology, or nobody would choose them at all.

One of the places I'd say they are appropriate are in places where you have some problem where some "shiny-thing" stands head and shoulders above the "boring technology" in some particular and you can ram home those advantages well enough to overcome the other issues. For instance, if you've got a server where you're going to have several thousand clients opening a socket connection and babbling away at each other in some custom manner, starting with Erlang/Elixir is quite possibly a very good idea, because none of the "boring" tech is anywhere near as good at that, even today.

But I do agree that when doing the cost/benefit analyses of these choices, far too many developers plop an unprofessional amount of weight on the "benefit" side that amounts to "it's fun to play with the pretty-shiny". (I'm still recovering from some old "NoSQL" decisions made in a context where a relational database would have been more than adequate, at most backed by something that even at the time was tested like memcached, instead of a combination of what are now completely defunct and semi-defunct databases.)

Re: Choose Boring Technology

#92

Post by lvh »

sydd wrote: post #84
lvh wrote: post #69

Author mentions Clojure a few times as an example of shiny-thing. Ironically, it's one of the few languages that I can reliably do in the browser, on the backend (on real servers or say, Lambdas), and build native binaries for -- which addresses the later "many tools" problem better than a "boring" programming language like Ruby. Unless you don't care about frontend code I guess :-) (Overall this talk is fine! I thin…

But: - good luck finding a Clojure programmer if your current one quits. - good luck finding answers for your exotic bug/performance issue etc. Code is a liability, it's much more than language/VM/compiler features

I've ran multiple org that are largely or almost exclusively working in Clojure(Script) and trained over a dozen folks to be proficient Clojure programmers, and have not found that any of those to be a problem. For example: you mentioned debugging serious performance problems, but the JVM has some of the most advanced instrumentation on any platform.

This is actually a point subtly made in the talk: your real production problems are probably going to be a lot more subtle than "oh, it's Python's fault". It's "this table ends up getting VACUUMd a lot and a minor version change made the disk size required 3% bigger and that combined with natural growth and a logging bug suddenly caused a catastrophic failure meaning everything started swapping". Yes, one point is what tool you use (a shiny new graph database is likely to be fundamentally less operationally mature than Postgres) but more important is your collective expertise in your toolbox, because a production P0 incident is a bad time to learn what autovacuum_naptime is.

For example: those fancy performance debuggers probably don't work on your Lambda runtime. I don't see that as a Clojure problem, because you would've had the same thing if you wrote it in Java+Dropwizard or Flask+Python or Go (which are presumably in the boring category).

Is the flip side of that argument that you should only write things in PHP, because that is what the market has decided where programmers are the most fungible?

Re: Choose Boring Technology

#93

Post by liveoneggs »

I proudly used "boring" to describe a massive simplification of my work's architecture that I have been working on for the last few years. It has been a successful culling of tech down to the bare minimum (as always- still a work in progress).

Anyway my boss got so so offended and angry that I would use the word "boring". I spent the rest of the day trying to explain it and calm him down.

Anyway use caution with the word "boring". It's more toxic than nuance would suggest.

Re: Choose Boring Technology

#94

Post by jasode »

merb wrote: post #85
jasode wrote: post #17

As a meta observation, I noticed this was submitted by user luu and his website also has a blog post with a similar theme ("boring languages"[1]). Therefore, I wonder if the "boring vs exciting" advice somewhat depends on the personality. I.e. if person has a tendency to prefer conservative technology, it means external advice that advocates "boring tech" will resonate with that person. I think choosing boring techno…

> From what I read, Google's first AdWords server in 2000 was built on MySQL. MySQL was released in 1995 so using a relatively new 5-year old technology may have been more risky than picking traditional Oracle RDBMS which had been around since the late 1970s. well they could've also used postgres/ingress. but at the time it was way less used than mysql and way more conservative. mysql was probably used because in the…

An ex-googler mentioned somewhere else that Oracle was the "real commercial db" in this story about the early AdWords server:

https://web.archive.org/web/20120305152003/http://eldapo.blo...

Re: Choose Boring Technology

#95

Post by falcolas »

malvosenior wrote: post #83
liveoneggs wrote: post #74

Earlier quoted context omitted.

> Ruby/Python are interpreted scripting languages This is not quite right since they both compile to bytecode and execute in a virtual machine shell scripting is, probably, the very rare example of "interpreted"

Python can be compiled to bytecode, but that's not the default or standard.

It occurs with every execution, if you don’t pre-compile it. That’s what the .pyc files are. It also does it with the “main” file, but it just keeps that in memory instead of writing it to disk.

Re: Choose Boring Technology

#96

Post by hyperman1 »

TheOtherHobbes wrote: post #63
Crinus wrote: post #47

Earlier quoted context omitted.

> For example, in 1974 when the new Altair 8800 made the cover of Popular Electronics[2], an excited Paul Allen showed the magazine to a 19-year old Bill Gates. The "boring tech" advocates would tell them they're wasting their time with the "new fad of microcomputers" and they should look at boring IBM 360 mainframes instead. I remember reading a book around the late 90s (the book was written in the early 90s) about…

That's a false analogy, because the micro was a category changer. It was literally the basis of entire new markets. A lot of people saw that coming. A lot of other people - like DEC and DG - didn't. IBM mostly didn't, but was lucky enough to have a small division that did in spite of the culture around it. (And they lost it. Too bad.) Node, Mongo, Clojure, etc were never category changers - they were solutions made b…

There is a benefit of hindsight here: The micro, in the beginning, was a bit like 3d pronters now. Nice toy for enthousiasts but that's it. It took the GUI, wordprocessor and spreadsheet to get them out of the toy category and in the usefull category.

Mainframes etc could also deliver this, the main differentiator being price. IBM was dreaming of a mainframe for each city, and phonelike terminald in the company. Minitel and internet proves the vision was right, only the price wasnt

The category killer needed to be cheap as well ad usefull.

Node also has an obvious benefit: same tech in frontend and backend, hence less devs needed. A.k.a. cheap, at least it seems so in the short term. History will judge us both on the long term, I guess.

Re: Choose Boring Technology

#97

Post by falcolas »

malvosenior wrote: post #78
nickjj wrote: post #54

Earlier quoted context omitted.

> It's weird to see people comparing Go and Python in this thread as they solve entirely different problems and shouldn't be interchangeable, not due to developer preference but due to fundamental features of the language. Yes but when Go first came out, a lot of people jumped on the bandwagon and started proposing they would use Go for web applications too. There's definitely some overlap in building web services wi…

> Go and Python are also pretty related for command line apps too. You could totally use either one to build a CLI tool. Distribution of Go CLI apps is much easier as you don't need to have your end users install the 3rd party libraries themselves.

Given the broad capabilities of the Python first party libraries, you can do a lot of work without 3rd party libraries. It’s not in as much fashion as it was 10+ years ago, but it’s still quite doable.

Re: Choose Boring Technology

#98

Post by parasubvert »

A huge part of our VC bubble in OSS infrastructure (NoSQL, clouds, middleware, automation) is fueled by a generation of technologists not choosing boring technology.

This is a great presentation, and great advice.

What this piece misses are the marketing, hiring practices and incentives in that capital pool that is fueling FOMO (fear of missing out) as the main driver of our technology trends.

Most people orbiting IT wants to be a part of something that changes the world: it’s their ticket to higher paying job elsewhere, bragging rights at a conference, internet fame/notoriety via blog posts, etc. This is how we wind up with Service Mesh proxied MongoDB on Kubernetes as THE ANSWER, and all the ensuing political battles / turf wars to fight boring alternatives as “yesterday’s news”.

It would be nice to see a greater focus on business outcomes, but I find few have the patience or bandwidth to truly track the success of a technology choice, unless you’re a larger company making a periodic cash bet with a business partner (eg software vendor). And even then, failure can be swept under the rug sometimes.

It requires strong leadership and management (or a great culture) to encourage your teams to communicate tradeoffs and make these sorts of “boring tech” decisions without it being more about individuals playing a turf game.

Re: Choose Boring Technology

#99

Post by uhhhhhhh »

crispyambulance wrote: post #37
dm3 wrote: post #3

Another case of someone discovering, after 10+ years in tech, that code is a liability and you're supposed to solve problems instead of chasing trends and padding the resume. Great that he's spreading the word!

Code is not "a liability". It is a tool that can be used masterfully or utterly abused. Every craftsman has to invest in their tools. And for someone to truly master their craft they must sometimes hone their tool skills speculatively, without short-term gain, and by sacrificing the time and attention used for other things, like actual projects. If everyone just obeyed their project manager and always focused 100% on…

Coding is a tool.

Code is the result of that tool. If you use a tool to build something you're constantly repairing/maintaining, then its a liability.

Re: Choose Boring Technology

#100

Post by shapiro92 »

Such strongly opinionated statements should be taken with caution. In our profession context is key and this theory does not always apply in every context.

Imagine if the Netflix guys were told to stay boring and not invent new shiny things? Ofcourse not everyone is in that scale.

I do not want to use the latest shiny tech but I do not want it to be boring as well. We are confusing KISS and boring here. A company I used to work at was running a job server at 90% utilization all the time and it even worked as a jump box, this is simple and boring but its also plain stupid. Invest some time and make it proper.

Maybe when I am 50 years old I will want a boring setup, but until then no. I want to be engaged and active in what I do.

Post reply on HN