5 ms·

It's easy to sit back and say that, but I can almost guarantee that if you actually follow this up with a set of opinions about what stack / architecture / appr

It's easy to sit back and say that, but I can almost guarantee that if you actually follow this up with a set of opinions about what stack / architecture / approach is easiest to debug and change, you will find yourself back in the argument with the rest of us stupid people. I believe there's a lot more variables than "how easy is something to debug and change". The issue is that how easy something is to debug and change is very contextual to the point in the lifetime of an application, the industry the application will live in, and the changing requirements as the application grows in complexity. Even the simplest interpretation of your statement leads to considerable argument. Often the ease of change and the ease of debugging are at odds with one another, where a highly dynamic approach might make change a breeze, but make debugging more difficult.

Timpy 3y ago
I agree that "easy to debug" is subjective. But it's insanity to act like that doesn't mean that some architectures are objectively easier to debug than others. How can splitting something up into different services and introducing network calls make it easier? You're not reducing complexity at all. It makes debugging harder.
- lemmsjid 3y ago
  It would indeed be insanity to argue that, which is why I didn’t. The argument for splitting into micro services is generally that particular teams would own particular services and therefore make debugging/change easier for them, at the cost of increased overall complexity of the overall system. Anyone arguing it reduces complexity is being very hopeful. I personally think an org should generally cling to a so called monolith as long as they possibly can. But it’s very hard to be prescriptive without knowing particulars of the problems an org is trying to solve.
antoniojtorres 3y ago
This very much. I find that often times we are looking at a narrow subset of the factors that lead to certain choices or technologies. Yes, there is a lot of fluff sometimes but there’s also the cycle of wanting to improve on existing pain points. Things like serverless appeal to businesses due to the much smaller logistical implications it presents to a business. Some businesses enjoy that (at least as promised), It’s all taken care of and the team you need to manage it is likely to be smaller. It’s pay as you go for what would otherwise imply more human beings and contracts on your plate. I imagine at some point those baked in costs and redundancies, the luxury of having huge scale on demand in a general sense, will be much higher than something thoughtfully designed when a company has understood their needs well enough after operating at scale. For what it’s worth I prefer bare metal clusters :)
- foffoofof 3y ago
  Serverless in the way we do it today is the best example of something that is impossible to debug. Every choice people have to make in tech today comes with this crazy tradeoff of where you get some benefit like scalability, but then it becomes impossible to debug or change. What's crazy about modern tech is that we've created a world where its so difficult to change things that its analogous to building pipes under asphalt roads. You have to spend all night with a construction crew digging up the road just to change a small thing, and then you have to put it all back again. Except that we work with digital stuff (any physical stuff is completely abtracted) where we can theoretically change anything instantly. The fact that we use shipping container analogies is ironic, if you've ever seen how long shipping loading/unloading and transport actually takes. We need to get back to the computer as the bicycle of the mind...at the moment it is not. I think we will look back on this era of tech as we do to the era of the secretary on the typewriter...and laugh at the inefficiency.
  - antoniojtorres 3y ago
    Agreed on the trade offs, not sure if to the same degree though. It seems to me that it’s critical to know if you’re gonna end up going “against the grain” on a platform that makes as many decisions as a serverless one does.
foffoofof 3y ago
> set of opinions about stack The stack doesn't exist today. It could have if we didn't jump so quickly to new technology and all these different prog languages. I've just never heard someone pitch new tech with: "easy to debug and change". It's always: look at this contrived example with some new esoteric feature.
- lemmsjid 3y ago
  I get your cynicism because I've made the same complaint. But I wouldn't universalize it, because I think it's more of a marketing and context issue than an issue fundamental to the whole ecosystem. Startups often prioritize time-to-market for what is effectively a prototype. Startups get a lot of hype. Therefore, frameworks that focus on time to market over refactoring / debugging get a lot of hype. Sometimes those frameworks actually internally put a lot of effort into refactoring / debugging, but when it comes to marketing themselves, they don't. But some frameworks are marketed more towards mature or large organizations, and they certainly do emphasize refactoring / debugging. The JVM and .NET runtimes are big examples here. Their debugging and operational monitoring capabilities are several classes above most of the competition, and their primary and tool-vendor ecosystems continually push further debugging capabilities as features.
  - foffoofof 3y ago
    > JVM and .NET runtime Maybe I'm too caught up in startup-land, as I haven't touched these tools in a long time. The debugging tools and IDE support on these platforms have always been great. The Visual Studio install time, the huge frameworks, slow start time, bad package managers, were such killers for productivity.

Timpy 3y ago

I agree that "easy to debug" is subjective. But it's insanity to act like that doesn't mean that some architectures are objectively easier to debug than others. How can splitting something up into different services and introducing network calls make it easier? You're not reducing complexity at all. It makes debugging harder.

lemmsjid 3y ago
It would indeed be insanity to argue that, which is why I didn’t. The argument for splitting into micro services is generally that particular teams would own particular services and therefore make debugging/change easier for them, at the cost of increased overall complexity of the overall system. Anyone arguing it reduces complexity is being very hopeful. I personally think an org should generally cling to a so called monolith as long as they possibly can. But it’s very hard to be prescriptive without knowing particulars of the problems an org is trying to solve.

antoniojtorres 3y ago

This very much. I find that often times we are looking at a narrow subset of the factors that lead to certain choices or technologies. Yes, there is a lot of fluff sometimes but there’s also the cycle of wanting to improve on existing pain points. Things like serverless appeal to businesses due to the much smaller logistical implications it presents to a business. Some businesses enjoy that (at least as promised), It’s all taken care of and the team you need to manage it is likely to be smaller. It’s pay as you go for what would otherwise imply more human beings and contracts on your plate. I imagine at some point those baked in costs and redundancies, the luxury of having huge scale on demand in a general sense, will be much higher than something thoughtfully designed when a company has understood their needs well enough after operating at scale. For what it’s worth I prefer bare metal clusters :)

foffoofof 3y ago
Serverless in the way we do it today is the best example of something that is impossible to debug. Every choice people have to make in tech today comes with this crazy tradeoff of where you get some benefit like scalability, but then it becomes impossible to debug or change. What's crazy about modern tech is that we've created a world where its so difficult to change things that its analogous to building pipes under asphalt roads. You have to spend all night with a construction crew digging up the road just to change a small thing, and then you have to put it all back again. Except that we work with digital stuff (any physical stuff is completely abtracted) where we can theoretically change anything instantly. The fact that we use shipping container analogies is ironic, if you've ever seen how long shipping loading/unloading and transport actually takes. We need to get back to the computer as the bicycle of the mind...at the moment it is not. I think we will look back on this era of tech as we do to the era of the secretary on the typewriter...and laugh at the inefficiency.
- antoniojtorres 3y ago
  Agreed on the trade offs, not sure if to the same degree though. It seems to me that it’s critical to know if you’re gonna end up going “against the grain” on a platform that makes as many decisions as a serverless one does.

foffoofof 3y ago

> set of opinions about stack The stack doesn't exist today. It could have if we didn't jump so quickly to new technology and all these different prog languages. I've just never heard someone pitch new tech with: "easy to debug and change". It's always: look at this contrived example with some new esoteric feature.

lemmsjid 3y ago
I get your cynicism because I've made the same complaint. But I wouldn't universalize it, because I think it's more of a marketing and context issue than an issue fundamental to the whole ecosystem. Startups often prioritize time-to-market for what is effectively a prototype. Startups get a lot of hype. Therefore, frameworks that focus on time to market over refactoring / debugging get a lot of hype. Sometimes those frameworks actually internally put a lot of effort into refactoring / debugging, but when it comes to marketing themselves, they don't. But some frameworks are marketed more towards mature or large organizations, and they certainly do emphasize refactoring / debugging. The JVM and .NET runtimes are big examples here. Their debugging and operational monitoring capabilities are several classes above most of the competition, and their primary and tool-vendor ecosystems continually push further debugging capabilities as features.
- foffoofof 3y ago
  > JVM and .NET runtime Maybe I'm too caught up in startup-land, as I haven't touched these tools in a long time. The debugging tools and IDE support on these platforms have always been great. The Visual Studio install time, the huge frameworks, slow start time, bad package managers, were such killers for productivity.