The Millennium Bug

This isn't really about the Millennium Bug, or the Y2K problem, per se, but about computer programming and software development. I became interested in computer programming in university. Back then, it was just a way to solve small problems. Nothing big. Just a program here and there to solve a personal problem. I used other software to write my software. C compilers to create my programs. Word processors, spreadsheets and so on. And even when I started writing programs for other people, they were always simple tools. The actual logic in the software took a short time to write. Most of the effort was spent writing user interface code, exception handling, help and additional code to protect the program from misuse and to protect the user from themselves.

That was the world of top-down, procedural programming. A program had an entry point and followed a pre-determined path. Some of the issues, or side effects, that were exploitable were few. Software was not that complex. It occurred to me that there were limitations from the machine. Having delved into assembly language, I knew that specific things were fixed. The processor had a specific number of registers and that you could only perform a limited set of operations. That data moved along a bus that had a specific width, 8-bit when I started, and seemingly simple operations, like addition, took a number of operations. As long as requirements were not complicated, writing software was a pleasure and it wasn't too hard.

But still, it never occurred to me, not until I entered the world of business application programming, that software development was very short sighted in its view of the future. Even though we knew that software spent most of its life in maintenance, so we were told, it didn't look as though that's how it was built. But that, in fact, is the case. When businesses need to solve particular problems, they build a tool for that problem. If later, the problem changes, they try to patch the software instead of building a new one. And this patching too is a problem. It's incredible how much software that we use today was written many years ago with limited scope. There was no way we could have anticipated what the world would look like ten years into the future to plan for it, less alone twenty.

So what was wrong with this Millennium Bug? Well, someone decided that dates needed to be stored in computer systems, and back then, programmers were using punch cards to write programs. To save space on the card, and ultimately in the computer, they decided that two digits were enough. This shouldn't have been a problem until date calculations were involved. Storing dates as two-digits would have been fine, if it was storage alone. However, once date calculations were involved, the problem of the myopic two digit storage reared its head.

But the seriousness of the problem was seriously exaggerated.

So why are business applications notoriously badly written? Is it a lack of specifications? Is it a lack of expertise? Is it a lack of planning and thinking about more than the immediate problem? There's a bit of each of these elements, but not really. I believe we're still writing software applications the same way we were writing them twenty years ago. But the problem has been exacerbated by the ease at which its possible to write computer software. The tools make it so easy to write software that anyone can do it. Software development experience is no longer required to build software and as such, most software is built without software development expertise. The growth of fourth-generation programming languages, English-like syntax for querying databases, user-interface pre-built objects and development frameworks has moved software development from the hands of computer nerds directly into the arena of the hobbyists and into the savvy business person. It's no longer necessary to hire a professional to build that database package. A few dollars invested in Microsoft Access and you have a platform to build software.

It is said that 90% of the world's buildings are built without Architects. Clearly the large structures require Architects, Engineers and other professionals. However, the remaining 90% that we live in are built without Architects. And that's fine. Building knowledge has become a general commodity. The tools and the materials have become standard. There's a way to build a wall, to put in a kitchen, to open up a patio. Later on, if you want to renovate your basement, add a bathroom, a bar and extend the lighting, it's easy to see what's been done and continue on. Software development is starting to look like this. The development tools are there for anyone to pick up and start coding. There are materials, or objects, that you can purchase so that you don't have to spend a lot of time actually coming up with algorithms. The algorithm is the basic building block of the application. Everything else isn't really necessary.

Here's a technology example. It used to take a long time to build a website. A lot of time and expertise. Specialised knowledge of Hypertext Mark-up Language (HTML) was required to build even the simplest page. It wasn't as easy as starting your word processing package and typing away. Today's content managers do not need to know any HTML at all. There are software packages which do all the layout work for you. But that's not all. The technology to set up websites is now available at the click of a button. Should you choose not to install anything, you can purchase web presence for less than five dollars a month! The problem of maintaining a website isn't a technical problem any longer. It's a content maintenance issue. Keeping the content fresh for your visitors.

The problems that are plaguing software development have crept into the world of website development. It's like the Millennium Bug of simply putting together a solution without stressing too much about the maintenance issue. But I understand that in this world of limited budgets trying to make development flexible could be seen as a waste of resources. But there is a balance. With the frameworks that are available, there's no reason not to invest in learning how to use them properly and developing software that fits within the limitations of the framework. Whether it's a commercial framework or an open source one. Each framework comes with its own limitations. No solution does everything for everyone and even though you can achieve most of your goals with 80% of the frameworks out there you shouldn't think that you can do everything the same way with all of them.

As long as the framework is well designed, well thought out and well supported. And as long as business developers learn how to use the particular framework, without taking short-cuts. And as long as modular development is kept truly modular. Then perhaps a similar Millennium Bug won't happen again. And I'm not talking about a date problem. That's been covered. But all this nonsense about narrowly defining interfaces and specifications. Hard-coding things so rigidly and making data requirements so fixed that a maintenance fix ripples through the entire system. Those things won't happen.