6 ms·

> At worst you are maintaining an old monolith trying to figure out someones logic from 15 years ago. Can you imagine what it will be like 15 years from now, w

> At worst you are maintaining an old monolith trying to figure out someones logic from 15 years ago. Can you imagine what it will be like 15 years from now, when we're trying to maintain someone's microservices with their logic smeared out across dozens of distributed API calls, storage backends, and code bases?

einpoklum 6y ago
That in itself will not be a terrible problem. If it's well-documented at the macro an micro level, and if those micro-services are coded according to the "principle of least astonishment" - it will likely be easier than some million-line code silo. B-U-T... All those if's probably don't hold. Good luck, future code monkeys!
- BossingAround 6y ago
  > If it's well-documented Well-documented is the biggest lie of any project. Unless you document it that is, in which case it's the only well-documented project.
  - esmi 6y ago
    My code is perfectly documented. I just choose to write my documentation in c++. :)
    - Koshkin 6y ago
      Sure... It’s just that C++ is not the best language to write documentation in.
    - BossingAround 6y ago
      Ah, I might be mistaken... The biggest lie might not be "it's well documented," but "it's self documenting" :))
- watwut 6y ago
  If million-line code silo is well-documented at the macro an micro level and coded according to the "principle of least astonishment", it will be easy to maintain too.
  - einpoklum 6y ago
    With micro-services and a lot of use of (FOSS) infrastructure, there is hopefully a lot less code that's actually part of your own project/app/framework.
phaedrus 6y ago
I'm already maintaining an application written 15 years ago which is almost like this. It's in C++ but it's like they thought they were writing Erlang (without the tools or language support). Every task from the most trivial to the most complex is a separate thread using Windows messages to communicate. It's impossible to follow the plot to understand what is going on because the thread of execution disappears with ever message post to be picked up by a message receive somewhere else. The messages are globally sent/received so there's not even a channel receiver to look for everyone is a sender and receiver peeing in the same pool. At least it's all in one process / one codebase.
- hinkley 6y ago
  I had somewhat similar experience with event-driven systems. I figured microservices would flame out a lot faster as they ran into the same class of problems. We do have some slightly better for managing the logistics though. Small force multipliers can add up to quite a lot in aggregate.

einpoklum 6y ago

That in itself will not be a terrible problem. If it's well-documented at the macro an micro level, and if those micro-services are coded according to the "principle of least astonishment" - it will likely be easier than some million-line code silo. B-U-T... All those if's probably don't hold. Good luck, future code monkeys!

BossingAround 6y ago
> If it's well-documented Well-documented is the biggest lie of any project. Unless you document it that is, in which case it's the only well-documented project.
- esmi 6y ago
  My code is perfectly documented. I just choose to write my documentation in c++. :)
  - Koshkin 6y ago
    Sure... It’s just that C++ is not the best language to write documentation in.
  - BossingAround 6y ago
    Ah, I might be mistaken... The biggest lie might not be "it's well documented," but "it's self documenting" :))
watwut 6y ago
If million-line code silo is well-documented at the macro an micro level and coded according to the "principle of least astonishment", it will be easy to maintain too.
- einpoklum 6y ago
  With micro-services and a lot of use of (FOSS) infrastructure, there is hopefully a lot less code that's actually part of your own project/app/framework.

phaedrus 6y ago

I'm already maintaining an application written 15 years ago which is almost like this. It's in C++ but it's like they thought they were writing Erlang (without the tools or language support). Every task from the most trivial to the most complex is a separate thread using Windows messages to communicate. It's impossible to follow the plot to understand what is going on because the thread of execution disappears with ever message post to be picked up by a message receive somewhere else. The messages are globally sent/received so there's not even a channel receiver to look for everyone is a sender and receiver peeing in the same pool. At least it's all in one process / one codebase.

hinkley 6y ago
I had somewhat similar experience with event-driven systems. I figured microservices would flame out a lot faster as they ran into the same class of problems. We do have some slightly better for managing the logistics though. Small force multipliers can add up to quite a lot in aggregate.