5 ms·

I used to work at a company with two database fields, speed_kmph. The documentation read "speed_kmph - This field contains the travelling speed in MILES PER HO

• quickthrower2 5y ago
  DB field names can be really hard to change. All those crystal reports to update, and the sales managers pet access DB that the hero set up for him that you don’t know about.
  • tonyedgecombe 5y ago
    >DB field names can be really hard to change. I find it really hard to accept any excuse for something like that. It's why enterprise code is so sloppy, people doing the most expedient thing rather than what is correct.
    • cle 5y ago
      What is "correct" is up for debate, and often depends on cost tradeoffs. Sometimes this is the "correct" thing to do, no matter how gross we think it is.
      • tonyedgecombe 5y ago
        Not often, what has always surprised me is how regularly these sort of problems are self inflicted. A lot of people will just do what is expedient regardless of what the management position is.
    • Closi 5y ago
      How do you write code so that it can accommodate DB field name changes without breaking SQL reports / BI? Might be easy if you own the whole codebase and all reporting, but you are also going to break all those linked BI reports that the analysis team has written.
      • pojzon 5y ago
        Most often those reports are built on top of table views and not direct table contents. If you have an abstraction layer between its not hard to change whats under. But that makes an assumption you didnt make any shortcuts.
        • Closi 5y ago
          Considering I was actually consuming the data, if there was an abstraction layer then the field name was in that.
      • Too 5y ago
        Breaking the report is a feature. If you don’t, it will assume kmph instead of mph and just present the wrong data! But sure…those graphs still look pretty…
        • Closi 5y ago
          Which links back to the original point from quickthrower that database field name changes are really hard to change then. If you can’t make a change without it potentially breaking other stuff, it goes in the “not easy” category for me. Especially if you probably won’t know if stuff is broken until the change is pushed to prod.
      • im3w1l 5y ago
        Create a new column speed_mph. Create a trigger that makes writes to either column gets written to both (make sure to write it to avoid infinite recursion). Copy all data from speed_kmph to speed_mph. Deprecate speed_kmph. Change existing usages at your leisure. Delete speed_kmph.
        • Closi 5y ago
          Fair enough, although sounds like it’s really hard to change then back to quickthrowers point.
        • gilcot 5y ago
• gpderetta 5y ago
  recently I was looking at some pcap parsing code which was storing the timestamp field into a timeval structure (that nominally has usec precision), but then treating it as nanoseconds (as pcap supports both resolution). It made for some very confusing reads!
• bombcar 5y ago
  This is why it's dangerous to encode the unit in the variable, because it will eventually change (we had code that was measured in seconds and had to be changed to measure in 20/ths of a second for more granularity, if the timer variable had been named "timer_seconds" it would have had to be changed everywhere.
  • hallway_monitor 5y ago
    In this specific case, it seems like creating a new property with the new data in a new name would be the safest path forward. Ensuring the unit are in both property names will prevent confusion.
  • RandallBrown 5y ago
    If you change the unit, I think the variable should be changed everywhere. It's hard to know what assumptions code is making and by forcing you to change the code everywhere (which should be pretty easy in any modern IDE) you at least have a chance to evaluate any issues that unit change could cause.
  • llbeansandrice 5y ago
    This sounds like a feature to me and modern IDEs make this type of simple refactoring quite straight forward for most languages.
  • andrewzah 5y ago
    Someone doing a half-assed refactor doesn't mean it's "dangerous" to encode a unit in a variable or function. I do agree that generally it's better to use something like a struct that's more flexible, but doing that for every function is also quite verbose. For some functions the time requirement may never change as well.
• jrodthree24 5y ago
  It's even better when the documentation gets stale too. And now this is in meters/second but the name implies km and docs specify miles.