• King (unregistered)

    Wow, I wonder what kind of budget that can not cover this fix?

  • Edd (unregistered)

    No easy reader version, skipped

  • m (unregistered) in reply to King

    You know how it goes. When 10 people meet up for an hour to discuss the story points of a ticket that's done and tested in 15 minutes...

  • pudin9 (unregistered)

    "there is no budget for making this kind of change"

    It's literally a one-line fix, zero budget needed. Writing the e-mail for complaining about it costs much more than fixing it.

  • gnasher729 (unregistered)

    Swift does have a class named Data. Which handles plain data as a sequence of bytes. Kind of like an object oriented malloc / free / realloc. And has nothing whatsoever to do with dates.

  • DQ (unregistered) in reply to pudin9

    But writing the e-mail is another budget, so that's not a problem :)

  • (nodebb)

    This makes me want to say Black Codes Matter, except this isn't a race condition. It's a boundary condition, but one with blatantly obvious and frequent boundaries.

  • Brian (unregistered) in reply to King

    The kind of budget that's used as a wall to maintain the status quo rather than an enabler to make the product better. Usually one tied to a Process that requires at least a week of overhead for any kind of change, no matter how trivial, in the name of minimizing risk.

  • Pedro (unregistered)

    "data" is portuguese for "date". So perhaps this class started with only date-related methods such as that "now()".

  • Ryan (unregistered)

    The Budget is probably related to the whole regression and UAT testing that their policy requires for any code change, especially when there is not enough UT coverage.

  • (nodebb) in reply to gnasher729

    Sooooo… a Buffer?

  • (nodebb)

    During code review for another bug... :reviewer: What's this change in the data class for? :me: It was one of the causes of <bug>, so I fixed it.

  • The Data Coder (unregistered)

    This is one of those things you fix first and ask forgiveness for later. There is somehow never budget to do these kind of 15 minute fixes and sometimes you just need to subvert the process and do it anyway.

  • ooOOooGa (unregistered) in reply to Brian

    Yeah. This.

    I have also worked at a place where this was the attitude. Writing the fix isn't where the cost is. It is in testing it to minimize the risk.

    No matter that the entire code base is going to be tested before release anyway. Nope, you aren't allowed to make any changes that aren't part of an approved, planned, budgeted change request. It is too costly to test.

  • WTFGuy (unregistered)

    A fragile codebase is littered with errors. A weak manager is much more afraid of adding one error than of removing 30. So you erect an impossibly high correctness barrier to new changes and simply shrug your shoulders at the old errors, both known and unknown. Selectively of course since you're not applying the same high correctness barriers to what new greenfield work you have; unit testing is too hard & entails too much retraining.

    Said another way, if enough of the bizidjits are devoted to the idea that the current outputs, however erroneous, represent ground truth, then indeed 30 wrongs are better than 1 right.

    We saw that just yesterday on the Big Spreadsheet. And we've seen it here again and again.

    Its near universality doesn't make me shake my head any less. It just makes me want to drink a little more.

  • JJJJJJJJ (unregistered)

    I mean....everything would be fixed with DateTimeImmutable......

  • Calli Arcale (unregistered) in reply to The Data Coder

    I was told there's no budget for things like this in a system I maintain (at least not right now) but I've been slipping a few in anyway when there's a bigger change to be made that is paid for by a different budget. ;-) I keep a log of quick fixes to slip in like that, so the changes do all get properly documented, and so I can just go in and do them when needed.

  • COB (unregistered)

    This is where you just fix the code without telling anybody so it's no longer a budget issue.

  • sizer99 (google)

    I am extremely surprised to hear that all four copies of the now() function actually contain the same code. Usually at least ONE of them has had some hacks applied to it and only it (more usually, all four have had different hacks applied) so they all have the same name but do different things. I guess they didn't have the budget for that.

  • Foo AKA Fooo (unregistered) in reply to WTFGuy

    I think this is much more to blame for the sad state of software engineering today than all those cowboy coders who shoot bugs on sight, even if causing some collateral damage. But in the long run, accumulating cruft hurts much more.

    https://xkcd.com/1172/

  • Just Me (unregistered)

    I was thinking "Data" was just "Date" in another language due to the now function.

  • (nodebb) in reply to pudin9
    It's literally a one-line fix, zero budget needed.
    Bu t but but. Agile!! Scrum!!!! Sprints!!!!!! Here, we are required to created a sub- task ticket for everything, and fill in all the details, and then after doing the work, go back and mark the time spent, the outcome, ... and so on. I've taken to writing down "estimated labor effort: 35 nanoseconds" . Management is of course totally convinced that all this tracking stuff is making our company GREAT.
  • Appalled (unregistered)

    I'm going to guess it was converted from a prior implementation, perhaps ColdFusion or something similar, and they simply made the exact same logic work in PHP, i.e. a custom set of functions was turned into a class, although I would have used a PHP Include for performance.

  • (nodebb)

    Regarding "budget to fix".... How many places is this called from?, what are all of the use-cases that involve this code? If testing is manual (an assumption, but usually a good one) then this could involve days of testing.

  • Patrick (unregistered)

    @sizer99 this was exactly my thought; as long as there are four exact same copies, you can call yourself lucky. Usually when there are more copies, they are off by a bit

  • Realworld (unregistered) in reply to TheCPUWizard

    Exactly, all the devs saying this is a 15 minute fix, or "I just like to slip things like this in and just fix it in secret; I know better " are the same ones that end up creating regression defects in production because nobody is testing their changes. I get that there is ALREADY a theoretical bug here that probably deserves to be fixed, but to think that it is a ridiculous position to weigh the risks vs benefits is just juvenile.

  • Jinks (unregistered) in reply to King

    @king: "Wow, I wonder what kind of budget that can not cover this fix?"

    You have to remember that every fix needs a meeting to plan it, a code review meeting, documentation, and a test deployment before it can move to a production environment.

    Five minutes of coding easily turns into hundreds of man-hours of work.

  • The Data Coder (unregistered)

    all the devs saying this is a 15 minute fix, or "I just like to slip things like this in and just fix it in secret; I know better " are the same ones that end up creating regression defects in production because nobody is testing their changes

    Possibly, if the system isn't properly tested (another thing that budgets don't seem to cover), but the extra time to fix that regression when it occasionally occurs is going to be a lot less than the time saved by not having a crap code base. And there's the developers' morale to consider as well.

  • (nodebb) in reply to WTFGuy

    A weak manager is much more afraid of adding one error than of removing 30.

    Not exactly. He's afraid of adding one big huge enormous (but rarely-occurring) error when removing 30 tiny oddities that can be triggered once a day if you're unlucky.

    This debate reminds me of a bug that a colleague was investigating many years ago. Most of the details aren't important, except the critical one. There was a window three machine instructions long that if it aligned with this thing issuing an interrupt, the bug would (100% guaranteed) happen. I found it by blind chance, and described it to him. He pooh-poohed it as totally unlikely. The machine was a 4.77 MHz 8088, and it was about two dozen clock cycles all-in for the three instructions, so around 5 microseconds long, triggerable once a second. (The bugged code was called fairly often, but the interrupt was tuned dynamically to happen once a second.)

    I told him that what I had described absolutely totally would cause the symptom he was seeing, and that he had to fix it before he could diagnose the real problem. He fixed it, and the "real" problem (one that took about twenty minutes to happen) never happened again...

  • Factory Improvement (unregistered) in reply to Pedro

    Yup, that's what I thought

  • Pedro (unregistered)

    What's the point of posting here when moderation takes ages? I'm taking this site out of my rotation - r/talesfromtechsupport is what I want.

  • (nodebb)

    I found it by blind chance, and described it to him. He pooh-poohed it as totally unlikely. The machine was a 4.77 MHz 8088, and it was about two dozen clock cycles all-in for the three instructions, so around 5 microseconds long, triggerable once a second.

    Hey Steve, was your colleague Larry?

  • Bill P. Godfrey (unregistered)

    There was a popular OS that had this issue. The API had separate calls for date and time, which meant there was risk that if you called these two functions either side of midnight, you'd get a 24-hour error.

  • smf (unregistered)

    There was a popular OS that had this issue. The API had separate calls for date and time, which meant there was risk that if you called these two functions either >side of midnight, you'd get a 24-hour error.

    Which is why you get the date, get the time, get the date again. If the second date is different then you go round the loop again.

    are the same ones that end up creating regression defects in production because nobody is testing their changes.

    I'd probably hack up a test program that constantly ran the old and new code in a loop & print out if they didn't match, then leave it running for a day. I'd make sure the actual time was recorded where there was a mismatch so that the validity of the new code could be tested.

    Of course there may be some code relying on it failing, or a someone that relies on the out of hour support calls to supplement their income, but if this was a system I was responsible for maintaining then I wouldn't care about that. I'd probably slip it in when I knew there was going to be a big QA test.

    If you're stuck with Jenga code then you're going to go through pain at some point, just because any change you make risks taking down the pile.

Leave a comment on “The Data Class”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article