4 ms·

People tend to add elements to solve a problem rather than take things away

mlazos 5y ago
The cognitive load result is interesting and might explain why technical debt is such a problem in our industry. I’m thinking that it might also be easier to simply add to an existing structure rather than understand the entire thing to realize where you can subtract.
- nightowl_games 5y ago
  It can be easier to delete the whole thing and add to zero rather than to parse the existing structure in order to subtract from it.
aparsons 5y ago
I could never quite put my finger on it - but some of the best programmers I’ve worked with illustrated this. They seemed equally open to simplifying systems as towards extending them. Not “time for this week’s rewrite” kind, but they weren’t afraid of “losing” all or part of what had already been built.
karmakaze 5y ago
In an arbitrary structure if a if b ... else ... end else case c ... when y ... when z ... else ... end end Rather than understand how everything works and literally 'factor' out a new aspect, any structure can, without understanding, be incrementally be amended by changing all the relevant leaves with additional, duplicated substructures. Of course it looks clear and obvious here, but usually the structure is distributed across many classes, methods, and strategy patterns, etc. The 'factoring' work that needs to be continually done is at a higher conceptual level rather than the mindless 'deduplicating' refactorings that tend to get done.
jgjot-singh 5y ago
This is surprisingly relevant to audio engineering, where amateurs tend to layer too many sounds and end up with a "muddy" mix, and pros are very good at selectively removing elements/frequencies to make the rest of the sounds extremely clear and coherent
perl4ever 5y ago
I have a two step process for building a software system; I haven't got to the second step in practice, but some day... Step 1: Build a proverbial "ball of mud", adding things left and right until all the shifting requirements are met. Step 2: Write a minimal description of all the logic from scratch, by surveying the existing code, and then, essentially, write an interpreter for it. If I got to step 2, and did a good job, future projects would become much easier.

The cognitive load result is interesting and might explain why technical debt is such a problem in our industry. I’m thinking that it might also be easier to simply add to an existing structure rather than understand the entire thing to realize where you can subtract.

nightowl_games 5y ago
It can be easier to delete the whole thing and add to zero rather than to parse the existing structure in order to subtract from it.

aparsons 5y ago

I could never quite put my finger on it - but some of the best programmers I’ve worked with illustrated this. They seemed equally open to simplifying systems as towards extending them. Not “time for this week’s rewrite” kind, but they weren’t afraid of “losing” all or part of what had already been built.

karmakaze 5y ago

In an arbitrary structure if a if b ... else ... end else case c ... when y ... when z ... else ... end end Rather than understand how everything works and literally 'factor' out a new aspect, any structure can, without understanding, be incrementally be amended by changing all the relevant leaves with additional, duplicated substructures. Of course it looks clear and obvious here, but usually the structure is distributed across many classes, methods, and strategy patterns, etc. The 'factoring' work that needs to be continually done is at a higher conceptual level rather than the mindless 'deduplicating' refactorings that tend to get done.

jgjot-singh 5y ago

This is surprisingly relevant to audio engineering, where amateurs tend to layer too many sounds and end up with a "muddy" mix, and pros are very good at selectively removing elements/frequencies to make the rest of the sounds extremely clear and coherent

perl4ever 5y ago

I have a two step process for building a software system; I haven't got to the second step in practice, but some day... Step 1: Build a proverbial "ball of mud", adding things left and right until all the shifting requirements are met. Step 2: Write a minimal description of all the logic from scratch, by surveying the existing code, and then, essentially, write an interpreter for it. If I got to step 2, and did a good job, future projects would become much easier.