DevDisasters

The End of Days

It's a situation a coder should never have to face: perpetuating bad coding practices from years ago, or just fixing the darn thing!

You don't have to know Bruce C. for very long to understand he has a negative opinion toward long meetings about key performance indicators, milestones and department goals.

He felt such things were not only a complete waste of productive time, but a torturous exercise right up there with passing a kidney stone during a complex dental procedure.

Knowing this, you can imagine how Bruce felt as he settled in for a mandatory two-hour-long PowerPoint slide deck-a-palooza with the rest of his department.

It was around the halfway mark during this meeting -- just as Chris, Bruce's manager, was getting into his groove discussing deliverables for the next quarter -- when the presentation was interrupted by an unexpected Outlook reminder pop-up: "Never Forget 6/1/2010!"

Chris chuckled. "Oh no! How'd that get there? Yep, I'll never forget back when I was a developer! Sometimes I wish I could go back to those days!" and then quickly dismissed the reminder, to the amusement of the developers in attendance.

Although an interesting disruption, it didn't take long for Bruce to return to daydreaming, wishing that he, too, could get back to writing code.

Later, after Bruce had been reseated back in normal reality, he received an e-mail from his manager with an attached SQL file:

From: [email protected]
To: bruce.c      @us.cyberdyne.com
Subject: Never Forget 6/1/2010

Hey Bruce,
Needless to say, I did forget about the events
following 6/1/2010, hence the reminder!
Can you help take care of a little
favor for me? The file is updated and I would've handled
myself, but my old logins are all long expired.

Greatly appreciated,
Chris Connor
Senior Project Leader
Order Fulfillment Systems
Cyberdyne Supply Chain Solutions

Bruce opened the attachment, inspected the code and noticed the areas where Chris had made some recent adjustments:

DECLARE @StartDate datetime
DECLARE @EndDate datetime
DECLARE @LoopDate datetime

SET @StartDate = '06/01/2014' --'06/01/2010' --'06/01/2005'
SET @EndDate = '05/31/2019' --'05/31/2014' --'05/31/2009'
SET @LoopDate = @StartDate

WHILE @LoopDate <= @EndDate
BEGIN
INSERT INTO [Dim_Date]
           ([SK_Date_ID]
           ,[Date]
           ,[Day]
           ,[Month]
           ,[Quarter]
           ,[Year])
     VALUES
           (
           CONVERT(int, convert(varchar(255), @LoopDate,112))
           ,@LoopDate
           ,Day(@LoopDate)
           ,Month(@LoopDate)
           ,CASE WHEN Month(@LoopDate) IN (1, 2, 3) THEN 1
                 WHEN Month(@LoopDate) IN (4, 5, 6) THEN 2
                 WHEN Month(@LoopDate) IN (7, 8, 9) THEN 3
                 WHEN Month(@LoopDate) IN (10, 11, 12) THEN 4
              END
           ,Year(@LoopDate)
           )
 SET @LoopDate = DateAdd(d, 1, @LoopDate)
END

A quick query revealed that the Dim_Date table held an entry for each date in the ranges that were commented out, starting in 2005 and going through to 2014.

Bruce knew that what he was being asked to do was utterly and completely wrong in every way. He knew in his heart that perpetuating a simple table of dates and date information that could be easily calculated on-the-fly by code written by the newest of newbie developers wasn't the way to go. But he proceeded anyway, as June 1 was coming soon -- no way could he squeeze in testing and authorizations. He ran the script, as requested, and expanded Dim_Date out by several hundred more rows, to hopefully stave off failure for several more years.

Bruce sent a simple reply, explaining that he ran the script, but also insisting that it be replaced with a common function to calculate date information instead of storing the static values in a table. To show he was serious, he also included a listing of the two dozen or so dependent objects to the Dim_Date table that he could find in Team Foundation Server.

The reply back from Chris was swift:

From: [email protected]
To: bruce.c      @us.cyberdyne.com
Subject: RE: Never Forget 6/1/2010

Thanks for the quick turnaround! That list looks pretty sizeable,
so we'll need to develop a plan to make that volume of
code changes. Let's pick up the conversation
again closer to the end of the year.

Greatly appreciated,
Chris Connor
Senior Project Leader
Order Fulfillment Systems
Cyberdyne Supply Chain Solutions

Soon after, Bruce received a calendar invite with the title, "Don't Forget about Dim_Date," dated not for an arbitrary point near the end of the year, but rather for today's date, in 2019, with the description, "Just in case one of us forgets," and the previously used SQL included.

Bruce accepted the invite, but was concerned he might not be around to perform the update. In the end, he had some serious doubts as to his longevity in the department, especially if his and Chris' goals weren't aligned.

About the Author

Mark Bowytz is a contributor to the popular Web site The Daily WTF. He has more than a decade of IT experience and is currently a systems analyst for PPG Industries.

comments powered by Disqus

Featured

  • Compare New GitHub Copilot Free Plan for Visual Studio/VS Code to Paid Plans

    The free plan restricts the number of completions, chat requests and access to AI models, being suitable for occasional users and small projects.

  • Diving Deep into .NET MAUI

    Ever since someone figured out that fiddling bits results in source code, developers have sought one codebase for all types of apps on all platforms, with Microsoft's latest attempt to further that effort being .NET MAUI.

  • Copilot AI Boosts Abound in New VS Code v1.96

    Microsoft improved on its new "Copilot Edit" functionality in the latest release of Visual Studio Code, v1.96, its open-source based code editor that has become the most popular in the world according to many surveys.

  • AdaBoost Regression Using C#

    Dr. James McCaffrey from Microsoft Research presents a complete end-to-end demonstration of the AdaBoost.R2 algorithm for regression problems (where the goal is to predict a single numeric value). The implementation follows the original source research paper closely, so you can use it as a guide for customization for specific scenarios.

  • Versioning and Documenting ASP.NET Core Services

    Building an API with ASP.NET Core is only half the job. If your API is going to live more than one release cycle, you're going to need to version it. If you have other people building clients for it, you're going to need to document it.

Subscribe on YouTube