So for the past one month I'm working on an enhancement in a product coded in C++ and shell script, running on RHEL. After toiling away for almost 10 hours/day for a month, the enhacement is ready. Coded, tested, documented. Ready to ship.

The client is supposed to recieve the update as a drop. 1 day before the drop is scheduled to be released to Quality Control, I fire an overnight build on the build machine, update the change request ticket, update other related tickets, inform QC of the drop to be released tomorrow. On the D-day, I package the drop using the company's painfully arduous method. Everything is ready by the evening, and the drop is good to go.

At 7pm (one hour before the drop is to be released), Jack fucking Jack-o-lantern (one of the top most exec in the company) tells me that the default value of the parameter introduced in the enhancement, needs to be changed from 86400 to 1500. HALF AN HOUR BEFORE THE DROP IS TO BE RELAEASED!

Now here I am, changing the value in over 25 files, followed by firing an overnight build, followed by sanity testing, change specific testing, followed by drop packaging, followed by inform QC that the drop will be delayed.

All because fucking jack-o-lantern wanted to change the fucking default value.

  • 2
    Well my question then is: why is this value a literal in so many places? There should be some way of abstracting it...
  • 0
    Because I work in code that was written 16 years ago and since has been modified/enhanced by over 20 people. That's why.
    The value is actually pulled from the database and can be configured. But since this particular value wasn't mission critical, the system had to fall back on a default hardcoded value instead of throwing an exception if it failed to fetch the value from the db. Since there aren't many such non-mission critical parameters, nobody has taken the pains to abstract these values and they are hard coded into every class that needs them.
Add Comment