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

Choose Boring Technology (2015)

boringtechnology.club

Post reply on HN
Print view View original

131–140 of 374 posts

Re: Choose Boring Technology (2015)

#131

Post by cutler »

atoav wrote: post #56
methyl wrote: post #51

How do we make progress if everyone just chooses to use boring technology which is already established? There would be no Rust, no Ruby or other great pieces of technology as they cannot thrive without communities. Communities cannot thrive if everyone neglects everything that’s new and exciting.

I guess it goes like this: Is there much at stake? Choose a boring technology. Is it a experiment or a toy project? Choose whatever floats your boat, knock yourself out, have fun and learn on the way. Trying out new things makes a ton of sense. But trying them out in a domain where unforeseen consequences could potentially destroy you is not a smart move.

Since most commercial projects have much at stake how would new technologies ever get a chance to become mainstream? For this to happen there has to be some risk-taking otherwise we'll be permanently stuck in the current situation where a bunch of scripting languages designed in the mid-90s for single processors are tasked with handling much bigger workloads on multi-core machines. Hence the current wave of bolted-on gradual typing.

Re: Choose Boring Technology (2015)

#132

Post by datavirtue »

the_gipsy wrote: post #17

I think there's an unfairness angle to it, if someone like the CTO makes the "boring" call. He then hacks maybe a few things here and there, but the one's to "sucker up" are the devs who have to program some "boring" shitty tech every day.

Dude, you can go home and play with any toy you want.

Re: Choose Boring Technology (2015)

#133

Post by ChrisMarshallNY »

cutler wrote: post #119
ChrisMarshallNY wrote: post #60

Earlier quoted context omitted.

I don’t do “boring,” as much as I do “mature and robust.” I like shipping products, as opposed to just “writing” them, and shipping is boring. Lots of annoying intricacies and processes. I’m writing a fairly large-scale app, right now. It’s written in Swift (frontend), using IB (classic UIKit), and PHP/MySQL/Postgres (backend). It does not use SwiftUI (shiny), or Rust (shiny, but a bit more dusty), or some form of No…

Isn't all this planning for future redundancy what the article is arguing against?

I don't look at it that way. I have a very "wishy-washy" design approach. I call it "paving the bare spots"[0]. It's definitely not a "classic" approach, and it would not be something that I would recommend to anyone that is not extremely experienced.

The idea is that I am not actually aware of what the final product will look like, when I start, so I take a very careful approach. I spent 27 years, working for a "Waterfall-based" corporation, where the system had to be 100% designed up front, and the end result would "meet spec," while still sucking. I am not particularly thrilled with many agile approaches, either, as I see many of the same problems. It's really just shifting the tech debt around.

My approach actually results in my having to throw away a lot of really good, tested, code, but I still end up moving lightning fast, and coming out with good results. If you look at my portfolio, you will see a whole bunch of small, heavily-tested module projects. Many of these were things that I ripped out of other projects, but didn't want to throw away. Some of them are crazy useful, like the Persistent Prefs Utility[1], or the Generic Swift Toolbox utilities[2], which show up in most of my work. The fact that they are treated as independent projects, with heavy testing, means that I can reuse them with confidence.

The Spinner project[3] was an example of a UI I designed to be a central aspect of an app, then decided not to use it, as it deviated too much from the user workflow I had in mind. It will be back, but not until it's the best approach. Eye candy is nice, but it still needs to be usable.

That modular approach is not new at all. I think I may have been doing it since the early nineties.

True, there is flexibility, but that flexibility is implemented as a single-point hinge, not a bendable continuum. It's very clear where the flexibility goes, and that point is well-tested. I just got done refactoring the server, where I added a more flexible way of allowing users to implement security postures, and I'm really, really glad that I did things the way that I did. It was a pretty big job, adding personal tokens (the new functionality), but a lot of the work was making sure that I stuck with the "philosophical" domains of each layer, and testing the living bejeezus out of the code.

And each point of flexibility has a very clear domain. For example, the ANDISIOL layer is where the SQL turns into functions. You can rip out everything below that, and replace it with whatever you like, as long as the same functional API is presented to BASALT. That's a fairly classic pattern.

[0] https://littlegreenviper.com/miscellany/the-road-most-travel...

[1] https://riftvalleysoftware.com/work/open-source-projects/#RV...

[2] https://riftvalleysoftware.com/work/open-source-projects/#to...

[3] https://riftvalleysoftware.com/work/open-source-projects/#RV...

Re: Choose Boring Technology (2015)

#134

Post by _qulr »

ChrisMarshallNY wrote: post #60
phendrenad2 wrote: post #2

I always found it funny that companies will go to extreme Herculean lengths to hire the best programmers, and are incredibly fearful and paranoid that they could be making a "bad hire", and yet once hired they don't spend a second making sure engineers aren't completely running the software product off the rails and killing the company internally. The author mentions trying to rewrite Etsy's backend in Scala and Mong…

I don’t do “boring,” as much as I do “mature and robust.” I like shipping products, as opposed to just “writing” them, and shipping is boring. Lots of annoying intricacies and processes. I’m writing a fairly large-scale app, right now. It’s written in Swift (frontend), using IB (classic UIKit), and PHP/MySQL/Postgres (backend). It does not use SwiftUI (shiny), or Rust (shiny, but a bit more dusty), or some form of No…

> I don’t do “boring,” as much as I do “mature and robust.”

> I’ve been writing in Swift since the day it was announced

May I ask how you consider these to be compatible?

Re: Choose Boring Technology (2015)

#135

Post by whimsicalism »

collyw wrote: post #97
js4ever wrote: post #34

Earlier quoted context omitted.

What's wrong with Node.js? It's super mainstream now. We have it in production since years, I see a LOT of companies migrating from everything else to node since years and it's a growing trend from what I see at my level with startups and even enterprises

The language for one. There are decent choices of language for backend work. Why anyone would choose JavaScript is beyond me.

Oh, but Python is an ideal backend language?

Give me a break.

Re: Choose Boring Technology (2015)

#136

Post by whimsicalism »

gurkendoktor wrote: post #112
laurent92 wrote: post #48

Earlier quoted context omitted.

and Java?

The Java community has some great developers, but also a lot of Serious Software Engineers who will sabotage everything with extra complexity, and then everyone who learned Java in school and never felt like looking at another language (not even Kotlin). Java is definitely "boring technology", but hiring random Java developers will probably sink a company faster than doing the same for Go.

> everyone who learned Java in school and never felt like looking at another language

A large reason I avoid Java teams.

Re: Choose Boring Technology (2015)

#137

Post by whimsicalism »

jermaustin1 wrote: post #106
collyw wrote: post #99

Earlier quoted context omitted.

I think maintainability is mostly down to developer skill and the ability to abstract to the right level. A good Python dev will likely leave far more maintainable code than an average Java dev.

> A good Python dev will likely leave far more maintainable code than an average Java dev. And a GOOD Java dev will likely leave far more maintainable code than an AVERAGE Python dev.

I have yet to see this in an enterprise setting, maybe my standard for "average python dev" is too high.

Re: Choose Boring Technology (2015)

#138

Post by cbm-vic-20 »

gurkendoktor wrote: post #112
laurent92 wrote: post #48

Earlier quoted context omitted.

and Java?

The Java community has some great developers, but also a lot of Serious Software Engineers who will sabotage everything with extra complexity, and then everyone who learned Java in school and never felt like looking at another language (not even Kotlin). Java is definitely "boring technology", but hiring random Java developers will probably sink a company faster than doing the same for Go.

The GP comment mentions the need for finding engineers with "a proven track record of delivering value", yet here we have a concern about "hiring random Java developers".

Is the industry biased against great engineers who have been working with Java for the past 20 years, even if they "deliver value" (which is pretty much impossible to determine externally)?

Re: Choose Boring Technology (2015)

#139

Post by whimsicalism »

roenxi wrote: post #25
phendrenad2 wrote: post #2

I always found it funny that companies will go to extreme Herculean lengths to hire the best programmers, and are incredibly fearful and paranoid that they could be making a "bad hire", and yet once hired they don't spend a second making sure engineers aren't completely running the software product off the rails and killing the company internally. The author mentions trying to rewrite Etsy's backend in Scala and Mong…

They are fearful and paranoid of making a bad hire because they don't know how to assess whether the engineer is destroying the company from the inside. If there was a reliable general algorithm to make good software managers would hire lousy engineers then tell them to execute the algorithm. There isn't, they can't. The fallback is to be as picky as possible about who has influence on the software.

> They are fearful and paranoid of making a bad hire because they don't know how to assess whether the engineer is destroying the company from the inside.

This is the obvious conclusion. I wonder when investors will wake up to the value of having engineering-savvy management.

Re: Choose Boring Technology (2015)

#140

Post by ChrisMarshallNY »

_qulr wrote: post #134
ChrisMarshallNY wrote: post #60

Earlier quoted context omitted.

I don’t do “boring,” as much as I do “mature and robust.” I like shipping products, as opposed to just “writing” them, and shipping is boring. Lots of annoying intricacies and processes. I’m writing a fairly large-scale app, right now. It’s written in Swift (frontend), using IB (classic UIKit), and PHP/MySQL/Postgres (backend). It does not use SwiftUI (shiny), or Rust (shiny, but a bit more dusty), or some form of No…

> I don’t do “boring,” as much as I do “mature and robust.” > I’ve been writing in Swift since the day it was announced May I ask how you consider these to be compatible?

> May I ask how you consider these to be compatible?

It was a calculated risk. Since the company I was working for, at the time, was never going to use Swift, my "bread and butter" was at no risk, whatsoever. We were a C++ shop. I just started working with it on nights and weekends.

Being a C++ shop, however, we were quite familiar with Lattner and LLVM, so we were aware of his propensity for WIN. That gave me some confidence, going forward. Also, Apple didn't just announce a language. They also announced a full system API, as well as a product roadmap. The API showed they were serious about it. Those don't come in Cracker Jack boxes. They take some serious work and investment.

It was definitely a risk, but I'm a conservative, scarred veteran of many errors in judgment (can you say "OpenDoc"? I knew you could!). I wasn't about to run into a burning dumpster, half-assed, and I thought it was worth it. I knew it would take four or five years to mature, and it has. I tend to play the long game. I learned that, from all those years, working with the Japanese.

Post reply on HN