My job is designing SAAS software products. Big SAAS systems with enormous complexity and lots of parts, some of which are operating 'out in the wild'.

My biggest challenge? Getting software engineers to think about the problems they are solving with the right level of abstraction. They want to get into the weeds of detail, so they end up talking about how to solve the one particular problem right in front of them.

Whereas I want to solve the CLASS of problem.

[contd]

Follow

Thing is, when you solve one particular problem you've solved that problem. Then the next problem you solve is almost the same, but just different enough the first solution doesn't quite work for it.

Focusing on the details results in either:

1. Organically solve the CLASS of problem over the entire project via incremental changes

–OR–

2. Ending up with a mishmash of different solutions operating at the same time

[contd]

Obviously (2) is non-optimal. But so is the organic solution! Sure, you did it incrementally, but does that make it bad?

Yes it will. An organic solution to a problem class ALWAYS results in a complex, clumsy implementation with weird side-effects, unless schedule and management allow for a full rewrite once you've got it working.

Whereas simply stepping up to the right level of abstraction early does not. The trick is, knowing the right level of abstraction…

[fin]

Sign in to participate in the conversation
Rusted Neuron – an Intentional Community

Rusted Neuron is a Mastodon Instance operated by Jack William Bell