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

61–70 of 356 posts

Re: Choose Boring Technology

#61

Post by undreren »

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…

Code absolutely is a liability. It is not a tool, it's a means to an end.

A simple tool, like a hammer, is not volatile over time. The house that you build with your tools is. It will weaken and rot, and given enough time it will crumble. It takes care and maintenance to keep it safe to live in.

It is the same with code in production; at some point in time in the future, through no fault of your own, the code can become "wrong" as reality changes around it.

Code is also costly to maintain, sometimes even for small code bases. As the world changes, so must the code.

One of the definitions of "liability" in the Merriam-Webster dictionary [0] is "a feature of someone or something that creates difficulty for achieving success". This definition is often met by code.

[0] - https://www.merriam-webster.com/thesaurus/liability

Re: Choose Boring Technology

#62

Post by DougBTX »

malvosenior wrote: post #46
nickjj wrote: post #41

Earlier quoted context omitted.

For me, change happens when I see a real improvement in almost every way possible which is usually determined by building a few things and letting my brain simmer on the technology as a whole so I can look at it with a logical and unbiased perspective. I remember looking at Node when it first came out and got mildly excited, but that excitement quickly went away after writing a couple of small apps with it. It just w…

Go is a compiled language and Ruby/Python are interpreted scripting languages. There are domains where it's a much more appropriate choice (distributing binaries, performance sensitive code). The type system is also quite nice vs. dynamic typing (in most situations). 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 d…

> fundamental features of the language

The thing is you’re right, Go compiling to a self-contained binary is different from a folder of .py scripts.

But both can be deployed into production.

The deployment steps are different but the outcome is the same, so they can be used interchangeably.

Re: Choose Boring Technology

#63

Post by TheOtherHobbes »

Crinus wrote: post #47
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…

> 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 by people who like to tinker for other people to tinker with. For the sake of tinkering. Hyped into orbit with industrial quantities of hypeology.

If you're trying to Get Shit Done, they're mostly a disaster. (Clojure less than the others - but it's still not solving the problems that actually matter in a production context. Not really.)

Bottom line is micros had an obvious business benefit - low cost, ease of installation, cheap software - that was never going to be matched by the mini and mainframe markets.

Node etc don't have an obvious business benefit at all. They appeal to a certain set of developers. But for most applications they don't cut development time, minimise bugs, simplify maintenance and bug fixes, de-complexify system architecture, simplify new hire onboarding, streamline the development process, scale with minimum effort, or any of those other boring requirements that actually matter when you want to get good working software out the door.

Re: Choose Boring Technology

#65

Post by jasode »

Erlich_Bachman wrote: post #43
crispyambulance wrote: post #37

Earlier quoted context omitted.

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…

In the real world with limited resources, limited skills, limited budgets and limited brain power, yes code is a liability. Not only a liability, but a liability among other things.

>In the real world with limited resources, limited skills, limited budgets and limited brain power, yes code is a liability.

That's an unbalanced conclusion. Code can be a liability but it can also be an asset.

Do we have limited resources? Maybe writing new code can help. E.g. In cars, the electronic fuel injectors have computer code determining the optimal amount of gas to inject to minimize fuel usage. Fuel efficiency is improved over older "non-computer-code" carburetors. Computer code is an asset that's equivalent to discovering new proven oil reserves.

How about the limited resource of bandwidth on networks? Code and algorithms like h.264/h.265 that shrinks video enough to make it practical to stream to homes maximizes the existing network without having to lay a bunch of new fiber optic cables to every house.

And consider all these YC companies that aren't worth much today. How do they become more valuable? They need to write more code. New features that customers find valuable requires coding. Even if the startup's code does not have patents, it will still be part of the tech portfolio assets that the acquiring company will include in the purchase.

The "code is a liability" seems to be true if one limits their focus to negative situations like npm leftpad and the Boeing MCAS accidents. In contrast, I don't think the astronauts thought the Apollo Guidance Computer was a liability if it helps them get to the moon.

Re: Choose Boring Technology

#66

Post by tracker1 »

I'm not sure I agree with some of the examples... For instance, since Redis can replace Memcached in addition to other chores, what would it have taken for a migration strategy to eliminate an older tech in favor of the newer one?

In the end, I understand how each tech adds costs and values... however, one shouldn't be afraid to update/change things. It's too easy to be stuck on a decade and a half old tech if you are and don't at least try to keep up a little. Then the upgrade is exponentially more costly.

Re: Choose Boring Technology

#67

Post by stinos »

oftenwrong wrote: post #58

Always glad to see this making the rounds, as it has been influential for me, especially the perspective of "Happiness comes from shipping stuff". I often think about this part, in particular: >Then we walked away. We didn’t do anything related to activity feeds for years after that. We barely even thought about it. >Then one day I said, “hey, I wonder how activity feeds is doing.” And I looked at it and was surprise…

For me, implementing something that provides value with near-zero maintenance for years is the ultimate sign that I've done well.

Such a good point it's worth repeating. We have a bunch of small tools of which the code might not exactly be brilliant or adhering all possible good practices, but after 10+ years they still just work without any unsurprising behavior nor bugs and still also just build/deploy with a click of the button so to speak. That's just nice.

Does make me wonder sometimes what exactly all other knowledge I gathered since then is good for. Some of it is definitely wasted on shiny stuff. But most of it is software architecture and with repect to the subject I'd translate that as 'how do I make this large scale application a combination of all those small and nice tools, and make that combination itself also work as those small nice tools'.

Re: Choose Boring Technology

#68

Post by mu1313 »

tracker1 wrote: post #66

I'm not sure I agree with some of the examples... For instance, since Redis can replace Memcached in addition to other chores, what would it have taken for a migration strategy to eliminate an older tech in favor of the newer one? In the end, I understand how each tech adds costs and values... however, one shouldn't be afraid to update/change things. It's too easy to be stuck on a decade and a half old tech if you ar…

I don’t think the point is not to migrate. The point is to discuss and make the decisions globally not at the whim of “this makes me happy” or “we have a new problem”.

Re: Choose Boring Technology

#69

Post by lvh »

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 think the problem/technology set illustration is particularly useful. I run Latacora's Cloud practice and we own all production infrastructure and "no, more boring, boringer than that, keep going" is a good way to describe what that looks like. We deploy half a dozen projects with exactly the same zero config storage and in ECS Fargate because I'm not managing servers.)

Re: Choose Boring Technology

#70

Post by trm42 »

sametmax wrote: post #44
openfuture wrote: post #9

Earlier quoted context omitted.

You never change, at some point a competitor arises that chose different technology and it kills you.

Competitors don't kill you because they chose a new tech. They kill you because they can either: - solve a new problem - solve an existing problem better - solve an existing problem cheaper A new tech MAY allow that, and it MAY be used successfully toward that objective, but even in that case, that's hardly the core of it for most cases. Not saying it does not happen, but there are much more at play.

In my experience this all boils to the fact that usually it's not the actual chosen technology stack but the missing craftmanship when making the stuff first time.

Then you either end up refactoring the whole setup for years (which usually is expensive, slows down the business development velocity) or rewriting it from scratch (or as a new implementation next to the old one).

If the original implementation would've been sanely made. Then making new features on top of it (or partial replacements or micro-services etc) wouldn't be that big issue. But usually these beasts are more like godzilla-level monoliths with bad architecture etc so it's probably easier to rewrite the whole thing.

Post reply on HN