Maintenance, glitches and acronyms galore.
Another week over and another week closer to the big bad world of placement. This week we continued on with the COBOL maintenance module, looking at progressively larger codebases, aiming to understand their logic, refactor where appropriate and add some extra features.
After the success of the gilded rose kata, I had moved on to 2048. 2048 is a simple online game, you start with a 4x4 grid with a couple of spaces occupied by the number 2. You have to move squares around, matching tiles will double and new 2s or 4s will appear randomly each turn. The overall aim is to merge enough tiles to get a square with the number 2048. Sounds simple enough but it’s actually quite a tricky challenge and one that kept me happily amused for a while last week.
Pulling myself away from the game itself, my task was to read the code for 2048 in COBOL, try to understand what was happening and add some new features without breaking the whole thing. First thing to do was to expand the grid to a 6x6. This turned out to be an easy enough task and after a couple of checks to make sure I had converted all mentions of 4x4 to 6x6, I was done. Easy. The second task unfortunately was not.
2048 has a lovely online version with slick graphics and nice colours, the COBOL version however, played in black and white on a terminal screen, was a bit less user friendly. So our task was to alleviate that, at least a bit, by adding some colour. We had to change the program so that matching numbers were the same colour e.g. all 2s are green, 4s are blue etc. Not the easiest task when you have a dynamic grid with numbers changing position and value regularly. Nevertheless, I had an idea I was pretty sure would work.
Using my new found skills and logic from the bulletin board activity I figured we could use a similar principle here and make use of a table, a counter and an indexed variable to change our colours when appropriate. After a bit of playing around, a couple of silly mistakes and some debugging we had something that pretty much worked as intended, except for one problem; the top left grid square just wouldn’t play ball.
This has to be the strangest bug I have come across to date. For some reason the first grid square was not behaving like the rest. We tried everything, we brute force changed the colour of it, we changed the order around, this just moved the problem on a square, we displayed as many variables as possible and we still couldn’t figure out what was going on. After many hours spent battling with this one grid square we enlisted the help of not 1 but 2 coaches. After some even more intense debugging, leaving all but about 5 lines of code commented out, we still had the same problem and no idea why it was happening. We concluded it was simply one of life’s greatest mysteries, an unknown bug, a fault in the system, a glitch in the matrix.
So whilst we couldn’t get to the bottom of the glitch in our matrix and understand what was causing it, we did have a workaround. A brainwave from a colleague revealed that we could simply write the line of code to display the square twice, the first time including the glitch and the second time, glitch-free to overwrite it. Such a simple idea, something that was pretty much the equivalent of sticking a plaster over it and hoping for the best, but it did the job and at this point, days after our initial attempt, I no longer cared. It worked, that was all that mattered.
After a good night’s sleep and an escape from the world of 2048 we had a fresh challenge on Wednesday morning. We were in the fortunate position where we had been given some sample code from DWP to look through. The program couldn’t run as we didn’t have all the files and we couldn’t make any changes but still, we had real life code, exactly like the type of code we would soon be working with.
It made no sense.
Okay, so that’s maybe a tad dramatic, some bits made sense, like the date and author name but that was about it. Suddenly things felt very real and a bit scary. Here we were looking at this massive codebase, which was actually only a small section of the real codebase, the type of programs we would be expected to fix, maintain and write in a few weeks time and we had no idea what was going on.
Send help.
Initial panic over, we looked at the code in a bit more detail as a group to start and things did start to make a bit more sense. The first thing to note, and something I learnt during my previous temp role in DWP is that the DWP love a TLA (three-letter acronym). They were everywhere, and to be honest, the acronyms and abbreviations were probably the main barrier to us understanding any of the codebase.
Armed with google and a list of common DWP abbreviations we spent a good few hours in groups trying to decipher a section of code at a time. Gradually things started to become clearer. We had to guess a few abbreviations (STA surely can’t be the Swimming Teachers Association right?) but overall we were able to get some idea of roughly what this program was doing and how.
We spent the following day, continuing our slow progress through the code and my mood started to pick up. Things were making more sense, the abbreviations and acronyms aside, the code wasn’t nearly as complicated as it first appeared. What a relief.
However, reading through a large complex codebase without being able to run it or make any changes, can only get you so far and frankly it gets a bit dry after a while. We found our attention span narrowing and narrowing as the day went on, taking any excuse for a break or a change in the topic of conversation.
One last push through the finish the program and we decided to call it a day. We had taken all we possibly could out of the codebase and our brains were well and truly turning to mush. Time for a well deserved weekend and a break from trying to decipher acronyms, but I’ll allow myself one more; TGIF.
