RSS 2.0 Feed
What Can You Do With 16 Bytes?

Sometimes you read something in the paper that suddenly makes you go "What...?...!". So you read it again to make sure you didn't miss out some words in the middle, or even a vital comma, but it still says the same thing. You read it again, and - sure enough - it says exactly what you think it said the first time. It was like this a few days ago when I was reading the Daily Torygraph business news section. And I'm still not sure I quite grasp what it said. Basically, the gist is that our useless Government has noticed that a decreasing number of people are starting up new businesses, and an increasing number are closing down. That's kind of understandable in today's economic climate, especially since the only three countries in the world with higher rates of tax and business regulation than the UK are Hungary, Egypt, and some small island off the coast of somewhere.

Amongst the solutions our Communist leaders are considering are the usual half-baked ideas like encouraging more women to set up businesses by "...providing useful gender-specific telephone advice lines and colorful pamphlets...", and "...plans to reduce the impact of regulation and red tape on small businesses by 10% during the next ten years." Maybe there will be thousands of people queuing up outside their local accountants' offices tomorrow morning to register their exciting new business. However, it wasn't this bit that caused me to splutter into my cornflakes. It was the next bit of the article, which carefully explained that one of the major new initiatives to encourage people to risk their house, their livelihood, and their children by starting up on their own was that they were going to introduce measures that "...reduce the stigma attached to bankruptcy." What they really mean, then, is that they know you have pretty much no chance of ever making a go of this, but they won't sneer at you when the bailiffs are confiscating your house and children, and you end up living in a cardboard box under a railway arch.

One of the reasons it's taken me a while to actually report this amazing new direction in British politics is that I've been trying to think of an allegory in the computing world. You know - the kind of thing that starts off "It's like if....". But I can't actually think of one. Maybe providing the customer with a free copy of Visual Studio and Amazon's best-selling book "How to Debug and Fix Crap Applications" when they commission a Web site from you would come close, but it still doesn't have that same "What...?...!" factor.

Of course, these days, you design your applications to conform to the latest architectural guidelines and coding practices, and implement agile development and comprehensive unit testing, and so you know that they will work perfectly straight away and never fail. In fact, soon you will probably just have to write some specs and tests, and Visual Studio 2012 will write all the code for you. Don't believe it? Take a look at the software factories and other code development tools that are appearing now. I mean, let's face it, why should we have to do drudge work and mess about writing code when computers are so fast and reliable that they can do it all on the fly - while you are still drawing boxes and arrows on a whiteboard, and trying to remember the name of the design pattern you think you ought to be using.

It's interesting to compare this to only a relatively few years ago. OK, so I am not currently residing at the spotty teenager end of the age scale, but when I started programming you had to start every program by writing or importing the code to take a character and print it onto the screen in the appropriate position (you could choose any one of the 26 lines and 40 characters width). And, if you were really keen, you could do it in "graphics mode" so you could actually have custom characters. Italic or bold, for instance. And then, to maximize the performance of your sparkly new application, you went through the code changing all the variable names to single characters, and all the subroutines to inline code. In fact, I made a chart generation program run over three times faster just by applying this optimization technique.

Of course, if you wanted an application to run at slightly more than glacial speed, you wrote it in machine code. That way, users wouldn't actually see the screen being redrawn each time you needed to prompt for input. So most of the developers of my generation became experts at loading and storing accumulators, comparing registers, and branching if not equal. I can remember reading articles in the magazines of the day that showed how you could reduce code that took up 500 bytes of memory (note: that's bytes, not KB) by 20% by pushing and popping the stack. Even though I was past the teenager stage in those days, I guess I was still a fully paid up member of the anorak-wearing geek set. And I probably still am.

I mean, I remember when we discovered that the Oric Atmos (our favorite development tool at the time) had 16 bytes at the top of memory above the O/S that wasn't cleared when you reset the system. That meant you could do all kinds of devious things like cracking the best new games of the day to find the cheat codes, and making your own copies on those new-fangled floppy disk things, just by writing a short routine that disabled the auto-run feature. As long as you could fit it into 16 bytes, the world was your coding oyster. All you needed was a regular supply of coffee and toast (we didn't have a local pizza shop), and some reasonably believable excuse for not managing to get into work the next day.

But then, like computing theory and technique, I grew up. I'm not quite sure what happened in the intervening 25 years, as I spent most of it getting married, buying a house, doing DIY, cleaning the car, and working in jobs where you couldn't get away with turning up after an unscheduled week off with no better excuse than "I forgot where I worked", or "the dog ate my sales report". I can seem to vaguely remember the GEM operating system, dBase III, Lotus 1-2-3, Visual Basic 1.0, and having to learn LISP as part of a technology course I ended up on (where we used a teletype to write programs on the college mainframe). I even half-mastered COBOL and some RPG on a huge and lumbering IBM 360 when the boss wasn't looking (I was supposed to be "out in the field", not "fiddling around with sales data"). Though, of course, I've forgotten it all now.

However, coming back to earlier ramblings, you can see why it continually amazes old codgers like me when I see how we create software now. My enviable position associated with a team that builds exciting new products for .NET means I see all the new technologies, architectural theory, patterns and practices, and the final results created by some of the brightest people in the industry. Yet, I can't help thinking how complicated it all seems. For instance, to read a few values from a configuration file takes a couple of dozen classes that rely on several layers of base classes in the .NET Framework. Yet I could write four lines of code that open a file and read the contents into an array. Likewise, a simple event-driven mechanism for controlling a small demo application requires two separate Visual Studio projects and almost 50 classes. That's almost enough to cause another "What...?...!". I could do events with three lines of code in Turbo Pascal 1.0.

Yet, only last week, I was at a conference standing in front of a hundred or so hardcore developers waving my arms about, rambling aimlessly, and generally trying to get them excited about Enterprise Library, design patterns, policy injection, manageable configuration, inversion of control, and aspect-oriented programming. It's strange because I know all this stuff works, and I even understand how most of it works, yet I still find it hard to believe just how far we (and I) have come. I started off poking machine code bytes into remote corners of memory, and now spend my time telling people how they can build systems that allow an administrator to change the concrete classes that an application instantiates internally - across 20,000 servers - just by editing a value in Group Policy on a domain controller.

Yes, I know that everything changes, and has done dramatically over the past 25 years. I've heard the often-quoted comparison between computers and cars many times. You know, the one where - if cars had developed at the same rate as computers - they would cost two dollars, do 8000 miles per hour, and travel round the world twice on a gallon of fuel. And I suppose comparing how we used to fix electrical faults on an old Honda 250cc Dream (by putting a brass nut-and-bolt in the fuse-holder) with the untouchable electronic systems in modern cars and bikes does reflect how things have changed in the automotive world. But I canít help thinking that the pace of change in the kind of software we build today exceeds everything else. Can we keep doing it? And what kinds of tools will we need to maintain the thrust of development? Maybe Visual Studio 2012 does need to be able to automatically write all the code for us...

Email:         Privacy and Acceptable Use Policy