Live data from Hacker News

Ask HN: Are we overcomplicating software development?

news.ycombinator.com

321–330 of 378 posts

Re: Ask HN: Are we overcomplicating software development?

#321

One of my fav tech talks ever (and I watch a lot of tech talks) is Alan Kay's "Is it really 'complex'? Or, did we just make it 'complicated'?" It addresses your question directly, but at a very, very high level. https://m.youtube.com/watch?v=ubaX1Smg6pY Note that the laptop he is presenting on is not running Linux/Windows/OSX and that the presentation software he is using is not OoO/PowerPoint/Keynote. Instead, it is…

Alan just complicated his own laptop by not using which is proven to work.

No, he made a point, which no one would have believed without his example.

The whole vertical software stack sitting on top of the hardware of a PC is generally considered a massive towering best with layers of abstractions, and armies of programmers needed to implement and maintain each layer. To say that this does not need to be so, would be taken as theoretical, impractical nonsense without any proof. Which actually would be a valid position, because doing software is so hard that generally you can't guarantee will something work without actually doing it.

So, yes, to make that point, and to have it taken seriously, he really needed such an example.

Re: Ask HN: Are we overcomplicating software development?

#322
post #265

Earlier quoted context omitted.

One caveat is that if you need to fix a bug in your library in an API-compatible way, you can't reach into all the codebases that are using your library. You can deploy a new version of the microservice, though.

> you can't reach into all the codebases that are using your library You can deploy a new version of the dll and applications can pick it up when they restart. Linux will apply security patches this way.

Better, you can do it without a restart is you can serialise current state. That also enforces discipline in defining such state.

Microservices are only a step ahead.

That said, in many cases the cost of a full restart can be accepted.

Re: Ask HN: Are we overcomplicating software development?

#323

Earlier quoted context omitted.

Nothing about splitting your app into microservices _forces_ a good design. I've never seen microservices with well-defined seams. Every time, knowledge "leaked" between the apps, and any non-trivial change to the app required updating multiple repos, deployment synchronization, etc. Microservices are a tremendous burden that the vast majority of companies will not benefit from.

I did not mean microservice as in "just make it many apps!". I meant as do not share databases and expose everything as APIs. It helps cognitive load because such apps can be reasoned about without reading code elsewhere.

API is not enough, full contract has to be shared.

Re: Ask HN: Are we overcomplicating software development?

#324

Earlier quoted context omitted.

I believe, for small shops, the real benefit of microservices is the logic split that forces good design and reduces cognitive load. You reap the scaling benefits way later, if ever.

I think this is actually a failure in mainstream programming languages, which make it far too easy to reach across what's meant to be a defined subsystem boundary and meddle where you shouldn't.

They also have to weak tools to automate enforcing contracts. Generally the only available tool is "assert".

Re: Ask HN: Are we overcomplicating software development?

#325

Earlier quoted context omitted.

In our case, we did that using functional programming & type-driven design (which ironically is also a TDD.)

T(est)DD does tend to make your code look more like you used a functional-oriented language. A lot less mutability, heavier use of first-class functions, etc. Though I tend to prefer languages that are at least somewhat functional (eg. python, go).

It doesn't even help people enough apply SOLID principles.

Pure functions help but the principles of generalisation are deeper than this.

Tests verify contracts offline. This will miss real issues.

Re: Ask HN: Are we overcomplicating software development?

#326
post #53

Earlier quoted context omitted.

I find microservices can help in just keep everything small and focused. I know you can do this with a monolith. But having a process boundary really enforces it.

I find that the boundary creates operational headaches. A function call won't time out, deliver a 502 error, have authentication/authorization issues, require load balancing, etc. etc. A REST API will. Plus, once you've debugged a problem that involves crossing 5 microservice boundaries you'll start to wonder if it was all worth it. Monolith is also a wrong (and somewhat derogatory) word to describe a non-microservic…

Well said. "Monolith" is a pejorative that prejudices any discussion of said code.

Re: Ask HN: Are we overcomplicating software development?

#327
post #220

Earlier quoted context omitted.

In our case, we did that using functional programming & type-driven design (which ironically is also a TDD.)

This this this! Most often I see TDD used as a couch for a really bad type system.

Types are just formalised limited contracts. Emphasis on limited. They are not enough.

Re: Ask HN: Are we overcomplicating software development?

#328

Earlier quoted context omitted.

One thing that bothers me is the 'relational databases are good enough' statement, that is repeated in other contexts as well. But especially here, where we're talking about reducing complexity, it feels off to me. PostgreSQL and MySQL seem to me like incredibly complex packages. SQL, the language, is not easy to master either; most programmers I meet know mostly basics. On top of that, there's a long ongoing history…

Postgres and MySQL aren't overly complicated for simple use cases. A lot of other technologies drop complications like foreign keys which you won't miss when you start developing software but it gives guarantees you will miss sorely when you start seeing inconsistent data 6 months in.

The expensive and complicated thing about these is deployment and maintenance. But then, you could instead pick sqlite and switch to big one when needed.

Sometimes it is good to get a pickup truck ahead of time, but often a smaller less versatile car will suffice. But not quite a motorbike.

Re: Ask HN: Are we overcomplicating software development?

#329

I think in many cases complexity just comes from lack of experience and poorly understood requirements. I've had my fair share of cases where I ended up implementing something needlessly complicated, only to later realize my approach was terribly misguided. I'd like to think I'm slowly improving on this as time goes on. The software world has a big discoverability problem. Even though I know there's probably prior ar…

Honesty.

Re: Ask HN: Are we overcomplicating software development?

#330
post #106

1. What problem are you optimizing for? "The job" encompasses code, but it also encompasses staffing. It's a lot easier to hire Java developers than Scala developers. In a leadership role, your responsibility isn't just the day-to-day code - it's the whole project. 2. Microservices vs monoliths is a see-saw. You build a monolith, find it's a brittle, incomprehensible hairball, and you break out microservices. You bui…

> Which kneecap do you want the bullet in?

Funniest thing I've heard all day!

Post reply on HN