4 ms·

I've managed developers for the same software product (accounting system) over the last 15+ years. That amount of time gives you some perspective. A common thi

by _red 9y ago

I've managed developers for the same software product (accounting system) over the last 15+ years. That amount of time gives you some perspective. A common thing that new hire developers do is call for "a complete rewrite", they do this because when they first approach a large old code base, its daunting and seems impenetrable. Of course they are right, but naive in thinking a "rewrite" will help. Any new rewrite will eventually just grow to be just as impenetrable once all features and edge-cases are accounted for. Fundamentally, any software product is trying to model some aspect of the real world...and the real world is messy, very messy. Governments pass laws that contradict each other, some laws change drastically state by state, employees try new and novel ways to embezzle, different languages and units of measure exist, changing prices for commodities can suddenly cause complete upheavals in manufacturing process, etc. All this must try to be accounted for and its nearly an impossible task. The bugs that persist are almost never "I click Button A and it does the wrong thing", but almost always "In case that Situation A + B + C all simultaneously exist, the result as interpreted by Agency X is not optimal". Obvious and real bugs get squashed pretty quickly, but those complex situational bugs can linger for a long time. As a manager, you sometimes just need to shrug, because the effort required to fix each and everyone of these would produce little to no tangible business value. Moreover, an environmental change could come along to render your "fix" invalid anyways. Sometimes even during design discussions we are completely aware we are creating "a bug", but the decision is made that the amount of people that want both Feature A and where Situation B exist will produce relatively little overlap. Most often we just design a manual workaround, instead of trying to completely eliminate the bug. I'm always refreshed and excited by dealing with young devs, particularly for their zeal to fix problems, simplify things, and generally improve the product. Yet, I do feel a bit of sadness in that I know reality is going to temper their enthusiasm after a decade or so. Reality is a very hard thing to model with any semblance of being "bug-free".

zimpenfish 9y ago
> once all features and edge-cases are accounted for. But one of the benefits of a rewrite is that you can dump all the features and edge-cases that are no longer required. Or fold old edge-cases into new generalities because the business has changed since then. > the real world is messy, very messy. Cannot disagree -but- it's nowhere near as messy as the people (often those who are to blame) defending the byzantine software stacks using that argument. > reality is going to temper their enthusiasm after a decade or so. I've been doing this professionally for two decades and my enthusiasm for "chuck it away and do it right" hasn't waned one bit.
- carlmr 9y ago
  >> reality is going to temper their enthusiasm after a decade or so. >I've been doing this professionally for two decades and my enthusiasm for "chuck it away and do it right" hasn't waned one bit. I think it's probably somewhere in between the two extremes. I think you should have good unit tests and then refactor parts of your code where you see better generalities, or where basic code cleanliness was disregarded before. But throwing all of it away is rarely possible without endangering the profitability of the company for a while.
  - zimpenfish 9y ago
    > throwing all of it away is rarely possible without endangering the profitability of the company Well, obviously I don't mean "turn it off and wait for the new system to be finished". You build the new one whilst the old one is in maintenance mode and swap in new bits as and when you can. For example, at current $WORK, the backoffice system is a horror show of overcomplex PHP that is riddled with bugs and no-one really understands how it all works. Replacing that would be a huge boon both humanly and monetarily to the company because CS use it heavily every day.
    - dragonwriter 9y ago
      > You build the new one whilst the old one is in maintenance mode and swap in new bits as and when you can. Continuous incremental improvement of a production system may, over time, have the same net effect as a an idealized big-bang replacement, but it's a very different process (it's usually what people who are saying you should never do a ground-up replacement prefer instead, because actual big-bang replacements, unlike idealized ones, are usually a shitstorm: and the reason is that they are usually done to the kind of systems you describe, overcomplicated key systems with inadequate documentation or institutional memory, and they are done instead of trying to get a firm grasp on each component of the existing system before replacing that component. And so they end up, at best, being exceedingly well designed, but overlooking key elements of business function discovered and implemented, but not durably documented, in the original system.)
- 9y ago
jaclaz 9y ago
>I've managed developers for the same software product (accounting system) over the last 15+ years. You will probably appreciate this little piece of anecdata, last July there was an update change in some fiscal Laws in Italy, so that a number of firms had to make a certain payment of taxes within the 31st of July, BUT the change was communicated/published almost "last minute" (as often happens) and a software house had to update their accounting program in a very strict time. The payment code (on the government side) was the same of another payment (already known to be due on the 31/07/2017) so the programmers, in order to distinguish the two payments "anticipated" (virtually) the date on the database, so that two payments were resulting, one on the 30th and one on 31st. This (intentionally) "queer" behaviour was not explained (or not explained well enough) to the users. Most users "trusted" the program and everything went well for them, those that noticed the anomaly managed to "force" both payments on the same date, and this resulted in a "single" payment (instead of the two separate ones required), thus messing up the whole thing.
- njarboe 9y ago
  This is the future of learned helplessness. People that see problems and inconsistencies in software systems and try to work around them will have worse outcomes than those that just blindly follow the workflow assigned to them. Seems like one needs to be controlling the spec and writing the code not to get stuck in this trap.
  - jaclaz 9y ago
    >People that see problems and inconsistencies in software systems and try to work around them will have worse outcomes than those that just blindly follow the workflow assigned to them. Well, not always. That applies ONLY to those that find such problems or inconsistencies and workaround them in an incorrect manner. And this brings us back right to Chesterton's fence: https://en.wikipedia.org/wiki/Wikipedia:Chesterton's_fence https://en.wikipedia.org/wiki/Wikipedia:Chesterton's_fence that can be invoked both when users do silly things, but also when programmers do them.
    - carlmr 9y ago

by _red 9y ago

zimpenfish 9y ago

> once all features and edge-cases are accounted for. But one of the benefits of a rewrite is that you can dump all the features and edge-cases that are no longer required. Or fold old edge-cases into new generalities because the business has changed since then. > the real world is messy, very messy. Cannot disagree -but- it's nowhere near as messy as the people (often those who are to blame) defending the byzantine software stacks using that argument. > reality is going to temper their enthusiasm after a decade or so. I've been doing this professionally for two decades and my enthusiasm for "chuck it away and do it right" hasn't waned one bit.

carlmr 9y ago
>> reality is going to temper their enthusiasm after a decade or so. >I've been doing this professionally for two decades and my enthusiasm for "chuck it away and do it right" hasn't waned one bit. I think it's probably somewhere in between the two extremes. I think you should have good unit tests and then refactor parts of your code where you see better generalities, or where basic code cleanliness was disregarded before. But throwing all of it away is rarely possible without endangering the profitability of the company for a while.
- zimpenfish 9y ago
  > throwing all of it away is rarely possible without endangering the profitability of the company Well, obviously I don't mean "turn it off and wait for the new system to be finished". You build the new one whilst the old one is in maintenance mode and swap in new bits as and when you can. For example, at current $WORK, the backoffice system is a horror show of overcomplex PHP that is riddled with bugs and no-one really understands how it all works. Replacing that would be a huge boon both humanly and monetarily to the company because CS use it heavily every day.
  - dragonwriter 9y ago
    > You build the new one whilst the old one is in maintenance mode and swap in new bits as and when you can. Continuous incremental improvement of a production system may, over time, have the same net effect as a an idealized big-bang replacement, but it's a very different process (it's usually what people who are saying you should never do a ground-up replacement prefer instead, because actual big-bang replacements, unlike idealized ones, are usually a shitstorm: and the reason is that they are usually done to the kind of systems you describe, overcomplicated key systems with inadequate documentation or institutional memory, and they are done instead of trying to get a firm grasp on each component of the existing system before replacing that component. And so they end up, at best, being exceedingly well designed, but overlooking key elements of business function discovered and implemented, but not durably documented, in the original system.)
9y ago

jaclaz 9y ago

>I've managed developers for the same software product (accounting system) over the last 15+ years. You will probably appreciate this little piece of anecdata, last July there was an update change in some fiscal Laws in Italy, so that a number of firms had to make a certain payment of taxes within the 31st of July, BUT the change was communicated/published almost "last minute" (as often happens) and a software house had to update their accounting program in a very strict time. The payment code (on the government side) was the same of another payment (already known to be due on the 31/07/2017) so the programmers, in order to distinguish the two payments "anticipated" (virtually) the date on the database, so that two payments were resulting, one on the 30th and one on 31st. This (intentionally) "queer" behaviour was not explained (or not explained well enough) to the users. Most users "trusted" the program and everything went well for them, those that noticed the anomaly managed to "force" both payments on the same date, and this resulted in a "single" payment (instead of the two separate ones required), thus messing up the whole thing.

njarboe 9y ago
This is the future of learned helplessness. People that see problems and inconsistencies in software systems and try to work around them will have worse outcomes than those that just blindly follow the workflow assigned to them. Seems like one needs to be controlling the spec and writing the code not to get stuck in this trap.
- jaclaz 9y ago
  >People that see problems and inconsistencies in software systems and try to work around them will have worse outcomes than those that just blindly follow the workflow assigned to them. Well, not always. That applies ONLY to those that find such problems or inconsistencies and workaround them in an incorrect manner. And this brings us back right to Chesterton's fence: https://en.wikipedia.org/wiki/Wikipedia:Chesterton's_fence https://en.wikipedia.org/wiki/Wikipedia:Chesterton's_fence that can be invoked both when users do silly things, but also when programmers do them.
  - carlmr 9y ago