3 ms·

As programmers we are ingrained to look further than the problem at hand. We try to see the bigger picture, solve problems in holistic ways if possible. Often

As programmers we are ingrained to look further than the problem at hand. We try to see the bigger picture, solve problems in holistic ways if possible. Often this can lead to over-engineering, creating more corner cases and ambiguity in requirements and reduction of test coverage. That is a trap to lok out for. On the other hand it also can lead to better understanding of the problem space, increase understandability, and less need for later refactoring. Just stating, 'don't look further than the problem you are required to solve' is not an excellent general rule.

gherkinnn 2y ago
The trick is not to stop at the birds-eye view but to see that one small change that is actually required from up high and dive back down.
Nevermark 2y ago
I don’t think it makes sense to not think of generality options. Often that helps us see a problem in more ways. Come at it from different directions. Generalizing mentally is map discovery, But when it comes to implementation, any code that is there to enable unused generality is unused and unnecessary code. Any unused freedom of interface increases the chance of unintentional misuse or sleeper bugs. The number of ways unnecessary code or loose constraints can be unhelpful is unlimited. When it comes to optimizing, testing, maintaining, it is optimal to have the narrowest mission possible. — The exception is when designing a platform or library, with open ended reuse. Then value can genuinely be increased with greater applicability. Then there will be generality vs. focused tradeoffs whose resolution will be very context dependent. On the subject matter and its potential market/users.
switchbak 2y ago
Yeah, it's a real challenge to come up with low resolution rules/heuristics. That becomes much harder when you're tailoring your message to different communities / expertise levels. I agree with you, but I also get where the author is coming from. Sometimes simple guard rails for new devs is a lot better than ultra detailed nuance that leaves them without a simple path forward. In my experience I've witness horrible examples of both extremes. Overgeneralized yet poor solutions, and (often duplicated) hyper specific solutions. Both typically from less experienced folks. I think more communication and mentoring would really have helped more there.
DanielVZ 2y ago
Good point. I guess it also depends on what are you further looking into. A few months ago I implemented a feature a client requested that was being charged by the hour. When code review came a more senior engineer suggested a huge refactor that in the end would leave cleaner code but required changing half of the small code base. I pushed back saying it wasn’t necessary due to the scale of the library we were working on. Turns out he took on the task to refactor it himself, broke both my code and preexisting code, and I had to go in and spend triple the amount of time debugging the refactor. A few months pass by and the whole code base will forcefully have to be refactored again to be merged into another code base. He was looking further into making a clean code base, but I was looking further into saving our clients a few thousand bucks and delivering early. Which one was right? I’ll reflect on that after this new refactor and see how much the previous one helps (or doesn’t).
virgilp 2y ago
> Just stating, 'don't look further than the problem you are required to solve' is not an excellent general rule. It's still pretty good though; I think the only better formulation is "only implement a general solution if it's _simpler_ than the particular/specialized solution". Sometimes, that is indeed the case - but it's pretty rare. So if you want to keep things simple, "don't generalize until you have 3 examples" is a pretty solid rule-of-thumb.
- psychoslave 2y ago
  But the main issue with that kind of remarks is that we are not omniscient demiurges. If we don’t try to implement two approaches, then we won’t be able to judge based on actual facts and metrics. If we already did that in the past often enough, sure we can gain some intuition on what will be the actual outcomes of the tradeoff we retain. But paying the price to build such an expertise is also a tradeoff. In particular we might desire to provide the most sound and solid solution from a grand master quality level. But if the whole market is already in the hand of a few players that went with the old card of "occupy the territory first and (possibly) consider quality later", our grandiose art will be also a path to starvation.
  - virgilp 2y ago
    > our grandiose art will be also a path to starvation. That's what I'm saying, that in general the "grandiose art" _is_ a path to starvation, in a lot of business software at least. Because the actual (eventual) requirements are often unknowable at the start, and the initial assumptions are often invalid/false. So if you build your grandiose architecture based on wrong initial assumptions, it'll still lead to a subpar product even if the architecture was perfectly correct (given said assumptions). It's better to approach it with the idea that you're not writing code that needs to run 1 more than e.g. 1 year (but, you ARE writing code that you might need to maintain next year! that's a subtle but important difference. You write code to move fast now - not to enable you to move fast 1 year later; BUT, at the same time you write code that won't slow you down horrendously, in case you can no longer delete it 1 year later).
- vrighter 2y ago
DrScientist 2y ago
It think it's essential to understand the problem you are trying to solve - however often that problem is how to do something better in the specialised case than the current tools that support the general case. ie why is anybody writing any new software these days when Powerpoint, Excel and Word cover all the use cases in the general case? ( I exaggerate for effect ).
ergonaught 2y ago
Trying to solve a generalized problem in response to advice to refrain from prematurely generalizing solutions. 10/10.

gherkinnn 2y ago

The trick is not to stop at the birds-eye view but to see that one small change that is actually required from up high and dive back down.

Nevermark 2y ago

I don’t think it makes sense to not think of generality options. Often that helps us see a problem in more ways. Come at it from different directions. Generalizing mentally is map discovery, But when it comes to implementation, any code that is there to enable unused generality is unused and unnecessary code. Any unused freedom of interface increases the chance of unintentional misuse or sleeper bugs. The number of ways unnecessary code or loose constraints can be unhelpful is unlimited. When it comes to optimizing, testing, maintaining, it is optimal to have the narrowest mission possible. — The exception is when designing a platform or library, with open ended reuse. Then value can genuinely be increased with greater applicability. Then there will be generality vs. focused tradeoffs whose resolution will be very context dependent. On the subject matter and its potential market/users.

switchbak 2y ago

Yeah, it's a real challenge to come up with low resolution rules/heuristics. That becomes much harder when you're tailoring your message to different communities / expertise levels. I agree with you, but I also get where the author is coming from. Sometimes simple guard rails for new devs is a lot better than ultra detailed nuance that leaves them without a simple path forward. In my experience I've witness horrible examples of both extremes. Overgeneralized yet poor solutions, and (often duplicated) hyper specific solutions. Both typically from less experienced folks. I think more communication and mentoring would really have helped more there.

DanielVZ 2y ago

Good point. I guess it also depends on what are you further looking into. A few months ago I implemented a feature a client requested that was being charged by the hour. When code review came a more senior engineer suggested a huge refactor that in the end would leave cleaner code but required changing half of the small code base. I pushed back saying it wasn’t necessary due to the scale of the library we were working on. Turns out he took on the task to refactor it himself, broke both my code and preexisting code, and I had to go in and spend triple the amount of time debugging the refactor. A few months pass by and the whole code base will forcefully have to be refactored again to be merged into another code base. He was looking further into making a clean code base, but I was looking further into saving our clients a few thousand bucks and delivering early. Which one was right? I’ll reflect on that after this new refactor and see how much the previous one helps (or doesn’t).

virgilp 2y ago

> Just stating, 'don't look further than the problem you are required to solve' is not an excellent general rule. It's still pretty good though; I think the only better formulation is "only implement a general solution if it's _simpler_ than the particular/specialized solution". Sometimes, that is indeed the case - but it's pretty rare. So if you want to keep things simple, "don't generalize until you have 3 examples" is a pretty solid rule-of-thumb.

psychoslave 2y ago
But the main issue with that kind of remarks is that we are not omniscient demiurges. If we don’t try to implement two approaches, then we won’t be able to judge based on actual facts and metrics. If we already did that in the past often enough, sure we can gain some intuition on what will be the actual outcomes of the tradeoff we retain. But paying the price to build such an expertise is also a tradeoff. In particular we might desire to provide the most sound and solid solution from a grand master quality level. But if the whole market is already in the hand of a few players that went with the old card of "occupy the territory first and (possibly) consider quality later", our grandiose art will be also a path to starvation.
- virgilp 2y ago
  > our grandiose art will be also a path to starvation. That's what I'm saying, that in general the "grandiose art" _is_ a path to starvation, in a lot of business software at least. Because the actual (eventual) requirements are often unknowable at the start, and the initial assumptions are often invalid/false. So if you build your grandiose architecture based on wrong initial assumptions, it'll still lead to a subpar product even if the architecture was perfectly correct (given said assumptions). It's better to approach it with the idea that you're not writing code that needs to run 1 more than e.g. 1 year (but, you ARE writing code that you might need to maintain next year! that's a subtle but important difference. You write code to move fast now - not to enable you to move fast 1 year later; BUT, at the same time you write code that won't slow you down horrendously, in case you can no longer delete it 1 year later).
vrighter 2y ago

DrScientist 2y ago

It think it's essential to understand the problem you are trying to solve - however often that problem is how to do something better in the specialised case than the current tools that support the general case. ie why is anybody writing any new software these days when Powerpoint, Excel and Word cover all the use cases in the general case? ( I exaggerate for effect ).

ergonaught 2y ago

Trying to solve a generalized problem in response to advice to refrain from prematurely generalizing solutions. 10/10.