3 ms·

We could do this. And if you take a look at some solutions like the old VisualBasic/Delphi/Unix scripts, the philosophy is the same: Create small software quick

We could do this. And if you take a look at some solutions like the old VisualBasic/Delphi/Unix scripts, the philosophy is the same: Create small software quickly that solves some user/business needs. Systems like Java/.Net and their IDEs, as all as current mobile SDK, they run against that need. A bit of tangent: I think the idea of coddling users is what’s leading to the complexity of all those system. We’re building cathedrals when we need tents. Instead of having small, sharp software tools that can be adjusted easily, we’re developing behemoths that’s supposed to handle everything under the sun (systemd, a lot of modern package managers, languages that is tied to that one IDE,…)

ghaff 1y ago
Well, except you end up with 20 different incompatible tools with different workflows. I'm not really arguing for mega-tools with locked-down workflows. But there's usually some happy-ish medium between chaos and rigid monoliths.
- listenallyall 1y ago
  > 20 different incompatible tools with different workflows Kinda the whole goal behind (and "benefit" of) microservices, right? Totally independent dev teams, all uncoupled from each other, no need to look inside at the code, language-independent - just pass data according to an API and dont look behind the curtain.
  - TeMPOraL 1y ago
    Internally it could work if the teams understand that their services are never done - they're part of a living organism, and the responsibility of a team assigned to a service is to keep it working. Shit will break constantly, but that's not a problem as long as it gets fixed. It's labor-intensive, but done right, we're talking few devs being busy maintaining a process that benefits thousands, or hundreds of thousands of their colleagues. It's what the internal development is meant to be. At some point in our industry, "service providers" started thinking of themselves as kings, instead of what they were supposed to be - servants.
  - ghaff 1y ago
    That's the theory. You can also end up with a lot of effort devoted to maintaining totally independent tool chains which may have a single person bus factor.

ghaff 1y ago

Well, except you end up with 20 different incompatible tools with different workflows. I'm not really arguing for mega-tools with locked-down workflows. But there's usually some happy-ish medium between chaos and rigid monoliths.

listenallyall 1y ago
> 20 different incompatible tools with different workflows Kinda the whole goal behind (and "benefit" of) microservices, right? Totally independent dev teams, all uncoupled from each other, no need to look inside at the code, language-independent - just pass data according to an API and dont look behind the curtain.
- TeMPOraL 1y ago
  Internally it could work if the teams understand that their services are never done - they're part of a living organism, and the responsibility of a team assigned to a service is to keep it working. Shit will break constantly, but that's not a problem as long as it gets fixed. It's labor-intensive, but done right, we're talking few devs being busy maintaining a process that benefits thousands, or hundreds of thousands of their colleagues. It's what the internal development is meant to be. At some point in our industry, "service providers" started thinking of themselves as kings, instead of what they were supposed to be - servants.
- ghaff 1y ago
  That's the theory. You can also end up with a lot of effort devoted to maintaining totally independent tool chains which may have a single person bus factor.