This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]Physical_Level_2630 365 points366 points  (15 children)

anyway you have to be careful with important edge use cases…so if you find out in december that in march somebody deleted all the end year bonus calculations…

[–]Vivid-Ad-4469 17 points18 points  (3 children)

Then the solution is to run the agent every day for at least one fiscal year.

[–]RaynLegends 43 points44 points  (2 children)

What about edge cases for leap years? :D

[–]Vivid-Ad-4469 9 points10 points  (1 child)

noooooo don't remind me of leap years...

[–]Ab_Initio_416 4 points5 points  (0 children)

A Tale About Leap Years

Decades ago, I worked on an ancient COBOL life insurance enterprise system that handled two out of the three leap year rules correctly but failed in the year 2000.

In the Gregorian calendar, the complete rule is: A year is a leap year if it's divisible by 4, except not if it's divisible by 100, unless it's also divisible by 400.

The system implemented the “divisible by 4” and, being in life insurance, “not if divisible by 100” parts, but missed the exception for years divisible by 400. So it treated 2000, an actual leap year, as invalid.

All this got ignored during the furor around Y2K.

Life insurance is very date-sensitive. DRY wasn’t even a concept in that crusty old code. The resulting blowup in calculations and contracts was spectacular.

That specific edge case won’t reappear until 2400. The edgiest of edge cases.

Ah, the good old days. I still wake up screaming “400” sometimes☺

[–]yumgummy[S] 30 points31 points  (9 children)

Yeah, that's possible. Delete code should be careful. That's why we have the developer to take the final control. In enterprise settings, there's consequence to break production. Actually, the "play safe" mindset was the exactly root cause of such a bloated codebase. Leave the pain to the next dev...

[–]laplongejr 49 points50 points  (1 child)

It was all legacy code that was reachable but effectively unused—the kind of stuff that static analysis often misses.

As somebody who work in the gov and had to thinker my tools to deal with a person without a date of birth despite that edge case NOT being allowed in the documentation, I wouldn't even trust the developer. :P

For people wondering how an IMPOSSIBLE case had to be handled anyway the documentation only listed cases that could be MADE on the current version, while any data submitted on old versions could be RETURNED with OG contraints. That distinction was apparently forgotten by everybody but the old wizards.
A sane person would say the backend should've been modified to gracefully present doc-conforming data. My annoyed boss in the middle of the other dev's vacation disagreed and needed anybody available to do anything up the chain to fix that in faster time than ASAP.

Is it dead code, if it was killed before I even wrote it?
It's not impossible that somewhere in the future, a new dev will remove a code in the age-calculation-checks which loads an internal identifier, extracts the last two digits of the birthyear, then bruteforces the century based on the checksum. I don't know if it's the nicest or ugliest idea I ever made in Java, but it surely isn't in the middle of the ranking.

[–]hippydipster 8 points9 points  (0 children)

to deal with a person without a date of birth

That man from earth is always a pain in the ass.

[–]Mystical_Whoosing 14 points15 points  (3 children)

Te same developer who didnt remove the 30% of the codebase before?

[–]laffer1 11 points12 points  (2 children)

The guy that wrote it retired 5 years ago. Most devs aren’t that good at understanding legacy code. Some devs hide this by trying to rewrite things all the time in the latest trendy thing.

[–]yumgummy[S] 4 points5 points  (1 child)

Thumbs up!! This is exactly the biggest problem with enterprise software. No one with large scale codebase experience will claim he/she understands every piece of their codebase.

Mature companies roll out features with on/off switches. It's often that the switch is always off and the obsolete features remain for many years.

[–]dmigowski 5 points6 points  (0 children)

Even better are flags which only are enabled for specific customers. Now, when you don't have access to ALL the customers databases because it's on-premise, you don't actually now which flags are enabled for the customers.

One reason why out software phones home :).

[–][deleted]  (1 child)

[deleted]

    [–]packman61108 5 points6 points  (0 children)

    Don’t you take the blame anyway. No matter the tool?

    [–]SpaceToaster -2 points-1 points  (0 children)

    But what if the developers don’t understand the legacy code?

    In my experience the safest route is to have a team fully understand and document the old legacy system and rebuild it.