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

91–100 of 137 posts

Re: Choose Boring Technology (2018)

#91

Post by re-thc »

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…

> It’s interesting that the wisdoms of “buy, don’t build” and “NiH” etc. seem to be shifting in general.

I don't know how these can ever be a "wisdom". It's often taken out of context and most people don't even understand how or where it should applied. If you blindly apply anything it's never a wisdom.

Something like "buy, don't build" earn companies $$$ and there is likely heavy influence from those trying to profit from it more than a general wisdom.

Re: Choose Boring Technology (2018)

#92

Post by sparrowInHand »

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…

There are frameworks that take outrageous amounts of time producing very little, besides opinionated staff. Basically assembly for X in disguise, demanding everyone be "educated" and up to task. Meanwhile the world moved on.

Re: Choose Boring Technology (2018)

#94

Post by a_imho »

eitland wrote: post #27
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…

> But if you make the choice of Java (boring) over Kotlin (shiny new), you’re possibly signing up for a curse of chasing NPEs You are also choosing -to let your team choose their own IDE - easy to debug - frameworks that works out of the box - and continue to work regardless of Kotlin versions (since one doesn't use Kotlin) - to no have to deal with a number of "interesting" ways to write code I like Kotlin. But it i…

Agreed, also, imo boring implies that failure modes are well understood or at least documented and have a bigger community to rely on when you eventually hit them.

Re: Choose Boring Technology (2018)

#95

Post by adamckay »

bl4ckm0r3 wrote: post #85

I hate this, as usual all blanket statements are false assumptions. The presentation is mainly focused at new paradigms but technology is there to help us fix problems, and I totally agree that jumping on a cutting edge tech is very risky in most of the cases and can end up in wasting a lot of time finding workarounds on either limitations, bugs or immaturity of the chosen tech, BUT my problem with this is "where do…

> BUT my problem with this is "where do you draw the line?"

Wherever it makes sense for you and your organisation. There's not a list of approved "boring technology" and unapproved "exciting but scary technology". It's not about the age of the technology, but your level of experience with it. If you know it inside out, understand its failure modes and can easily find information when something goes wrong it's "boring".

If your team can configure AWS services in their sleep but have never touched a bare metal box then AWS is boring. On the flip side, if you're a bunch of Linux greybeards and wrote the book on iptables but can barely spell VPC then on-prem is boring.

This is also where the concept of "innovation tokens" comes in. C++ is well established and quite far from innovative on its own, but if you're building a web app and your team is full of new graduates and interns that have only ever touched Javascript and Python then using C++ would spend one of your "innovation tokens" as your team is busy learning it instead of learning the business domain.

Re: Choose Boring Technology (2018)

#96

Post by AugustoCAS »

I do agree with a lot of the presentation. A word of caution though: some technologies that start by offering simplicity evolve over time to provide a very difficult to grok environment. So the evaluation about the cost of maintenance is not a do once and forget.

And sometimes boring means roll your own. An important aspect of this for me is to pick the simplest solution: A bit of code > A library > A Framework > Platform, which I think is in line with the presentation.

Re: Choose Boring Technology (2018)

#97

Post by nailer »

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.

Re: Choose Boring Technology (2018)

#98

Post by bl4ckm0r3 »

adamckay wrote: post #95
bl4ckm0r3 wrote: post #85

I hate this, as usual all blanket statements are false assumptions. The presentation is mainly focused at new paradigms but technology is there to help us fix problems, and I totally agree that jumping on a cutting edge tech is very risky in most of the cases and can end up in wasting a lot of time finding workarounds on either limitations, bugs or immaturity of the chosen tech, BUT my problem with this is "where do…

> BUT my problem with this is "where do you draw the line?" Wherever it makes sense for you and your organisation. There's not a list of approved "boring technology" and unapproved "exciting but scary technology". It's not about the age of the technology, but your level of experience with it. If you know it inside out, understand its failure modes and can easily find information when something goes wrong it's "boring…

100% agreed, as I mentioned in house knowledge (and engineering size) matters when deciding this. In your example, if you only have recent graduates in your team you have a whole lot of different problems :D In a more common setup (some seniors, some juniors) given they will have to learn something on the road anyway, wouldn't you want to, for example, use managed services instead of "boring" services? Use svelte instead of angular? use flask instead of django? or fastify instead of express? And if you go boring because there's more literature on them, you will soon find out that most of it is confusing as it spans over the years (have you ever used springboot? so many different ways of doing things that evolved in time...) and in the beginning you'll end up using the - by the book- approach which does bring some complex problems (try refactoring the auth module out of an app).

In the end what you are doing is moving the problem of figuring things out later in the future, when things are much more complex and refactoring is much more costly.

But I agree with you in the end it depends on the org, which is why you should not choose boring tech by default, and not choose cool tech by default either and think more about what would really give you speed of execution and maintainability in an always changing business domain AND keep things small enough that can be refactored out in an as-easy-as-possible way.

ps of course this is after like the first year of your startup, there's no point of doing any of this, or even choosing any technology if your company dies in 3 months.

pps i still don't understand why early stage startups don't do everything in javascript (FE+BE) so the same engineers can contribute to both part of the stack and then decide what to change depending on the business needs

Re: Choose Boring Technology (2018)

#99

Post by raverbashing »

strken wrote: post #66
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…

You can make bad technology choices today. For example, if you were using Typescript to build a mobile app, you might be tempted to use TypeORM (32k stars on GitHub, been around since 2016, widely used). If you wanted to also use transactions and concurrency then this would be a mistake, because you would quickly find that TypeORM's SQLite adapter doesn't have a connection pool or locking for transactions, and will h…

I think the issue here is depending on transactions/concurrency in a locally running SQLite

The fact that SQLite supports those is of course great, but maybe there are easier ways of serializing access to it.

Re: Choose Boring Technology (2018)

#100

Post by pjmlp »

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…

Rewriting in Go and Rust, with a blog post afterwards, would qualify.

Guest languages on the JVM and CLR.

Mobile apps with hybrid stuff, instead of the SDK languages.

Also using SPAs for what would be doable in PHP.

Post reply on HN