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

Choose Boring Technology (2018)

boringtechnology.club

Post reply on HN
Print view View original

111–120 of 137 posts

Re: Choose Boring Technology (2018)

#111

Post by K0SM0S »

Dan McKinley's innovation model is solid. If you're familiar with entrepreneurial literature (eg. HBR), or financial analytics, or even the prosumer DIY scene, you'll land on the same general principles.

"Boring" is essentially a synonym for "reliable," a principle that holds true across sectors, especially in tech-adjacent fields. Nintendo's success is a case in point for the power of commoditizing reliable tech.

Google's polyglot approach (Go, Kotlin, Dart…) might seem like an exception, but it's more likely a symptom of being "too big to notice friction." This will eventually manifest as either tech debt or a talent bottleneck.

As for sectors that defy the "boring is best" mantra, they're rare. Even buzz-heavy areas like crypto and Web 3.0 often rely on tried-and-true languages like Java or Python. Domain-Specific Languages (DSLs) are the real game-changers, bridging monoliths to human-centric solutions. The only sector that genuinely benefits from "non-boring" tech is cutting-edge R&D—think languages like Julia.

Re: Choose Boring Technology (2018)

#112

Post by klabb3 »

ed_blackburn wrote: post #72

I am six months into a startup. It's a Python monolith with Postgres. It's been a success. There's a product-market fit, paying customers, and a healthy roadmap. The team picked boring tech, and it was the right call. Now, we are scaling to add exponentially more customers and hiring more people. We need to add resilience. We must tackle challenges around back pressure, flaky third parties, etc. Now is the time to in…

> It's a Python monolith

> flaky third parties

Seems contradictory. What are the third parties used for?

Re: Choose Boring Technology (2018)

#113

Post by klabb3 »

avindroth wrote: post #45
gfodor wrote: post #13

Earlier quoted context omitted.

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.

It should probably be “Default to boring tech”

Re: Choose Boring Technology (2018)

#114

Post by kyawzazaw »

hgomersall wrote: post #57
kyawzazaw wrote: post #24

Earlier quoted context omitted.

> But if you make the choice of Java (boring) over Kotlin (shiny new), you’re possibly signing up for a curse of chasing NPEs, which Kotlin would have caught at compile-time. Or if you choose C++ over Rust, same general idea. But isn't the point that if you run into this much issue for the initial choice, you are now ready to use an innovation token and switch to a different one? > Some semblance of safety needs to b…

Interestingly enough, the concern in the early stages is actually not at all about hiring people, it's about personal motivation and technology fit. We dropped C for Rust in a systems language context and technologically it was a fantastic choice. I guess some of the benefits of a language switch could have been realised with C++, but since my proficiency with C++ was a few small incremental changes relative to C, I…

> Interestingly enough, the concern in the early stages is actually not at all about hiring people, it's about personal motivation and technology fit.

Is this in regards to running a startup? In that case, I have little to add. But my initial understanding would be, the startup needs to be able to reach product market-fit as quickly as possible. Which is where using a boring technology (to the founders/founding team) would reduce distractions/unknowns.

> but since my proficiency with C++ was a few small incremental changes relative to C, I was going to have to learn a lot in either case.

Isn't this premise aligned with the philosophy written in the article? 1. You needed to learn something new (so no longer boring, and prime for innovation token) 2. You needed to use something different for a systems language context (innovation token time)

Re: Choose Boring Technology (2018)

#115

Post by kyawzazaw »

jpgvm wrote: post #48
mikece wrote: 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 yo…

But is there an easy good alternative to Datadog?

Re: Choose Boring Technology (2018)

#116

Post by appplication »

eddmakesio wrote: post #104
mikece wrote: 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…

> todays tech landscape is far less edgy Writing an app in a microservice architecture with services in Rust, Go, and Nim. Database is a serverless DB like Planetscale. Front end in HTMX. Etc… I think any tech your team is not already familiar with, and isn’t the standard pick, is an innovation token.

So I agree 100% with this, but postgres is so easy and scales infinitely (for the meaning of infinite in 99% of business use cases), I suppose I don’t understand why I would choose MySQL. Do folks just use it as a user cache? Most systems I’ve designed of worked on have required a central database so MySQL never seemed the right fit.

Re: Choose Boring Technology (2018)

#117

Post by kyawzazaw »

chadcmulligan wrote: post #42
freelanceTA wrote: post #12

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…

resume driven development

Re: Choose Boring Technology (2018)

#118

Post by simonw »

threeseed wrote: post #53
simonw wrote: post #43

Earlier quoted context omitted.

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.

> but there are thousands of production PostgreSQL instances out there have solved them Great. Can you provide the details on exactly how they did that. Ensuring of course that it doesn't rely on anything proprietary e.g. Citus. Because with every other database I can just go to the officially supported and maintained documentation.

OK, you've attracted my interest. What are some examples of official database documentation pages that do a great job of covering these advanced deployment topics?

It's important to note that "boring technology" doesn't mean the official documentation will answer all of your questions: it means that there is enough experience out there in the user community that you can find the information if you go looking for it.

Re: Choose Boring Technology (2018)

#119

Post by JambalayaJim »

crabbone wrote: post #105
fnfjfk wrote: 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…

Concentrating on NPEs and stuff like sum times is misunderstanding the problems with software quality to the point of misunderstanding the magnitude of impact of different flaws. Working tightly with QA for over ten years by now, I can assure you that NPEs are exceptionally rare in bug reports filed by QA. No matter if that's a common problem in the language the application is written in (eg. Java or C++) or virtuall…

NPE safety and sum times deal with issues that developers face on the day to day, long before the product ever gets used by end users in the first place.

NPE issues are also very very difficult to chase down.

Re: Choose Boring Technology (2018)

#120

Post by hnreport »

nailer wrote: post #97
mikece wrote: 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…

> I'm not even sure what tech is out there that would qualify as "spending your innovation tokens" other than AI. Spending a few hundred K on Unnecessary Kubernetes (and the surprises that result) is definitely still a popular thing amongst junior/mid devops people.

Gotta let the kids pop their cherry on something.
Post reply on HN