Choose Boring Technology (2015) • Hacker News Board

Re: Choose Boring Technology (2015)

#191

Post by the_af » Sun, Jun 07, 2020, 4:23 PM UTC

mlthoughts2018 wrote: post #177

the_af wrote: post #176

Earlier quoted context omitted.

This is true about enterprisey patterns, which for some reason plague Java more than other languages. I think it's a flaw of the moment in time when Java became ubiquitous -- I mean, it still runs most software than many fashionable technologies these days, but it's not as dominant as it used to be -- rather than the language itself. Modern Java doesn't look like that, but indeed older software built with it did. The…

I think that’s largely true, but not completely. It just turns out that certain language features sincerely matter more for business software, such as rapidly mutating object & data models without needs to update them as a ripple effect through other designs in the system, and the ability to trade-off safety or correctness as resources just like memory or runtime complexity, which Java as a language is just not set u…

Maybe my brain is slow today, so please excuse me if this is not what you're saying. Are you arguing that Java is not set up to "do easily" business software or rapidly mutating data structures? Because Java as a battle tested platform has evolved many cool features for exactly those cases. There are even commercial pauseless garbage collectors (and the noncommercial ones are pretty advanced, too). Java and the JVM run circles around many of the technologies that became fashionable later, such as Ruby or the many javascript frameworks.

For an article about "stick to boring and reliable" there seems to be too much push back against Java. I understand the psychological processes involved: stick to boring unless it's the one technology one personally finds unpalatable -- for me that would be COBOL or ColdFusion (and yes, I'm aware Java has been compared to COBOL by proponents of trendier technologies! :P )

Re: Choose Boring Technology (2015)

#192

Post by the_af » Sun, Jun 07, 2020, 4:25 PM UTC

pdimitar wrote: post #178

the_af wrote: post #174

Earlier quoted context omitted.

I haven't dealt with "a lot of XML" in Java for ages. I've been using it in my day job for a decade, and about the only XML I touch is pom.xml (that's the build file for Maven). This is like complaining about stuff in Java 1.4 -- sure, but we haven't been using it for ages. Please don't take it the wrong way, but the days of XML for everything are long gone, and for years in Java it's been XML for nothing as a counte…

Your experience doesn't nullify mine, and vice versa. There's a huge pile of legacy Java applications out there still needing maintenance and occasional new features.

You cannot judge a language and platform merely by legacy software. By that token, almost everything today is horribly broken, even trendier technologies like NodeJS or Go. You'd have to judge C by K&R standards, and C++ as the horrible preprocessor it initially was. It makes no sense!

You must judge Java by the developments of the last decade at the very least. Otherwise you're ignoring the practitioners.

Java hasn't used XML in ages and you cannot fault it for legacy apps. You could similarly complain about the horror of EJBs -- sure, but the industry has moved on and acknowledged they were a mistake.

Re: Choose Boring Technology (2015)

#193

Post by praveen9920 » Sun, Jun 07, 2020, 4:27 PM UTC

leonardteo wrote: post #184

Getting vulnerable here for a sec and hoping that others can add their thoughts. I struggle with this. As a small-ish, bootstrapped business, the issue I commonly run into is developer retention. If we stand our ground and choose boring technology because we have limited innovation tokens and can't afford to waste them, there's the flight risk of those devs who really want to work with those new technologies. And thi…

If you are early stage start-up, all your employees including engineers should be onboarded with the idea rather than technology choice. If you have someone joined you for any reason other than the excitement for idea, there is higher chance that you will find them going off track too often and it will drag you back

If you are mid-size company, I will assume that you can afford giving some breathing space for everyone to explore but still focus on the goal. You should ideally retain them with the culture.

These are the suggestions based on my experience. I may be wrong.

Re: Choose Boring Technology (2015)

#194

Post by pkilgore » Sun, Jun 07, 2020, 4:28 PM UTC

peferron wrote: post #80

gavinray wrote: post #23

Earlier quoted context omitted.

I don't know that necessarily correct. Previous startup I was at had a stack like this: - Frontend: Vue + Typescript - Android/iOS App: Vue (NativeScript/Capacitor) + Typescript - Backend: Node + Typescript - Database: Postgres - Deployment: Everything in Docker containers I know of a lot of places taking similar stances where the frontend and mobile apps are done in this way (IE React and React Native) and then you…

I just built a frontend and backend with TS following this same logic. I'm super happy with TS for the frontend, but I regret picking it for the backend and am considering rewriting the backend in Clojure while it's still early. My reasons are: - I don't need to share type definitions between the frontend and backend; the frontend can generate TS type defs using GraphQL introspection regardless of which language the…

> Static typing doesn't help much with setting up GraphQL resolvers correctly, and overall feels much less useful than on the frontend where it's absolutely stellar to type check all GraphQL queries, React calls, 3rd party component props, and so on.

We found @nexus/schema to be excellent for this particular problem, but only after you set it up correctly to feed in type information via its typegenAutoconfig options.

I agree it is less frequently helpful at catching type errors, but the errors it does catch tend to be more important to get correct than the frontend errors!

Re: Choose Boring Technology (2015)

#195

Post by aphextron » Sun, Jun 07, 2020, 4:28 PM UTC

leonardteo wrote: post #184

Getting vulnerable here for a sec and hoping that others can add their thoughts. I struggle with this. As a small-ish, bootstrapped business, the issue I commonly run into is developer retention. If we stand our ground and choose boring technology because we have limited innovation tokens and can't afford to waste them, there's the flight risk of those devs who really want to work with those new technologies. And thi…

>"If we stand our ground and choose boring technology because we have limited innovation tokens and can't afford to waste them, there's the flight risk of those devs who really want to work with those new technologies."

That's fine, let them go. There are plenty of great developers out there who just want to come to work, build the product to spec in some 'boring' reliable tech, and go home. The stack doesn't really matter. The "mission" doesn't really matter. Even the product barely matters. I've found that people who are leaving a job for the new shiny thing are either very early career, or the dilettantes who leave behind messes to be cleaned up by professionals.

Massive companies have been built around a Spring/Rails/Zend monolith with a few jQuery plugins on the frontend. Anyone who thinks they need more than that is probably wrong.

Re: Choose Boring Technology (2015)

#196

Post by zpallin » Sun, Jun 07, 2020, 4:33 PM UTC

nine_k wrote: post #62

I still think that "boring" is a wrong word. Choose the technology you know in and out, and are immediately productive with. Choose the technology which is sure to be around in 5-7 years, preferably 10-15. Choose the technology for which you are comfortable hiring the next 15 engineers. This does not mean that you need to choose something unpleasant, unergonomic, or ancient. Neither does it mean that you need to choo…

Agreed. I find "boring" to be an unreliable metric for decision-making in software. A boring tool could result in damage to the long term development of software if it is inflexible, for example. Migrations between tools are easily some of the most expensive technical debt costs any software organization may face.

I also agree that the better measurement of good software is that which is unsurprising. Code should be easy to follow, and the decisions for the software tools that are used should be given the same treatment. You should be able to explain your code or infra to most developers without any raised eyebrows. That doesn't make it boring. In fact, it's very interesting when a problem that looks complex on the surface can be solved by relatable means.

Re: Choose Boring Technology (2015)

#197

Post by dahauns » Sun, Jun 07, 2020, 4:39 PM UTC

d0m wrote: post #170

nine_k wrote: post #62

I still think that "boring" is a wrong word. Choose the technology you know in and out, and are immediately productive with. Choose the technology which is sure to be around in 5-7 years, preferably 10-15. Choose the technology for which you are comfortable hiring the next 15 engineers. This does not mean that you need to choose something unpleasant, unergonomic, or ancient. Neither does it mean that you need to choo…

People use "boring" in opposition to "hyped" or "trendy", which like you said totally misses the point. I jumped on react right away when it came out, but not because of it being trendy, but because like you said I could be productive with it right way, I knew it'd be around for 5+ years and that I could hire engineers.

>I knew it'd be around for 5+ years and that I could hire engineers.

How could you have known that right when it came out?

Re: Choose Boring Technology (2015)

#198

Post by non-entity » Sun, Jun 07, 2020, 4:41 PM UTC

scotty79 wrote: post #125

I think the problem is that not all programmers are motivated by successfully building things. Lots of us are motivated by learning things, and some are motivated by investigating and solving problems when things don't go the way they supposed to. If you pick a 'boring' technology, you have less of those two things, and you are stuck with boring process of developing one feature after the other with boring technology…

> I think the problem is that not all programmers are motivated by successfully building things.

> Lots of us are motivated by learning things, and some are motivated by investigating and solving problems when things don't go the way they supposed to.

I kinda realized this about myself recently, and now I'm wondering if I need to leave the field.

Re: Choose Boring Technology (2015)

#199

Post by marcosdumay » Sun, Jun 07, 2020, 4:51 PM UTC

gcoguiec wrote: post #83

nine_k wrote: post #62

I still think that "boring" is a wrong word. Choose the technology you know in and out, and are immediately productive with. Choose the technology which is sure to be around in 5-7 years, preferably 10-15. Choose the technology for which you are comfortable hiring the next 15 engineers. This does not mean that you need to choose something unpleasant, unergonomic, or ancient. Neither does it mean that you need to choo…

Mature Technology? ( https://en.wikipedia.org/wiki/Mature_technology )

Not quite. "Mature" doesn't describe what the article and the GP said, and what seems to happen on practice.

It's even biased the wrong way, tech does become outdated at some point and best avoided, but "mature" only increases with time.

Re: Choose Boring Technology (2015)

#200

Post by RNCTX » Sun, Jun 07, 2020, 4:54 PM UTC

onion2k wrote: post #86

RNCTX wrote: post #85

Earlier quoted context omitted.

It seems to me that simple devops decision making is becoming a forgotten skill outside of devops pros due to separation of concerns, whereas 15 years ago everyone knew how to install Linux or a BSD, set up required compilers and virtual environments, set up Apache or Nginx, set up a database along with database admin tools, etc. Wasn’t any Ansible then, either, you had to write your own damn scripts.

The entire reason PHP grew so wildly in popularity was because hosting providers made it so you could just FTP a file with a .php extension to a server and it ran. Apache was the default web server for shared providers because you could do per account config like url rewriting by uploading a .htaccess file. Virtually no one was configuring their own servers or installing Linux on bare metal for websites.

Not just for websites, for other stuff.

How many people had rented servers for games? A lot. Now video game companies have turned game servers into a SaaS, whereas then they just released Linux server binaries. In the early 2000s there was a bare metal server rental company on every other street corner.

How many people had Linux/BSD network appliances? Also a lot. There was such a time when all you got from the cable or telco for your broadband service was a modem, and you had to roll your own router/switch. There were a multitude of run-from-a-floppy (or USB stick) BSD and Linux router distros back then.

Also, you're not correct on PHP. The entire reason PHP grew so wildly was because it was server side rendered, and both AOL and Microsoft intentionally hindered their browsers' javascript capabilities in lame attempts to monopolize the internet.