Hacker News Reader

Comment by danjac | Hacker News Reader

As a sole dev you are also pushed towards simplicity, because your time and scope is so limited.

So a larger team might build some intricate DDD-microservices architecture with a services bus and a complex SPA frontend because, why not? That's what everyone else does.

As a single developer managing multiple microservices or separate backend/frontend codebases is a lot of overhead (unless it's a learning project). You have to do the simplest thing that will work. So if you can get away with server-side rendering, do that. A monolith makes more sense when you don't have multiple pizza teams, and so on.

View on HN

Or in other words: Conway's Law makes single developer code bases less complex, since there's no communication and responsibility boundaries reflected in it.

That said, I've seen a lot of small teams create a ludicrous amount of microservices. One per independently working team is my usual heuristic.

There is a problem in the tech industry where people's pattern matching isn't terribly good. They will have worked for a big company, or have read literature produced by people working for big companies, and concluded that "microservices" (to pick one pattern) are the best practice, because it worked for $BIGCORP, or they expect to be $BIGCORP 2.0 at some point, so why not be ready for that?

But, as you point out, microservices are the result of Conway's Law and shipping your org chart, not necessarily the best way to build software all other things being equal. If your org chart fits comfortably inside a broom closet, then maybe you're not quite ready yet for microservices.

In Apple development, there's actually a couple of programming methodologies that were specifically designed to make the code more complex, so it can be farmed out to multiple devs.

In my experience, it's a real good idea to stick to writing basic MVC, when working alone, on a UIKit codebase. If I was working with SwiftUI, I would probably consider MVVM, but I don't really like to take it much past that.

my experience too - if I am the guy for that piece of software (supporting testing, fixing prod issues etc.) then I have all the motivation in the world to make my work as simple and effective as possible. No place for fluff just because its in the vogue and 'big beards' of industry talk about it.

Measure of success of software is pretty straightforward in normal situation - users are happy using it, they don't care about technical details a bit. That and efficiency via simplicity above is how to do this for a decade, instead of building 1-man cathedrals with practically inevitable results

This is true - you may (possibly) end up in a scalability dead end, but you will likely have been far, far more efficient along the way.

I think the only scalability dead end you'll end up in is people-related. That is, you won't be able to scale further because it would require using patterns/solutions that balloon the complexity so much you now need a team to keep track of it, and/or it would require more money than you can manage handling on your own (e.g. you would need to turn your project into an actual business in order to fund it further - at which point you need to start hiring people, to either do the businessy bits for you, or the technical bits, whichever your preference).

Reply on news.ycombinator.com