A logistics company isn’t the kind of company that invests heavily in IT, no matter how vital IT is for their business. That’s why Rich spent several years as the only developer. Most of his code was built to pick up data from one siloed turn-key system and dump it into a different one, or to integrate two in-house developed applications. On a bad day, he had to touch up the VBA macros in home-grown Excel spreadsheet someone in accounting had hacked together and had suddenly become “business critical”.

Guru teg bahadur.jpg
What a Guru might look like

Practically overnight, the logistics company hit an inflection point in its growth curve, and suddenly they were exploding. Revenue quintupled, new SBUs were created from thin air, and headcounts expanded accordingly. This, sadly, left Rich drowning in the flood of new requests. “I need help,” he told his management.

“We don’t have room for more IT hires, but we can bring on some contractors,” was the reply.

And thus appeared “Lunch Room Guy”. Lunch Room Guy was the new contractor from Initech. With the rapid expansion, they didn’t have any office space for contractors, so Lunch Room Guy was so named because that was where he sat. He immediately proved his utility by learning how to work the newfangled and overly complicated coffee machine. He was cheerful, enthusiastic and friendly. Eager to prove he was a good team player, he even went so far as to train others on how to use those coffee machines during his lunch hour.

The only problem with Lunch Room Guy was that he didn’t have all that much experience. “Well,” he admitted, “I’ve only got a few years experience with .NET, but my boss is a total guru. I can call on him anytime I get stuck, so it’ll be fine.”

A guru! How exciting! Based on the Initech’s track record, based on Lunch Room Guy’s enthusiastic demeanor, and based on their confidence in his Guru, Rich handed off a set of simple requirements for processing some XML-based data, and a little advice. “We’ve been using XLinq- Linq to XML- for doing XML processing. It works very well, but your boss is the Guru, so if he has other ideas, let me know.”

Requirements went in, and… something came out. Something that became known around the company as The Code. The Guru and Lunch Room Guy worked hard and communicated well. The users were kept in the loop, testing proceeded well, and the product got released into production without any issues. For the first few months, everything was smooth. The developer team kept growing to keep up with the business needs, and Lunch Room Guy was joined by Conference Room Gal #0, Conference Room Gal #1, and Broom Closet Jake.

As the company grew, the number of XML files hitting The Code also grew, and that’s when everything started to blow up. Invalid XML was coming out of The Code, or sometimes the data was just incomplete. The users were angry, the CIO was furious, and Lunch Room Guy and his Guru were busy on other projects, which meant Rich had to take a look at the code.

The first thing he noticed was that there was absolutely no logging at all. There was nothing that gave him a clue to how many files were processed, or how long the processing took, or if any errors occurred. Rich quickly added some timestamps to the process, and discovered that it was taking well over two hours to process the XML files- which was a problem, since the downstream job that consumed the XML ran every hour.

Rich dug deeper into the code, and found mysterious enumerated types declared like so:

Public Enum TableType1
'table name here
End Enum

Public Enum Columns
<snip 28 more>
End Enum

Lunch Room Guy’s code was starting to smell like a week old bologna sandwich. Especially when, a few lines later, Rich found this gem:

Public ReadOnly Property TableType() As String
Return _TableType.ToString
End Get
End Property

Public Sub SetTableType(ByVal TableType As GLEAN.Tables.HEADER.TableType1)
    _TableType = TableType
End Sub

Get the table type as a string, but set it using an Enum? That kind of mysterious logic could only make sense to the mind of a Guru. A little further down in the same file, Rich found more of the Guru’s handiwork…

Public Property Items(ByVal ColumnName As Columns) As Object
    Select Case ColumnName
        Case Columns.DAddress1
            Return _DAddress1
        Case Columns.DAddress2
            Return _DAddress2
        Case Columns.DCity
            Return _DCity
        Case Columns.DCountry
            Return _DCountry  
'snip 28 more cases
    End Select
End Get

Set(ByVal value As Object)
        Select Case ColumnName
            Case Columns.ScheduleId
                _ScheduleId = CInt(value)
            Case Columns.HeaderId
                _HeaderId = CInt(value)
            Case Columns.SchedNum
                _SchedNum = CInt(value)
            Case Columns.ShipWithRef
                If value.ToString.Length > 30 Then
                    _ShipWithRef = value.ToString.Substring(1, 30)
                    _ShipWithRef = value.ToString
                End If
                If _ShipWithRef.Trim = "" Then
                    _ShipWithRef = ""
                End If 
' snip 28 more cases
        End Select

    Catch ex As Exception

    End Try

End Set  
End Property

This coding “style” was replicated throughout the entire project. The constructor (well, actually the “Create” method, as the code didn’t use constructors) took 32 parameters. Pretty much every operation ran through a 32-branch Select/Case statement to decided what, exactly, to do. Exceptions were always caught and ignored. And this class represented just one section of the XML file- an XML file that was divided into 10 sections, each of which were backed with a database table ranging from 10–40 columns.

Rich sought out Lunch Room Guy for an explanation of what this garbage was.

“Oh, the Guru did all of the design and architecture,” he said. “It’s a really genius pattern, because it’s like using a database, but without actually using a database. It runs in memory, so it’s lightning fast! I’ve learned so much from the Guru.”

Rich blinked and backed away slowly. Lunch Room Guy wasn’t the only one who had learned from the Guru. Rich had learned two things. First, code reviews were not optional. Second, that there were times when the only option was to completely junk the existing code. Rich applied both of those lessons, and over the course of one long weekend, reimplemented his own solution. With a review from Conference Room Gal #2 and Broom Closet Jake, he released it into production.

It’s less than one-hundredth the number of lines of code, it runs in seconds, not hours, produces copious logging data, and has been chugging away with little more than minor changes ever since. To this day, even though Rich and his co-workers have moved on to other jobs and projects, they connect over social media and routinely discuss The Code, Lunch Room Guy, and what it truly means to be a Guru.

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!