Live data from Hacker News

Choose Boring Technology (2018)

boringtechnology.club

41–50 of 137 posts

Re: Choose Boring Technology (2018)

#42

I want to choose tech that has the least amount of maintenance. For example I had to build a web app thing for something I'm doing. The many frameworks available are of course trivial to string together but now I'm looking at a huge amount of dependencies all that require a lot of maintenance. I went with avoiding all but the the most critical libraries for authentication but is there a better way? I found even writi…

I prefer jQuery and jQueryUI - actually I go one further and use the devextreme components so I have paid support (outrageous I know) for spa's or something like umbraco for CMS but they are very unsexy and old. Delphi for cross platform applications, but try and sell that as a development platform :-D

I think the big advantage of this sort of stuff is you have a million debugged and working examples to pick from and people who know them inside out.

Edit: I watch the kids trying to figure out how to release things on docker with their multiple git branches and merges, and re-engineering their microservices frameworks, and each time I die a bit inside. This was all done so long ago, why continue to make it harder. Now I'm not talking something google scale, but something with a few hundred users and maybe 20 concurrent, why would you do this, sigh.

Re: Choose Boring Technology (2018)

#43
post #30

Earlier quoted context omitted.

PostgreSQL is absolutely boring technology. What makes it boring is: - people have been using it for decades, for all kinds of different things - this means that any problem you run into, someone else will have seen before - and will have talked about it online - you're not going to be using it to solve a class of problems that no one else has used it for before

There are many aspects of PostgreSQL which are not solved problems e.g. clustering, replication, high-availability. And will remain unsolved whilst they are not part of the core products. Because everyone comes up with different solutions which change over time. Citus Data which people often recommended didn't exist prior to 2010 and may not exist next year now they've been acquired by Microsoft and conflict with the…

Clustering, replication and high availability may not be easy, but there are thousands of production PostgreSQL instances out there have solved them. That's what makes it boring.

Compare solving those problems to solving them with a brand new database engine where you might be one of the first organizations to run at that scale.

Re: Choose Boring Technology (2018)

#44

I feel like this has been misunderstood for years. I note this paragraph: But what I’m aiming for there is not technology that’s “boring” the way CSPAN is boring. I mean that it’s boring in the sense that it’s well understood. It’s bad, but you know why it’s bad. You can list all of the main ways it will let you down. I understand F# more than I understand PHP. By the articles definition, F# is 'boring', and choosing…

Another thing to keep in mind is the size of the candidate pool. There's a lot fewer F# devs than PHP. Can make hiring a bit trickier.

Re: Choose Boring Technology (2018)

#45
post #13

edit: Apparently "choose boring technology" is just clickbait, and in fact the guy advocates for all the nuanced technology selection advocated here.... so errr, apparently he in fact is saying "don't chose boring technology" or something, whatever. I completely disagree with almost any blanket philosophy on technology. Don't choose boring technology. Choose technology that suits the context: * choose what you like f…

It turns out that it’s impossible to reasonably title any talk or article without it being considered a blanket statement. This is why you attach the talk or article to the hyperlink so people can continue understanding more of what you are saying.

Well, this is just clickbait. Choose boring technology means sth pretty concrete for someone without context. It’s not that you can’t reasonably title it. It’s that you can’t reasonably title it to generate views.

I understand the sentiment, but then one should expect criticism of the schism between title and content.

Re: Choose Boring Technology (2018)

#46

I want to choose tech that has the least amount of maintenance. For example I had to build a web app thing for something I'm doing. The many frameworks available are of course trivial to string together but now I'm looking at a huge amount of dependencies all that require a lot of maintenance. I went with avoiding all but the the most critical libraries for authentication but is there a better way? I found even writi…

i found the key in reducing maintenance overhead is to avoid complex build tools that claim to manage your dependencies and use frameworks that don't frequently break compatibility.

Re: Choose Boring Technology (2018)

#47

I feel like this has been misunderstood for years. I note this paragraph: But what I’m aiming for there is not technology that’s “boring” the way CSPAN is boring. I mean that it’s boring in the sense that it’s well understood. It’s bad, but you know why it’s bad. You can list all of the main ways it will let you down. I understand F# more than I understand PHP. By the articles definition, F# is 'boring', and choosing…

Another thing to keep in mind is the size of the candidate pool. There's a lot fewer F# devs than PHP. Can make hiring a bit trickier.

And I was under the impression that coders were thought of as replaceable cogs in a machine, one just as good as the next.

Re: Choose Boring Technology (2018)

#48
post #11

The points often lost here is that (1) this advice is aimed at startups, and (2) the whole concept of "innovation tokens." Any successful business is going to solve some problem which is probably not so obvious and that takes innovative thinking. If you're spending too much time trying to be innovative with your tech stack then you're NOT innovating on your specific difference as a business, and that hold you back (o…

Biggest time wasters and innovation token consumers IMO is third-party vendors, especially shiny startups/products.

Don't waste your time, money and energy being someone else's guinea pig, you need to be focused on your business problems. Bigger companies that have engineers and resources to waste can try these out for you and eventually that startup you knew a few years ago will either be successful and ready for you to use or dead and you will be glad you didn't waste the effort.

Same goes for propropertary cloud services that have no business being proprietary. Biggest culprits here are data silo-ing lock-ins like DataDog, avoid like the plague. Use the standard off the shelf tools for everything you can, OSS may require slightly higher upfront integration costs in some cases, less than you think though, sometimes it's substantially faster due to integrations.

Generally speaking if a project has been around long enough folks have already encountered every problem and shared every solution. If you are stuck with some proprietary vendor for some important part of your stack and you are hitting an edge condition you had better hope you are a big enough fish for them to care (hint: You aren't).

I guess at the end of the day keep yourself off the Kool-Aid, ignore marketing speak and always ask hard questions of things and you will avoid innovation token sinks.

Re: Choose Boring Technology (2018)

#49
post #17

This article gets posted a lot, but I find it a little unsatisfying. I think it’s because it’s pretty vague about what “boring” means exactly, so it’s the kind of statement most can agree with, without it actually being a very strong statement. It’s not wrong per se, don’t choose some technology posted for the first time yesterday. But if you make the choice of Java (boring) over Kotlin (shiny new), you’re possibly s…

Eh, I would argue Kotlin is solidly boring right alongside Java now. It's still "mostly" Java if you are using it in the same places you can use Java.

I'm with you generally though. Yes choose boring tools, JVM, PostgreSQL, etc. But also write boring code using boring architectures deployed on boring platforms.

Post reply on HN