4 ms·

That just makes it a tautology. It basically says “essential complexity exists”.

• peteradio 3y ago
  Maybe but it still useful to know that essential complexity exists and to identify it in your project.
• paulddraper 3y ago
  It's a frame of mind. Often a developer will see something big or complex and see it as a problem. But they should consider whether this matches the size/scope of the problem being solved
  • simplotek 3y ago
    > But they should consider whether this matches the size/scope of the problem being solved In professional software development projects, specially legacy projects, often times the complexity is not justified by the problem. There is always technical debt piling up, and eventually it starts getting in the way.
    • kqr 3y ago
      > often times the complexity is not justified by the problem. Often times means not always -- what would you say some projects are doing right so that their complexity is justified by the problem?
• tracker1 3y ago
  It's often a matter of framing. When you abstract, refactor or move complexity it should serve to make the rest of the system/application easier to understand or for those adding features into the application(s) to be more productive as a whole. If it doesn't do one of those things, you probably shouldn't do it. It's one thing to shift complexity to a different group/team, such as managing microservice infrastructure and orchestration that can specialize in that aspect of many applications/systems. It's very different to create those abstractions and separations when the same people will be doing the work on both sides, as this adds cognitive overhead to the existing team(s). Especially if you aren't in a scenario where your application performance overhead is in eminent danger of suffering as a whole.