Is Simplicity Really That Simple?

Posted on September 5, 2007
Filed Under /dev/null/ | 239 views |

I’ve been working on my pet side project, Ticklists, for a few months now and every single day I’m reminded by myself and my code that, as counter-intuitive as it seems (especially to non-programmers and non-writers), making something simple is much, much harder than making something complicated.

Experienced developers will be nodding their heads right now, possibly nodding off out of boredom because this insight is not terribly unique to them what have made complicated things and then had to maintain them, or simplify them, or worst of all, explain them. Really experienced developers will find they’ve made a comfortable living taking other people’s complications and de-complifying them. I personally enjoy deleting code far more than I do actually writing code; it’s so incredibly satisfying to reduce. Reduction is simplification.

Quite frankly anybody can make a complicated thing, that’s the beauty of complicated things. Want proof? Diff my source tree (actually no, you can’t have access). Better yet, diff your own. Chances are if you dig through all the code you’ve refactored on your current project you likely won’t find any code that was refactored to make it more complicated (”you know what this function needs? Way more over-loading and a few extra pointers. I feel like I can still understand it…”). More powerful, sure. More elegant, I hope so, but complicated? Probably not.

This observation of course begets the one question that is always in the minds of every client and every project manager driving every project in the history of time (though the smart ones are smart enough never to ask it): “why didn’t you write it that way in the first place?”

It’s a good question, a reasonable question, certainly an infuriating question when asked of you, and when asked of ourselves hopefully an insightful question. I don’t really have a good answer yet, other than to say that I seem to find that complicated is easy to implement, simple is difficult, the first pass is usually somewhere in between and I never really think I’ve made something as simple as it ever ought to be.

I suspect this has something to do with a natural tendency towards entropy, path of least resistance, and all that. I suppose software development is akin to perpetually railing against a bit-wise form of the second law of thermodynamics.

I got to thinking about all this again recently because of “Malfunctiong Vote-Counting Machines Are ALWAYS A Sign Of Corruption” by Giles Bowkett, an article I thoroughly enjoyed save for his underlying premise about the technical difficulty of building voting machine software. Giles states (troll-baits):

I think pretty much any one of the programmers who read my blog regularly could build an absolutely secure voting machine in a matter of hours, and their only challenge would be staying awake while doing something so incredibly unchallenging and therefore boring.

Here’s the thing: I don’t think so. I’m pretty certain, “put money on it” certain, that most people reading Giles’ blog could not write production-ready voting software in a matter of hours.

I am certain most could probably write software that accepts user input, tallies it, writes it to some form of storage and bleats out the results at the end. But I wouldn’t trust it to run an election. A statement like that is fraught with assumptions. Any time someone describes a software problem as “simple” or “trivial” or, my favourite, “just”, and they’re not writing ‘Hello World’ in irb, take a good hard look at their assumptions for therein lies the complexity that is being missed.

(I don’t mean to pick on Giles per se, he just happened to provide the fodder at a time when I was already thinking about complexity vs. simplicity in my own code, aka the “wow was that ever dumb” phase of refactoring).

I know nothing about writing voting machine software so I’m going to take some wild-ass guesses as to what a few situations that need handling might be. I figure my total lack of qualification makes me perfectly qualified to do this, at least that’s what Deibold keeps insisting. Anyhow,

And that’s just for a single stand-alone voting machine sitting on a desk all by its lonesome. Want 2 machines? 3machines? n machines? Now we need to a way to keep voters from voting at multiple machines, which means networking them, which means secure communications, synchronization, probably a client-server architecture and code to gracefully perform across it all.

But wait, there’s more. The server component will also have to be able to authenticate the client machines to prevent someone from spoofing a voting machine and voting often starts and ends at different times in different locations so the software will need to account for that too.

This stupid little simple voting app has gotten complicated indeed, at least moreso than I can write in a few hours, which is all a fancy way of saying: beware assumptions about simpicity. That way lies unbounded complexity. Tthe only way that simplified software can truly be written is once the developer fully understands its complexities.

Oh that’s deep.

(Incidentally, this is not to excuse the creation of insecure, corruptable voting machines. While it may not be easy it sure doesn’t fall into the “intractable” category. I agree with the basic premise of Giles’ original post. There are no valid excuses for flawed voting machines.)

Comments

Leave a Reply