Cireon

Spaghetti code is a term that has become disliked by RuneScape players and developers alive. Spaghetti code is often given as reason we are not seeing certain updates or reworks come out in RuneScape. Spaghetti code refers to code that is just as long and tangled as actual spaghetti. Modern programming languages have many ways of keeping code organised. Subroutines that execute a single action can be abstracted into methods, and classes are used to group methods pertaining to a single type of object together. Sometimes it is just easier to tack on a few lines of code to an existing block of code just to make things work. Over time, you end up with long blocks of code without a clear structure, making it hard to maintain, work with, or add features to. In turn, incomprehensible code makes it easier to accidentally introduce bugs.

Spaghetti code is actually somewhat of a negative term in itself. A more neutral – or professional – term would be technical debt. This term is surprisingly appropriate, since it resembles a debt you could accrue in the real world by taking out a loan. Put quick and simply: whenever a developer makes the decision to take a shortcut in the code rather than doing things the right way to get something done quicker now, they are taking a loan. In technical debt, the debt is measured in time. You save time now, but in the future you may have to go back and fix the code, because it blocks a different feature.

Just like a real debt, technical debt accumulates interest over time. Whenever you touch code that already contains technical debt, you have to work with the shortcut you (or another developer) made earlier, which takes more time (the interest, since debt is measured in time, remember!) than if you had taken the right approach from the start.

So to summarise: spaghetti code, or technical debt, is caused by a programmer making the choice to not implement the “right” solution now, but leaving that for the future, gaining valuable time now, but potentially having to spend lots of time in the future to fix the mess you just made.

As I explained, spaghetti code is often a negative term, but is technical debt in itself a bad thing? The way we often hear about it from Jagex makes it sound that way, but it is not necessarily true. Technical debt can be caused by programmers who lack the skill to come up with a right solution, but more often it is actually a conscious choice. Building the right solution can sometimes take days, whereas a quick hack might get around the problem within a few minutes. Even though you are not really solving the problem, if you have a deadline looming up ahead of you, it may be valid to push the problem forward in time.

Another good reason to accept technical debt is if you are prototyping. Let’s say you have an idea for a killer feature, but you are not sure if it will work. This is very often the case in game design, where there isn’t a formula for “fun”, as I explained in this earlier article I wrote. Quickly putting some code together so you can try out the feature is a really important tool. This is also where the danger creeps in though. A programmer may build a prototype, and when the idea is approved, the prototype code is kept, with all its quick hacks and bad choices included. This is only one form of laziness that can cause technical debt. Sometimes a developer just really wants to make that deadline, even though the better decision would be to push the deadline back.

There are good reasons and bad reasons for taking on a technical debt. Even if you have a good reason, you’re not out of the woods yet. That loan you’re taking now is going to come back later, usually with a vengeance. It is important to take that into consideration, and have a plan to address the debt in the future. Many companies incorporate weeks in which the focus is to only remove technical debt. Another important way of reducing technical debt is by the so-called boy scout rule: each time you change code, you improve one or two things in its vicinity. It can be as simple as renaming a variable or splitting out a method, but over time it will improve the quality of the codebase.

Games have an interesting position when it comes to technical debt. A game is often finished, released, and forgotten about. Maybe there are several patches or DLC, but the lifespan of a game is rarely longer than a few months. That means that in game programming, you often get away with not repaying your technical debt ever, because everybody moves to a new project. Especially in the last few weeks before a big release, game development often finds itself in a state of crunch. Crunch is notoriously present in game development studios, and refers to the period of time in which developers often make long hours (nights and weekends included), just to get the game out on time for the promised release dates. The industry here is brutal, because gamers expect to know about release dates early, and expect to pre-order the game and play it on release date. In that period of time, if you have the choice between refactoring a bunch of code, or actually getting some sleep tonight, that choice is easily made.

This brings us right back to RuneScape. As opposed to many other games, RuneScape’s code has actually existed for over a decade. There is no hoping that a quick hack now will never come back to haunt you. Yet, we see the pressure of the community to release updates weekly. Larger updates at RuneScape may actually see some crunch time to make the promised release date. After that, it’s immediately time for the next project. Luckily, we are seeing a bit of a shift. Larger rework/remaster projects are a great opportunity to rework code as well. Working on patches in turn allows application of the boy scout rule, touching up code as you go.

In the past few years, code health and technical debt has become a top of mind issue to many companies that deal with ongoing maintenance of a code base. That means there are plenty of examples out there to learn from. It seems that Jagex at least has built up the courage to tackle older parts of the codebase, and reworking them. They are finally repaying the debt they have accrued over the many years of quick hacks and fixes. We may have to be patient while they do so, but it looks like we can look forward to content remasters as visible outcome to this progress.

Hopefully you have learned a bit about what spaghetti code really is, and why it isn’t necessarily a bad thing. It does help to get things done on time, even though there is a cost involved at a later date. Repaying the debt is the only way to move forward, and that is what we can expect Jagex to work on for at least the next year.