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

101–110 of 137 posts

Re: Choose Boring Technology (2018)

#101

Post by threeseed »

lelanthran wrote: post #87
threeseed wrote: post #34

Earlier quoted context omitted.

The first approach will be significantly cheaper if using the cloud. It allows you to use spot/ephemeral instances and scale down capacity to almost zero cost without any loss in availability. Single server in the cloud is great for dev environments and if you don't care about uptime. But given that poor uptime is toxic for customer retention only incompetent businesses would deliberately not choose to use something…

> The first approach will be significantly cheaper if using the cloud. Only if you're regularly scaling down to zero (AKA too few paying customers to stay in business). > only incompetent businesses would deliberately not choose to use something better suited. There's a time and place for both approaches. If you're serving anywhere near the number of users needed to show a profit, spot instances are extremely expensi…

Ignoring managed services:

Spot instances are the cheapest types of instances you can get.

Auto-scaling the smallest compute instances for your use case is the most efficient architecture you can get.

It doesn't matter what time or place it is. These are facts that you can check for yourself on AWS/GCP etc cost calculators.

Re: Choose Boring Technology (2018)

#102

Post by hobs »

dgb23 wrote: post #74
jpgvm wrote: post #48

Earlier quoted context omitted.

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…

It’s interesting that the wisdoms of “buy, don’t build” and “NiH” etc. seem to be shifting in general. I think a lot of people have been realizing through the pain of maintenance that dependencies are liabilities and that general, open source solutions with a bit of plumbing are often the lesser evil in that regard. Given my anecdotal experience it seems to be true in the small, and I can imagine how this problem is…

And then it will slowly come back to "my home grown solutions don't scale and I pay too many people to maintain all my infra, there's gotta be a better way!"

Or more simply, the urge to centralize and then decentralize has been repeated many times already in the computer industry, sometimes they are legitimate reasons, but often its grass is greener type of thinking which rules many engineering cultures.

Re: Choose Boring Technology (2018)

#103

Post by crabbone »

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…

Well, here's a problem with your approach.

Say you are a startup in storage niche. Well, big companies aren't going to try using you because you need to have like 10+ years of proven work record before they even consider trying. So, you find yourself in a catch 22 situation.

What you can do is find another startup who'd agree to use your product. Maybe fore cheap. Maybe for sharing some resources with them, like marketing or engineering expertise in some area. And that's the only way to get any "mileage".

Maybe you could bribe your way in, or maybe you could be "lucky" to personally know someone important in a big company, which will allow you to gather that mileage without cooperating with other startups... but if you are a nobody, not only won't you be able to get an interview with a relevant exec, you won't be even able to contact that exec to ask for an interview. These people treat their interviews as a hugely valuable service which they aren't willing to provide to the plebs.

Re: Choose Boring Technology (2018)

#104

Post by eddmakesio »

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.

Re: Choose Boring Technology (2018)

#105

Post by crabbone »

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 virtually nonexistent (eg. Kotlin or Haskell).

Here are some examples of more common bugs:

* Misunderstanding of the desired functionality (eg. giving admin permissions to regular users).

* Not being able to predict all valid input forms (eg. user names with accented characters).

* Forgetting to handle errors coming from multiple levels below the immediate level that's being worked with (eg. dealing with SSL-related problems in HTTP client / server communication).

* Simply forgetting to implement some uncommon bit of functionality (usually related to cleanups, deletion etc.)

----

Currently in-use programming languages have roughly the same ability to deal with these, as I call them, "macro-problems" of programs. All of them are equally ill-equipped and unprepared for them. Tightening the type system or chasing after nulls is working at a resolution that's too fine. At this resolution programmers usually still have a good chance of figuring out the problems without the aid of types or similar automation.

Re: Choose Boring Technology (2018)

#107

Post by K0SM0S »

LAC-Tech wrote: post #19

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…

"Boring" is subjective, and even objectively defined it can't be measured. Therefore yes IMHO, F# qualifies as 'boring' for you.

However, unless you're an isolated entity (e.g., SOHO) or fully remote, your business environment also factors into that equation. Node.js might be 'boring' in the USA but anecdotal (read: edgy) in entire subcontinents.

Economically speaking, a 'boring' tech stack is one that generates the least 'friction' for its devs. (friction may be construed as added cost beyond base material requirements, eg. time or complexity added by bureaucracy, or cognitive toll induced by steep-n-quirky learning curves, as opposed to the fastest road to MVP / RC / shipping).

Re: Choose Boring Technology (2018)

#108

Post by cpursley »

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…

The problems you describe are what Elixir solves out of the box simply by being based on Erlang, including caching and pushing real-time data to dashboards. It’s also easy to learn coming from Python and Ruby.

Re: Choose Boring Technology (2018)

#109

Post by dukeyukey »

jpgvm wrote: post #49
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…

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.

Definitely. The only real downside to going with Kotlin nowadays is hiring developers; it's reasonably easy to find Java developers who want to try Kotlin, but hard to hire people experienced in Kotlin.

Re: Choose Boring Technology (2018)

#110

Post by dukeyukey »

jpgvm wrote: post #51
joshuahutt wrote: post #44

Earlier quoted context omitted.

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.

This is almost never a bad thing. It means you have fewer people to compete with when advertising a position and the people that use a niche technology generally have more passion for their craft.

Although it also delays hiring - I work for a startup using Kotlin, and we've had maybe three candidates _ever_ who have used Kotlin beyond hobby projects. And I was one of them!
Post reply on HN