Ask HN: Is it just me, or is software development crazy

Sometimes it seemed to me the real reason people were interested in microservices, containers, etc. is that people want to run different applications in JDK 7, JDK 8, JDK 9, JDK 10, ... Instead of getting control of the Python they're running, data scientists can find a Python that uses Hungarian for the default charset. You don't spend the time to get in control, instead you can manage a larger system which is out of control which will waste a lot more time in the long term and maybe even before them.

It always seemed to me that you should standardize absolutely everything you can in a microservice architecture so that somebody who is working on microservice 7 can switch to microservice 35 and not have to learn a different build system, different web server, different system for loading configuration, connecting to a database and similar details. Not to say there isn't a good reason to use more than one language in some case (e.g. Python for training an ML model, Java for everything else.)

In other words: not-so-micro services, or are you arguing for the return of monolithic architectures?

I would write microservices in Java without opening my big mouth if I had bills to pay.

If I already have a job or a comfortable money buffer, I wouldn’t join a software company with a stack I don’t appreciate.

This is just your experience/maturity growing over time. Software development goes through cycles of hype, and it's all too easy to get swallowed by all the excitement. Over time you start realizing that there are no silver bullets, and it's all tradeoffs on top of tradeoffs. Solutions to most problems now start with "it depends", and you're slowly starting to resemble the gray-hairs whom you dismissed as cynical early on. The complexities have always been there, you're just getting wise to them. You're in good company, welcome :)

Sounds like have a big ego if you think your opinions are ahead of the curve.

What role levels are you applying to where you are advocating for a specific direction?

"Make things that are easier to reason with. Code that is easy to reason with and replace is the code that will run for decades."

I agree 100%, and, apparently many others did :

https://en.wikipedia.org/wiki/KISS_principle

When I started out programming in the 90s the KISS principle was mentioned, but I don't hear it so much these days. Maybe we all ought to start talking about it more.

Having been a developer for ages, ridiculous over-complexity of software has always been a problem. It comes and goes I think.

> Is it just me, as I'm in the middle of a job search as everything is shifting where I feel like I've progressed past?

It could be just you. Perhaps you're so far ahead of the curve that it will take years for the rest of us to catch up, and by then you'll have moved on again.

Simplicity is underrated by a lot of people. I think engineers (myself included) like to overcomplicate things, and think that if something simple implies it not being an intelligent design.

As I mature, I realize that intelligence != complexity, and more often than not, a simpler approach is harder to design and much better in the long run.

You are not particularly unique, many before you with exactly the same experience. Your work experience makes you above average at least and so you know what needs to happen.

Other people are not so lucky to have your experience and so they make bad decisions. You can fix this, but it means you have to give up 'doing' and become an evangelist for your beliefs.

Also like many before you, that's a personal choice and might not be a good fit for you. Only you can say.

Someone said about software a long time ago: we don't stand on the shoulders of giants, we kick them in the shins.

Or something like that

Software Development at companies is often like living on an alien planet. It takes information years to propagate to the company[1]. There's a multi-year delay between what you're doing and what you should be doing. Some, I'd imagine, try their best to predict what will happen to compensate for this delay, others may just follow along with the latest and greatest[2] even if there's a multi-year delay.

[1] Even if it reaches faster than speed of light, it may not be accepted or acted upon immediately. The analogy kinda falters here, but hopefully you get the point.

[2] perhaps "greatest" should be replaced with the word "popular" or "trendy"

With all due respect, these are your opinions about your experience. You may think you are ahead of the curve, but what objective measure are you using?

Someone else's decades of experience could lead to opinions that are the polar opposite of yours and be equally valid. You may have had "wrong" experiences and just got lucky that things worked out ok in the end - who is to know?

My advice would be, if you are interviewing, show humility - don't show ego.

You can also optionally don't care and get the paycheck.

Are you getting paid for this type of decision leading to your frustration ?

Are you applying to correct role ?

I was recently thinking of posting a similar ask hn, but opted not to because if felt too complainy and I’m not sure if the issue is with me or not.

I mainly feel that the scope of a developer’s responsibilities is constantly growing and it’s becoming too much.

I started doing front-end ~20 years ago. At that time we got a psd file, cut it into pieces and created a clickable mock-up. Maybe you’d need to loop through some php of a templating language to make it more dynamic but the logic resided in the backend.

Today I’m still responsible for converting that design, but it’s no longer a clickable mock-up, it’s now an application with its own state and logic that needs to be managed. We now have auth in the client so OAuth comes into play as well.

Instead of creating an index.htm and style.css we npm init which throws cryptic errors about mismatched dependencies, use a bundler, typescript, eslint, … all with their own config. It’s crazy to juggle all this config he’ll.

We used to upload our files to an ftp and called it a day. Now I have to setup a CI/CD, configure our AWS setup and it should all happen in one sprint.

As a React developer it’s also assumed that you know React Native. So you don’t only need to manage node, npm, … you’re now managing Xcode, Android Studio and the entire ecosystem that comes with it. How can you possibly build something of quality under these circumstances?

So yes, we should take a step back and look at the complexity we’re creating. Or at least look into splitting up that complexity into more different roles so that a front-end developer can do front-end again.

I find that small, separate, decoupled services make for easier, more complete testing. Designs like that also tend to minimize race conditions. Multi-thread all you like if there are no races!

I haven't heard anyone talking about new, safe ways to do threading to avoid those problems. Nor have I heard anyone talking about how to constrain individual parts of a monolith so that it can be reasoned about in any way other than a big ball of goo with potentially magical behaviors.

I'm also somewhat concerned that GraphQL is becoming the new monolith. Or at the very least, the new single point of failure.

So . . . I, for one, don't think "balance" is moving back to more tightly coupled code. And I worry that we don't know where to go from here so we'll revert to yesterday's problems (new again!).

Here's my heretical views. What's yours?

- the world is full of too many coders writing too much code

- most business logic should be in the database

- I blame the Apple II for the ORM quagmire

- I also blame it for the gender disparity in tech

- tech is littered with the tombstones of ideas that were ahead of their time at their time and still are today

- XML is one of them

- so is XSLT