- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Wow, I wonder what kind of budget that can not cover this fix?
Admin
No easy reader version, skipped
Admin
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...
Admin
"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.
Admin
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.
Admin
But writing the e-mail is another budget, so that's not a problem :)
Admin
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.
Admin
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.
Admin
"data" is portuguese for "date". So perhaps this class started with only date-related methods such as that "now()".
Admin
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.
Admin
Sooooo… a
Buffer
?Admin
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.
Admin
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.
Admin
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.
Admin
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.
Admin
I mean....everything would be fixed with DateTimeImmutable......
Admin
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.
Admin
This is where you just fix the code without telling anybody so it's no longer a budget issue.
Admin
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.
Admin
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/
Admin
I was thinking "Data" was just "Date" in another language due to the now function.
Admin
Admin
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.
Admin
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.
Admin
@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
Admin
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.
Admin
@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.
Admin
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.
Admin
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...
Admin
Yup, that's what I thought
Admin
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.
Admin
Hey Steve, was your colleague Larry?
Admin
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.
Admin
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.
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.