[HN Gopher] Solve software problems by adding more
___________________________________________________________________
Solve software problems by adding more
Author : dilumn
Score : 48 points
Date : 2021-06-26 06:43 UTC (16 hours ago)
(HTM) web link (dilumn.github.io)
(TXT) w3m dump (dilumn.github.io)
| cutler wrote:
| Composable immutable languages like Clojure can reduce this kind
| of burden.
| noir_lord wrote:
| 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.
| xupybd wrote:
| 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.
| gonzo41 wrote:
| It's always worth rereading business cases for old software to
| see if the picture in the business case holds up to reality.
|
| It's difficult to convey the idea of "don't solve problems
| dissolve them" when features always seem like the right answer.
| philipov wrote:
| 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...
| heisenbit wrote:
| 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.
| aszen wrote:
| 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.
| AvocadoCake wrote:
| 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.
| sega_sai wrote:
| 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.
___________________________________________________________________
(page generated 2021-06-26 23:02 UTC)