Speed and space
Back in the early days of computing, writing a program was an arduous task. It could quite easily involve hours of punching holes in pieces of card to get the program into the machine, and then a long waiting process for the machine to spit out further pieces of card with the solution to the problem written as — you guessed it — a series of holes punched in card.
The best way to get a fast result was to optimize the input. Don’t waste bytes of code, just get the machine to do exactly what you wanted. The reasons were two-fold — it took less time to punch the cards if there were less instructions, and it used less memory in the computer. This was beneficial as the working memory may have only been a few bytes in size.
Progress — of a kind
The microcomputer revolution began in the 1970s and was in full swing by the mid-80s. Most home and business computers had 64k of memory or less, which was thousands of times more than the older computers, but was still limiting as they now worked with screens and color graphics. Writing code that was small remained important. Furthermore, these machines were often being pushed to their limits. Games were written to run on these computers that were imitations of games you would find in an arcade. The problem was, arcade machines had custom hardware designed specifically to do the things they needed to do — play sounds, play music, draw graphics onscreen. Home computers were general purpose machines that just did the best they could. Therefore, writing optimized code — code that ran quickly — was also important.
Bigger isn’t always better
As time progressed, computers gained more storage space. RAM sizes increased from being measured in kilobytes to being measured in megabytes, and now gigabytes. The early machines didn’t have hard drives. When hard drives first arrived on the scene, they were measured in megabytes. Now they are measured in terabytes.
This progress meant that there was room to expand, more space to play in. And of course, processor speeds increased too — no longer are they measure in kilohertz, but gigahertz.
Because of this, code got larger and larger. More features were able to be added, more options, more of everything, including waste. No longer did code need to be small, as there was plenty of space to store and run it. No longer did code have to be inherently fast, as the faster CPUs took care of it. The art of efficient programming was almost lost.
The Internet Ruined Everything
When the internet arrived in homes and offices around the world, it rapidly gained traction. Information was at your fingertips, and could be transferred at the speed of…well, about 2k per second. Dial-up connections were the norm, and all of a sudden, large programs and files became the bane of every internet user’s life. Smaller files were needed. Compression algorithms helped, but starting with a smaller file was better.
The modern web was built on HTML, the underlying code of webpages, and so small HTML files were a great benefit for dial-up users. Of course, as with computers, connections speeds got faster and faster, until today where webpages and their associated scripts and images can weigh-in and quite a few megabytes in size. On a dial-up connection, they could take hours to display. On a modern broadband connection, just a few seconds.
This has led to an increase in “dirty code” — HTML code that does exactly what it is meant to (or at least, near enough), but in a very inefficient way, and is possibly difficult to understand.
“Clean code” on the other hand is very easy for a human to understand but may well not be efficient.
“Optimized code” will load and run quickly but might be harder for a human to follow.
Let’s look at an example in plain English. Imagine you were writing the code to build a dog. Here’s how each type of code might look:
Animal:\ Medium size, furry coat.\ Leg, leg, leg, leg, tail, head.\ Head and tail at opposite ends.\ Legs on corners.\ Goes woof.\ And bark.\ Defends and attacks.\ Runs.\ Fetch.\ Plays with toys.\ Good fun.
Animal: Medium size\ Has fur\ Has four legs\ Has a head and a tail\ Makes noises, including "woof" and "bark"\ Protective\ Enjoys playing and exercise
Animal//Fur:\ Size(50%)\ Leg:Loop(4)\ Head<->Tail\ Include('playfulness','sounds','security')
Bear in mind that these are not true commands in any programming or scripting language, but are intended to illustrate the difference in approach for each method of coding. The dirty code gets the job done, quite inefficiently (not everything is in a sensible order, and the description is quite long), and might not work quite correctly (are the legs really on corners?). The clean code is easy to follow, does what it needs to, and is a bit shorter than the dirty code. The optimized code does exactly what it needs to, is very short, but also not as easy to follow as the clean code.
What does the future hold?
The future is likely to continue in much the same way as the present. There is no slowing down of internet connections, so file sizes don’t present an issue. Clean code may become more popular, as it is useful in open source software as other people can see what you are intending to do, and it can still be updated long after the creator has abandoned it.
Optimized code will only become important again if computer speeds don’t significantly increase within the next 10 years, or if something happens to cause the internet to be accessible only at lower speeds.
Dirty code will always be around, as quite simply, it’s the quickest and easiest way to get a prototype up and running. Proving a concept will always outweigh the usefulness of readable code.