Core Dump

I’ve posted before about the idea of treating our legal system (legal code) like a computer system (computer code):

Our legal code is almost entirely like an entire operating system written in undocumented Perl.

1. There are no hints as to what any part of it is supposed to do and it is written in a language that to most people looks like line noise.
2. Every significant patch is applied by adding an additional Perl module that overrides an existing method in an existing module, replacing all of the code in that method with a complete new copy of the method that is almost identical to the old one but adds or removes a backslash in a single regular expression.
3. The entire core logic was written in a crunch session by a bunch of geeks locked in a room together and forced to design it by committee.
4. The application was a rewrite of another application that never really worked well in the first place.
5. Every function name is chosen explicitly to provoke an emotional response in the developer, e.g. thisFunctionSucks() or callMeNow().

Although that was somewhat tongue-in-cheek, there was a certain grain of truth to it.

It seems that I’m not the only one to think this – and indeed, someone has taken the idea even further by applying systems design principles to the new health care reform legislation that the US Congress is working on at the moment.

Bruce F. Webster writes:

On the occasions where I have reviewed the actual text of major legislation, I have been struck by the parallels between legislation and software, particularly in terms of the pitfalls and issues with architecture, design, implementation, testing, and deployment. Some of the tradeoffs are even the same, such as trading off the risk of “analysis paralysis” (never moving beyond the research and analysis phase) and the risks of unintended consequences from rushing ill-formed software into production. Yet another similarity is that both software and legislation tend to leverage off of, interact with, call upon, extend, and/or replace existing software and legislation.  Finally, the more complex a given system or piece of legislation is, the less likely that it will achieve the original intent.

He then goes on to talk about some “design flaws” in HR 3200 – otherwise known as the “America’s Affordable Health Choices Act of 2009.” (Brings to mind point #5 from the “Legal System as a Perl OS” quote from above, doesn’t it?)

Bruce then goes on make a point which is basically the same as point #2 in the “Legal System as a Perl OS” quote above:

Much of HR 3200 makes piecemeal modifications to existing legislation, often with little explanation as to intent and consequences.

Or to put it another way, entire sections of HR 3200 do nothing other than override some existing legislation in some incredibly small way, which will (presumably?) have huge (and in all likelihood, unintended and unforeseen) effects – much like how adding or removing a single backslash from a regular expression can have huge (and often unintended and unforeseen) effects on its pattern-matching behavior.

Bruce’s entire article (it’s the first of a 3-part series – as I write this, only parts 1 and 2 are done) is well worth reading – and in fact I highly recommend it, even for non-programmers.

Of course, if you ask me, I really think all legislators should be required to take a programming course or two – because, as I’ve said before (in my “A Programmer’s Perspective on Politics” article), laws are effectively the “operating system” of our society… and right now, the people writing our society’s “operating system” don’t seem to be particularly good programmers!!

It’s only natural to wonder why, after all this time and our collective experience, that we still produce buggy, brittle software that breaks and crashes. It’s also only natural to point at “software engineers” and then the other kinds of “engineers” – as in, the people who build bridges, skyscrapers, cars, planes, etc. – who can build things that work for years and don’t (generally) break down and crash, and ask “why can’t we do the same thing with software?”

To answer that question, it’s important to make a distinction between the physical world of bridges, skyscrapers, planes, and such, and the “thought-stuff” world of software.

While software is, to use the words of Frederick Brooks in The Mythical Man-Month, made purely of insubstantial “thought-stuff,” it is, ultimately, made by man – and as man is fallible, so to are the things that he creates. (After all, some bridges fall down, some skyscrapers collapse/leak/shake in the wind, and some planes crash.)

There’s also the “layer” aspect to keep in mind – software may be “thought-stuff,” but it doesn’t exist purely in a vacuum. It relies upon the perfect function of millions (or billions) of tiny, often microscopic physical components, which have been engineered with great specificity and tight tolerances. A few cosmic rays (or a clumsy user pulling out a cord) can screw up the perfect balance of all these components in unimaginable ways – sort of like pulling out the main support for a bridge, or blowing out the tire of a car. (Or, perhaps like having a few large birds fly into the engine of a plane!) When these sorts of things happen, the system – be it bridge, plane, car, or computer – fails, often spectacularly.

So, it’s less accurate to think of a computer system (hardware and software together) as being like a bridge, and more accurate to think of it as being like a giant clockwork mechanism – a huge Rube Goldberg-type device – with hundreds of finely inter-meshing gears and sprockets. If just one gear pops out of place, or one sprocket cracks a tooth, the system stops working properly – perhaps just a little bit, or perhaps so much so that more gears are forced out of place, and more sprockets are broken, until the entire thing collapses in a pile of ruin.

To carry the bridge metaphor in the other direction (as it were), it might be more accurate to think of a computer system as being like a bridge that not only functions like a bridge (gets people from one side to the other), but also functions as a musical instrument capable of producing both classical, jazz, and electronic/techno music; predicts the weather; washes your clothes; generates electrical power; can be quickly reconfigured into a skyscraper home for people or a hospital, as needed; can float up and down the river to a new crossing (dynamically expanding or shortening its length as it goes, of course); and can also fly, carrying everyone on it to a new river, with new road signs that instantly match the new language and traffic patterns of the new location. It also has to do all this while not disturbing the environment around it, while simultaneously accepting any impact its environment puts on it, even if such impact might cause it to function in a manner contrary to the one for which it was designed.

If you were to try to build a physical bridge to do all of these things, it would probably break in much the same ways that software does.

To use a different analogy, consider the difference between a typewriter (a machine designed to do just one thing – type words) and a computer. No one would argue that the computer is a more reliable typing instrument – after all, the typewriter is fairly simple, and because it is designed to do just one thing, it can do it well. Also, when the typewriter fails, the cause is generally immediately apparent (e.g., out of ink ribbon) and can easily be understood – and fixed – by the user.

On the other hand, the computer – while on the surface just the same as the typewriter (keyboard on which you type words), is infinitely more flexible. There is almost an infinite number of other things that the computer could do in addition to typing – it could play music, calculate your taxes, control millions of tiny light-producing elements to display an interactive 3D environment – or a photo of your dog, talk to you using a synthesized voice, control complex machining equipment, participate in a global network, and almost anything else you could imagine.

When you consider that, it’s no wonder that computers have so many ways in which they can break. It’s exactly because they are so flexible that they are so fragile at times – their flexibility is their greatest strength, and at the same time, their greatest weakness. Because they are so generalized, getting them to do any one specific thing involves a lot of re-building of concepts (we call them “metaphors” in the world of software) just to get any useful work done, never mind actually taking care of the main task at hand.

In the end, software breaks because it (and the computers on which it runs) are general purpose machines which we ask to do an enormous number of things (some often contrary to one another!), and even though we might only be asking it to do something simple at the surface (e.g., type a few words onto the screen), in reality there are innumerable hidden complexities involved in getting a general-purpose machine to do something so specific (and, we would hope, do it well) that it’s only natural that there will be errors – both human induced and artifacts of the system itself.

In other words, softare breaks because computers are fantastically flexible general purpose machines that, by their very nature, require complexity in order to do anything specific – and no layers of abstraction, big-M Methodologies, frameworks, or whatever else we come up with – are going to change that simple and immutable fact.

Programming is all about communicating.

Let’s face it – when you really break it down, programming is just a very specialized and highly technical form of communication. It’s communication between the programmer and the computer (or compiler) of course, but it’s also communication with other programmers and with end-users of the software.

So it naturally follows that to be a good programmer, you need to be a good communicator. You might even argue that a good programmer is by definition a good communicator.

Now, we know that the only way to become a better programmer is to program – that is, you get better at programming by programming more. Experience, in other words, counts for an awful lot, and is a wonderful teacher – better than any book or school.

But how do you become a better communicator?

One way to improve your communications skills is to start a blog (which I’ve written about before), and that’s all well and good, but blogging can only take you so far – it is, by its very nature, rather one-sided; you write, other people read (and sometimes comment).

Another way to improve your communications skills – which I have found to work very well myself, and which might be very beneficial in these troubled economic times is, ironically, to work from home.

It sounds crazy – how can isolating yourself at home improve your communications skills? Won’t you be communicating less? How can this possibly work?

I’m not entirely sure of the answers myself, but my theory is that it’s a bit like learning to swim by being thrown into a pool – you are forced to learn. And when you work from home (or work remotely), you sort of are forced to become a better communicator.

Think about it: suddenly, you can’t just walk over to someone and ask them a question – you’ll have to use email, IM, or the phone. And since you don’t have all the wonderful subtleties of facial expressions and hand gestures, you’re going to have to learn how to communicate all of that clearly and concisely – probably in written form, although over the phone works too (at least then you get the benefit of being able to use “tone of voice”). And for a programmer, there is no greater skill than that of being clear and concise – after all, the best code is that which is clear in its intent and concise with regards to its form. (If code isn’t clear and concise, it’s no better than “spaghetti code.”) 

In a way, it’s like being deaf or blind – you learn to use your other senses even more to compensate. So to make up for the lack of direct, person-to-person communications, you develop your writing (and phone) skills to an even higher level to compensate. You learn to:

• Eliminate ambiguity and write (or speak) clearly and to-the-point
• Get to the point quickly so as not to waste people’s time
• Structure your writing (or speaking) for maximum effect with minimum effort

All of these things help make you a better communicator – and by being a good communicator, you’ll be a better programmer.

Unfortunately, working from home has an awful stigma attached to it – people look down on working from home – which is truly unfortunate, as there are so many benefits. Of course, it’s true that working from home isn’t for everyone – there certainly are types of jobs where it’s simply not an option. But those reasons should be integral to the job itself, not artificially imposed from the outside – for example, a cashier can’t work from home, for obvious reasons. But most office workers – and especially “knowledge” workers, like programmers – could work from home without any trouble. The only limiting factor is really the organization’s willingness to allow it.

On the other side of the coin, there are of course some people who just can’t handle working from home – people who lack the self-discipline to focus on their work while at home, or who don’t have a “space” in their home to work from in the first place. While there’s not much that can be done for the latter problem, the former should be easy enough for any good programmer to overcome. After all, ours is a job that requires focus – if you can’t focus, you have no business being a programmer in the first place.

It’ll be interesting to see if more companies begin to embrace the idea of working from home in the coming years. The economic benefits from it can be great – the company can spend less on office space and the employees can save on gas and commuting costs. The incidental costs of good Internet connections and maybe some IT infrastructure to support remote workers is miniscule in comparison. And as for the stigma associated with working from home – well, I can only hope that it will erode with time.

Lately I’ve been doing some work on a desktop application that uses a database to store things, and I’ve run up against an age-old question:

To Delete, or Not to Delete?

There is a school of thought that says if you’re going to store things in a database, don’t ever delete them – just flag them as “deleted” or “hidden” and don’t show them unless you do something special. After all, disk space is cheap and that way you can save yourself from embarrassing accidents where you accidentally delete something you didn’t mean to (even the recycle bin can’t save you from every accidental deletion, after all).

Then there is a different school of thought that says if you’re going to delete something – really delete it! Don’t lie to the user and “hide” it and make the user pay the penalty of the disk space/performance overhead/etc. for things they think they’ve gotten rid of permanently. (There’s also an issue of data privacy to consider here as well – if you don’t delete things, and those things contain sensitive information – say, passwords, social security numbers, etc. – is that “right?”)

I’m mostly in the 2nd camp – if I want things to stick around after I’ve deleted them, I’ll explicitly allow for it, though either a backup system (Mozy) or version control (Subversion). Otherwise, when I delete something, I expect it to be really deleted!

Of course, in keeping with the idea of “strong opinions, weakly held,” I do have to consider the possibility of going the other way. And honestly, it’s a hard decision to make. There is no “right” answer – there are trade-offs on both ends.

Which camp are you in – the “keep everything” camp or the “deleted means deleted” camp?

Although all the “cool kids” these days seem to be writing web apps, and the word “cloud” has taken on a new meaning that is sure to confuse meteorologists and normal people alike, I still think that desktop apps are very important. Maybe even important enough to deserve a little more attention than they’ve been getting lately (living, as they do, in the shadow of the buzzword friendly “web app”).

Now, I’m not deriding web apps here – I use them, too! But let’s face it – the web was not designed to be an application. Look up the history of what hypertext means and you’ll see how far we’ve had to stretch it to get to where we are today.

Even the very best web apps tend to spend a lot of effort to look just like a desktop app. When the lazy programmer in me sees this sort thing, it causes me to develop an unhealthy twitch (in minor cases) or curl up into a ball in the corner (in extreme cases), muttering something about “code reuse.”

Of course, this is just a generalization – there are web apps that have absolutely nothing in common with desktop apps – take Google and Twitter, for example.

But even truly unique web apps still end up tied to the desktop in one way or another. I use Google all the time; but most of my searches happen through the “search” box in Firefox. I use Google Notebook, but I get to it through a Firefox add-in. I use Twitter, but I do so through a client (I’m currently using Witty Twitter, but there are literally dozens and dozens of clients out there).

Sometimes I worry that we focus too much on web app design, to the detriment of desktop app design (UI design in particular). Web apps are cool, sure, but the desktop app is still “king,” and it’s not wise to ignore the king!