neuroncollision

Maintaining and updating software is much like a massive game of The Towers of Hanoi. This is especially true with software that must continue to operate, at least in some form and fashion, during the overhaul.

If you aren’t familiar with the classic game of The Towers of Hanoi, let me first attempt to explain it. A wooden board has three dowels on it, spaced at even intervals. On the far left spindle are 4 rings decreasing in size from top to bottom. For sake of visualization, the bottom ring is orange, the next up is blue, followed by yellow and red, respectively. Looking down upong them, they make concentric circles of color. The goal of the game is to move the stack of rings to the furthest dowel. Easy task, until you give the simple rules. First, you may only move one ring at a time. Secondly, a move consists of taking an upper disk from one of the pegs and sliding it onto another peg, which may already be occupied by another ring. And the kicker, no disk may be placed on top of a smaller disk.

Steps to solution:

1. Move the red disk to the middle.
2. Move the yellow disk to the furthest peg.
3. Move the red disk to the furthest peg.
4. Move the blue disk to the middle.
5. Move the red disk to the first peg.
6. Move the yellow disk to the middle.
7. Move the red disk to the middle.
8. Move the orange disk to the furthest peg.
9. Move the red disk to the furthest peg.
10. Move the yellow disk to the first peg.
11. Move the red disk to the first peg.
12. Move the blue disk to the furthest peg.
13. Move the red disk to the middle.
14. Move the yellow disk to the furthest peg.
15. Move the red disk to the furthest peg.

These steps can be algorithmagorically created for any X number of rings.
With each move you are deconstructing then reconstructing the entire tower, while still maintaining the basic overall structure of the object.

Let’s change the name of our game to Code Blocks of Hanoi. When attempting to redevelope an application, we have two options:

1. Destroy our tower, and rebuild from the ground up
2. Step through the development cycle using analogues of the Towers of Hanoi

Sometimes, perhaps most of the time, under ideal conditions, the first option would be the best choice: Recreating the project from the ground up using the things you learned building it the first time to allow for extendability. However, given the nature of most developement, the person maintaining the code is not neccessarily the person who wrote it in the first place.

Let’s change our rings:

• Orange - Data storage (Databases, file systems, text files)
• Blue - Data Acquisition (SQL Queries, File I/O
• Yellow - Data Manipulation (Formatting and preparing data for output)
• Red - User Interaction (Display and interactivity of Data)

For most cases, the red ring will be the most oft requested change. As such, you would pick it up, dust it off, maybe change the way a button works, or how the interface handles a certain event, then put it back on top. No real impact on the client, or the developer. Now, let’s say the yellow ring needs to be changed. Just like in the steps for a tower, the red ring has to come off first, then the yellow ring. Perhaps the data we had recieved was good, but our calculations and manipulations of the data were incorrect. To fix the yellow ring, perhaps we’d need to do some string manipulation to remove special foriegn characters our clients can’t see, or our original formulas for calculating Yearly Dividend are off. Perhaps, our formatting function spit out the wrong number of zeros. Whatever it is, it has to be fixed, and like the good little code monkies we are, we do so with gusto. So, we stack the yellow ring back on top of the tower… but what about the red ring? The data it is expecting has changed, possibly a lot, possibly none at all. Either way, we’ve got to tweak it, polish it, and restack it.

Further down the tower still, we have the Blue Data Acquisition ring. At this level, we are retrieving the data from our data sources, whether it be a full blown Oracle Database, the now no-longer-opensource MySQL, a flat file, or an RSS feed, this is where we get the data that will be used on the yellow ring. But a client has called us and said that “Cheeseburgers aren’t a measure of market volatility.” Taking a look at our feed, we realize we selected the wrong field from the database, or that the maintainers of the RSS feed has changed the nodes around. Which ever it is, we must change the way we acquire our data, perhaps it’s a big change, like jumping databases and getting used to a new schema, or cycling through XML nodes till we hit the right one. Either way, we pull of the red ring, pull of the yellow ring, lump the red ring on the yellow together, and get crackin’ on what could be a big mess. After hours, or possibly minutes of work, we’ve fixed the data issue. But now… now we’ve got problems with the yellow ring, because the data coming to it is not what was expected. We remove our interaction layer so we can get to the meat of it. So we toil away, fixing one-off issues, modifying our previously working functions to handle the new data paradigm. Eventually we are happy with our changes, and look at it again, through the client’s eyes. Now data doesn’t mean the same thing. We’ve gotta re-arrange the layout tables, or add interaction to drill down into data. We get it down. It took us a while, and but we got it done.

Finally, at the base of the towers, we have our Orange Data Storage Ring. The one thing that we hope went through all the proper steps at the begining of developement. But, inevitably, the base layer will begin to crumble and need to be overhauled. We go through the steps, removing the interaction, manipulation, and acquisation layers. There we are, standing face to face with the heart of the beast. When the developement tower was first built, this layer was pristine… virginal even. Everything in the rest of the project was built upon the idea that this would never change. But somewhere, in the eons since the electrons began to flow out of this Binary Soul, corruption seeped in. A being not limited to ones and zeros decided that the information The Base contained was not enough. And so, there, in your inbox, comes a simple note. “Add These Columns To The Base”. The fear seeps through you, children flee from the openess of the dirty streets, the sky darkens, and there is heard an eldritch wailing and the sound of the masses gnashing their teeth.

You begin to deconstruct the tower, rules of movement be damned. The user interface gets tossed aside like a lawn chair in a tornado. The manipulation layer is left drowning in the open air like a carp flopping on the main deck. The acquisition layer sits motionless in the Barcalounger, the still smoking gun of ScopeCreep hits the ground with a heavy thud. And there in the corner, the Orange ring of Data Storage is curled up in the fetal position. Then, like the calm wind in the middle of the eye of a hurricane, your arcane machinations begin. The columns are added, and you place the ring on the spindle. With a steady hand, you begin to patch up the blue ring. Minutes, days, possibly weeks, you rebuild the mangled Data Aquisition ring. Better… Faster… Stronger. With a twisted look in your eye, you place the blue ring back onto the spindle. “Soon..” the voices whisper. Never mind them… you have other things to do. You grab the decaying ruins of the yellow ring, and like a twenty-first century Dr. Frankenstein, you start patching up the corpse of your Manipulation layer. Re-using some code, totally rewriting other parts, perhaps even stealing some from other long dead projects. Polishing it off, it gets dropped onto the tower. Only one ring left. You pick up the red ring and set it on an easel. The misshapen form looking more like a grotesque Picasso than a structured Piet. Grabbing a can of kerosene, you douse the canvas and set it a flame, a maniacal smirk smears your face. You grab a blank canvas and create your masterpiece. A work of Interactive art. You put the last ring on the tower. The work is complete.

This was a dramatization… obviously. However, it is important to keep in mind that a small change on a lower layer of code, can produce dramatic changes in code above it. This is espescially true for projects that have a time constraint. I can’t count the number of times I’ve been asked to make a seemingly small change and gave a completion time of “too soon”. Sometimes, those that are in a more business-like position don’t have a full grasp of how, what seems to be a little change on the front-end, can require drastic changes on the back end. It is up to you, as a developer, to give them a bit of understanding as to why it might take an hour to make a layout change, but a week to make a datachange. Perhaps the previous analogy will help a bit.