I've started to experience this going from an external consultant to an internal solo developer. We have removed so many bugs by removing complexity in the business. There were unmaintainable messes everywhere. I used to think the code was the problem. The real problem was the business had grown organically and the processes were inconsistent and complex. Simplifying them meant we could remove entire systems. Edge cases have been removed and all the code that handled them.
Whenever I make a PR for a bug fix or a change in behaviour, I'll check the LOC delta. Given all I'm doing is changing an existing thing, rather than adding a new feature, I would often consider it a soft red flag if the LOC has increased substantially. Now, obviously sometimes I'll stop and think about why it went up and decide that it's inevitable, but sometimes it will help me realise I wasn't properly utilising code/logic that already existed in that service. I might not be able to have low-code/no-code, but I can attempt to avoid high-code whenever possible.
ninety-nine little bugs in the code.
ninety-nine little bugs in the code.
take one down, patch it around.
one-hundred twenty-seven little bugs in the code...
Analyzing what impact removing a piece of software has is typically harder than thinking about what my addition does. This is especially true for libraries where it is hard to know exactly where and why something may have been used. Removal might require significant re-testing while addition may allow to get away with targeted testing. Cleaning up code may be the right thing to do if one knows what one is doing but some system are too big of complex that you can only pray you know what you are doing.
what kind of language are u using, using a statically typed functional language most removal of code is self obvious and even automated. u remove a method, it tells u to remove this and this too.
I always consider if a bug is a result of the wrong level of abstraction first before fixing it.
In "A Philosophy of Software Design" Ousterhout talks about the difference between tactical and strategic programming (great book mostly because it codifies a lot of what I think is the "One True Way" so I'm biased) and it's really easy to bang out a fix for variant 98 of the bug vs rethinking it so variants 0 through 97 which haven't been reported yet but exist can't happen.
I think the problem is that the complexity analysis of adding is often easier, as opposed to subtracting. I.e. if I added an if statement, one can argue that you may need to only analyse that statement, while removing a bit of code may require analysing a much larger chunk of code. (it's obviously a simplification).
Adding is often a local solution, while subtracting can be a global. Since we all work under some time or cognitive pressures, it's not surprising that the additive solutions are used, where other ones would be better.
10 comments
[ 2.0 ms ] story [ 39.1 ms ] threadIt's difficult to convey the idea of "don't solve problems dissolve them" when features always seem like the right answer.
In "A Philosophy of Software Design" Ousterhout talks about the difference between tactical and strategic programming (great book mostly because it codifies a lot of what I think is the "One True Way" so I'm biased) and it's really easy to bang out a fix for variant 98 of the bug vs rethinking it so variants 0 through 97 which haven't been reported yet but exist can't happen.