Companies are just a table where some people put money on it with the idea of taking more from it later. The rest are strategies to make that money grow.
161 karma · joined April 13, 2021
What you do should be based on that analysis. If not, frustration, dissapointment and conflict (internal, external) will follow.
Most business persons I´ve talked to did understood when I told them that the code was a mess, and that if we didn´t work on improving that mess we would start to get into trouble because we will be basing our work on something brittle.
>Turns out that "where to put code" is one of the hard things in software engineering and there are no silver bullets. That's part of the reason why there are so few easy tutorials on this subject.
This is called modularization and there are lots of papers and books that discuss it in decent detail.
When I started coding in the 90s dark mode was associated with old. "Cobol dinos" used dark modes, we "cool kids" used light modes. Nowadays if you ask most young programmers they will say that light mode is old. They use dark mode.
And I guess this idea of hip, has turned mainstream lately. The latest uses "dark"
Tech organizations value their managers in terms of their budget, headcount and being in fashion. As such the tech business model has always been about getting "good enough" results through a brute force process, possibly with the latest tech. Expertise/deep knowledge is only added/valued when the development gets stuck.
For example, the tradeoff between centralized and distributed has been taken (mostly informally) by big institutions for years. It´s not possible for a large bank with multiple overlapping domains, hundreds or thousands of dev tems (some of them outsourced/offshored) to have all of it´s code in a single repo or a single executable. And not all of it´s applications have the same requirements (technical, scale, etc) either.
SOA came to aid in this case by putting a common integration pattern between the interested parts.
But at some point the idea was hyped, and even small teams with no diverse technical or scale problems started doing simple backends using full blown distributed systems without reason.
Basically: if you don´t have problems of scale (domain, technical or people related) going microservices first is probably not granted.
The problem seems to be that quite a number of teams don't have any formation about system design (mono/distributed/mixed).
Most teams go for microservices because of hype and because they see an spagheti monolith and believe the problem is the monolith and not the rotten badly modularized code.
In one of those projects the code got so big and bloated that it took around 1 minute (sometimes more) to move from one line to the next while debugging. For me it was a torture, it was ok for most.
Who do you fear it´s going to do this?
But what about human nature knowledge?
That`s whats get me. Depression is an illness. People wouldn`t accept such take with other illnesses why?
This article, as others, perpetuates the stigma.
I also self diagnose myself with brain cancer and I will start posting advice on how to cure it using my strategies. Do you see the point?