3 ms·

It reminds me of all the naive engineers that look at a complex codebase, don't fully grok it, and say "this is a mess, it needs a rewrite!". They then find ou

It reminds me of all the naive engineers that look at a complex codebase, don't fully grok it, and say "this is a mess, it needs a rewrite!". They then find out that every complex rule had a reason for existing. The rewrite takes time and resources to reimplement. As they go they hit snag after snag and add a specific business rule for that only to find out that they are just recreating the original "too complex and inefficient" codebase with a whole lot of effort and money wasted.

lwansbrough 2y ago
We're basically paying the government per line of code written currently. Ask Microsoft how that turned out.
- daveguy 2y ago
  What do you mean by that? Is that how doge is working? No one in the government has previously been paid per line of code. Am I missing something here?
  - lwansbrough 2y ago
    It's a metaphor for how we pay for the evolving and deepening complexity of government, without any effort being put into processes that might help eliminate complexity -- because there's no real accountability for spending. I think "DOGE" is conceptually a good idea, and if it were executed by a competent administration could lead to great outcomes, as was the case with the USDS.
    - aqueueaqueue 2y ago
      Trump could have put someone good on it, but he prefers loyalty over competence.
    - daveguy 2y ago
      Well yeah, government efficiency is obviously a "great idea", but that is ridiculously simplistic. No one is paid for "great ideas" without any clue how to execute. Poorly implemented good ideas screw things up just as bad as bad ideas. Maybe worse. If it's a good idea, implemented poorly, you have a lot of cheerleaders worshipping the idea. But if it's a bad idea, at least you have people offering alternative ideas.
rjbwork 2y ago
While true, a lot of the time the problem is organization. Complexity exists and our job as engineers is to wrestle with it and organize it into a grokkable whole. Something being messy and needing a rewrite or significant refactor is often down to inexperience of initial implementers or too-short timelines causing entropy explosion rather than taking the time to build structure for arranging and organizing the complexity.
phito 2y ago
There's also the many cases where the code is an actual mess because it had unclear requirements during its whole development, or it was written by someone who doesn't fully grasp the language they're using. I've rewritten several of such projects, successfully reduced complexity and improved performances just by knowing what I am doing.
- magicalhippo 2y ago
  > knowing what I am doing This code is a mess, I don't understand what it's doing is very different from I get what it's doing but this code is a mess. The first should probably be a strong sign you should not start rewriting the code, while the second can be a decent position to consider rewriting it.
  - MereInterest 2y ago
    I think I’d distinguish between rewrites and refactors. A rewrite starts from a blank slate, where a refactor starts from the previous version. Being unable to understand the code in its entirety does not mean that somebody is unable to understand pieces of the code. Refactoring those pieces into easier-to-understand portions can be done, even when the end-to-end flow is still being contemplated.
    - magicalhippo 2y ago
      > Refactoring those pieces into easier-to-understand portions can be done Right, but the main point still stands I think, that if you don't understand the full code, you run a risk at introducing bugs when refactoring portions of it. Code that seemingly does nothing might in fact do something due to non-local effects, ie global variables in disguise, and other pitfalls. A "favorite" is using reflection to modify some non-local variable rather than accessing it directly, making it very difficult to find during code searches. Sometimes these bugs can be glaring, other times they can be more subtle and only be detected once they've inflicted significant damage to customer data.
- wrsh07 2y ago
godelski 2y ago
I don't think this is a great analogy. While it can be true I'm not sure it even usually is. A lot of complexity in a codebase comes from the fact that the end goal isn't specified from the start. In fact, it really can't be. The code evolves along the way, goals change, the hardware changes, dependencies change, and patches turn into solutions. This isn't to say that everything along the way didn't have a good reason, in fact it most certainly did! But a good codebase is also constantly rewritten. There should never be shame in this because the goals changed. There are unknown unknowns that can't be avoided. But you need to constantly profile, fix, and rewrite. There is no end as long as time marches on.

lwansbrough 2y ago

We're basically paying the government per line of code written currently. Ask Microsoft how that turned out.

daveguy 2y ago
What do you mean by that? Is that how doge is working? No one in the government has previously been paid per line of code. Am I missing something here?
- lwansbrough 2y ago
  It's a metaphor for how we pay for the evolving and deepening complexity of government, without any effort being put into processes that might help eliminate complexity -- because there's no real accountability for spending. I think "DOGE" is conceptually a good idea, and if it were executed by a competent administration could lead to great outcomes, as was the case with the USDS.
  - aqueueaqueue 2y ago
    Trump could have put someone good on it, but he prefers loyalty over competence.
  - daveguy 2y ago
    Well yeah, government efficiency is obviously a "great idea", but that is ridiculously simplistic. No one is paid for "great ideas" without any clue how to execute. Poorly implemented good ideas screw things up just as bad as bad ideas. Maybe worse. If it's a good idea, implemented poorly, you have a lot of cheerleaders worshipping the idea. But if it's a bad idea, at least you have people offering alternative ideas.

rjbwork 2y ago

While true, a lot of the time the problem is organization. Complexity exists and our job as engineers is to wrestle with it and organize it into a grokkable whole. Something being messy and needing a rewrite or significant refactor is often down to inexperience of initial implementers or too-short timelines causing entropy explosion rather than taking the time to build structure for arranging and organizing the complexity.

phito 2y ago

There's also the many cases where the code is an actual mess because it had unclear requirements during its whole development, or it was written by someone who doesn't fully grasp the language they're using. I've rewritten several of such projects, successfully reduced complexity and improved performances just by knowing what I am doing.

magicalhippo 2y ago
> knowing what I am doing This code is a mess, I don't understand what it's doing is very different from I get what it's doing but this code is a mess. The first should probably be a strong sign you should not start rewriting the code, while the second can be a decent position to consider rewriting it.
- MereInterest 2y ago
  I think I’d distinguish between rewrites and refactors. A rewrite starts from a blank slate, where a refactor starts from the previous version. Being unable to understand the code in its entirety does not mean that somebody is unable to understand pieces of the code. Refactoring those pieces into easier-to-understand portions can be done, even when the end-to-end flow is still being contemplated.
  - magicalhippo 2y ago
    > Refactoring those pieces into easier-to-understand portions can be done Right, but the main point still stands I think, that if you don't understand the full code, you run a risk at introducing bugs when refactoring portions of it. Code that seemingly does nothing might in fact do something due to non-local effects, ie global variables in disguise, and other pitfalls. A "favorite" is using reflection to modify some non-local variable rather than accessing it directly, making it very difficult to find during code searches. Sometimes these bugs can be glaring, other times they can be more subtle and only be detected once they've inflicted significant damage to customer data.
wrsh07 2y ago

godelski 2y ago

I don't think this is a great analogy. While it can be true I'm not sure it even usually is. A lot of complexity in a codebase comes from the fact that the end goal isn't specified from the start. In fact, it really can't be. The code evolves along the way, goals change, the hardware changes, dependencies change, and patches turn into solutions. This isn't to say that everything along the way didn't have a good reason, in fact it most certainly did! But a good codebase is also constantly rewritten. There should never be shame in this because the goals changed. There are unknown unknowns that can't be avoided. But you need to constantly profile, fix, and rewrite. There is no end as long as time marches on.