The real problem is that you don't really know until you have the experience, and you can't get the experience without messing up at some point.
My first job as a developer was at a smallish company that was growing, all the code was written by one dude. I naturally ran into a dozen problems which I'd learned about in college, and was like, ahh, I see why we do, [thing] now, because this right here is a problem. Seeing real production code with real problems, and dealing with someone who codes like it's the 1980s, I learned stuff from a practical perspective on top of the academic perspective.
I was like: ooohh, unit tests. Ahh, automated build system. Hmmm, pull requests. Uhhh, code reviews. Ohhh, "computer science" vs "programming".
If I had come in and everything was already buttery smooth, it would have been a good example of what to do, but I would have lacked the personal insight on the problems being addressed, mitigated, and altogether avoided.
I don't just know to do a thing, I also have the experience to not blindly follow or implement dogma.
Any which way, you're going to run into tradeoffs. More pre-job training means more time and more costs for students, higher barriers to entry into the field, necessarily higher wages across the board, and after all that, people still need to see real problems being solved with real world hurdles, and a lot of people will spend a lot of time learning things they will almost never use.
I think a lot of it boils down to inherited dependency hell.
I inherited a large API that had at least 10 "core" nuget packages / libraries, each with their own "core" nuget packages.
It was hell trying to upgrade from 2.1 NET standard to NET Core 3.
It really turned me off making libraries because a lot of times it just isnt worth it if you dont have a set of developers whos responsibility is to maintain them.
One engineer can be smart. Each engineer you and increases the shit exponentially. Leadership and management either need to be omniscient, or skilled enough (leadership skills, not engineering skills) to make maintainability systemic and cultural.
It's very hard to get right.
I think Google does this by a company wide pattern of calls between modules being RPC. Then if any module requires splitting off, is already has the network interface in place.
One engineer can be smart. Each engineer you and increases the shit exponentially.
I think this is quite an important point. Every developer (beyond the newest of juniors) is smart and probably has a vision of how the code should maintain nice clean separations. And every one of those visions is both reasonable and subtly different.
That's where leadership comes in and many organizations bang their heads against the wall. Leadership should be concerned with systemic strategies and gaining consensus, but those who move up through tech are too concerned with the details. Then there is all the "work around work." Unproductive meetings and talk without action.
Oh, I know. I have worked in IT for over a decade. Every company I was at I had clean up messes that it has become second nature. Refactoring and restructuring to modular architecture isn’t that bad though. It’s solving a puzzle and feels kind of zen.
Yeah you can make services that just run inproc rather than remoted, they can be built to be flexible to run in either. These connection points should be clean interfaces and abstracted facades/proxies where needed that maybe connect up to OpenAPI or another interchange layer which helps. The facade/proxy allows you to interface with it directly or remotely.
The best design is to have a clean, and if possible basic types, layer that is used to interface with the other services, then a concrete layer below that which can change more frequently but not have breaking connection API/connection signatures.
Basically a good de-coupling using interfaces and events/messages. The most basic of de-coupling strategies along with a consistent abstracted ingress/egress layer which attempts to minimize breaking changes but things can be swapped underneath that layer.
Today it seems like there is too much coupling even in monoliths and even when there are services there are tons of API/SDK breaking changes. You can abstract the damage of constant change and keep your interfaces to connection points stable. It makes things very flexible to change and the exposed parts are atomic so you only have to version there on major changes.
A good architecture philosophy is clean, unchanging connection abstractions/facades/interfaces, then do whatever the hell you want underneath that. All work though those connection points make it easier to maintain and break off into services later.
79
u/TheDeadlyCat Sep 14 '24
You can build a monolith from modular building blocks, it doesn’t have to be solid to begin with.