Forums
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”.
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
LOADSCHEDULE
ARCHIVESCHEDULE
REVIEWSCHEDULE
End Enum
Public Enum Columns
ScheduleId
HeaderId
SchedNum
ShipWithRef
<snip 28 more>
End EnumLunch 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
Get
Return _TableType.ToString
End Get
End Property
Public Sub SetTableType(ByVal TableType As GLEAN.Tables.HEADER.TableType1)
_TableType = TableType
End SubGet 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
Get
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)
Try
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)
Else
_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!