5 ms·

I’m certainly familiar with systems growing over time and outgrowing their original schema. Is this the same phenomenon that resulted in Cloudflare Tunnels app

by amluto 2y ago

I’m certainly familiar with systems growing over time and outgrowing their original schema. Is this the same phenomenon that resulted in Cloudflare Tunnels apparently being domain names? Or why domains that are proxied by Cloudflare show up as “CNAME” in the DNS panel? (The latter one seems extra strange — wasn’t the reverse proxy service the very first service that Cloudflare offered? There must be some history here.)

hinkley 2y ago
All new products are full of scaffolding that has to be removed when robustness becomes a higher priority than existence. Where we fail is not calling it that. Instead we just call some code “good” while our thicker skinned coworkers call the rest “fine”. It’s not fine. I don’t want to be working overtime the week of thanksgiving because you can’t think past the horizon.
- deleted 2y ago
  [deleted]
- gmueckl 2y ago
  There is a very fine line between "good enough" and "not good enough" in any product beyond a certain complexity. Finding the pieces that cross that line can be hard and improving "good enough" parts is (sadly) mostly a waste of time in commercial settings.
  - hinkley 2y ago
    You have to backdate starting a project so it happens before things stop being good enough. And take into account bad estimates and the five other deadlines between then and now. Often it’s better to clean as you go. If you have the time and the inclination, shore up one of the least good enough things. It’s not unheard of to open up new feature sets via refactoring. Something that previously would have taken an “impossible” amount of time now becomes profitable, not just possible.
    - dmorgan81 2y ago
      I miss working at a place where that was encouraged. Now if I do that the testers complain that it’s not in scope for the ticket and to split the changes into another ticket with a separate test plan. The rot thus continues.
      - hinkley 2y ago
        I think this is about when I discovered zone defense for performance optimization. QA doesn’t want to chase your code changes halfway across the codebase, and that’s fair. At some point it starts looking like you’re changing things just to change them, even if it ends up being a few percent better. But if you limit yourself to one part of the interaction, they don’t get as mad. A dozen changes in the signup system piss them off less than five changes across the app.
  - didgetmaster 2y ago
    This is why some bugs never get fixed (that is if you define a bug to include inefficient code and not just code that breaks something).

by amluto 2y ago

hinkley 2y ago

All new products are full of scaffolding that has to be removed when robustness becomes a higher priority than existence. Where we fail is not calling it that. Instead we just call some code “good” while our thicker skinned coworkers call the rest “fine”. It’s not fine. I don’t want to be working overtime the week of thanksgiving because you can’t think past the horizon.

deleted 2y ago
[deleted]
gmueckl 2y ago
There is a very fine line between "good enough" and "not good enough" in any product beyond a certain complexity. Finding the pieces that cross that line can be hard and improving "good enough" parts is (sadly) mostly a waste of time in commercial settings.
- hinkley 2y ago
  You have to backdate starting a project so it happens before things stop being good enough. And take into account bad estimates and the five other deadlines between then and now. Often it’s better to clean as you go. If you have the time and the inclination, shore up one of the least good enough things. It’s not unheard of to open up new feature sets via refactoring. Something that previously would have taken an “impossible” amount of time now becomes profitable, not just possible.
  - dmorgan81 2y ago
    I miss working at a place where that was encouraged. Now if I do that the testers complain that it’s not in scope for the ticket and to split the changes into another ticket with a separate test plan. The rot thus continues.
    - hinkley 2y ago
      I think this is about when I discovered zone defense for performance optimization. QA doesn’t want to chase your code changes halfway across the codebase, and that’s fair. At some point it starts looking like you’re changing things just to change them, even if it ends up being a few percent better. But if you limit yourself to one part of the interaction, they don’t get as mad. A dozen changes in the signup system piss them off less than five changes across the app.
- didgetmaster 2y ago
  This is why some bugs never get fixed (that is if you define a bug to include inefficient code and not just code that breaks something).