Dubroy.com/blog

I just saw that my post Oversimplification is Confusing from a few weeks ago got posted on Signal vs. Noise. Coincidentally, I posted yesterday that things should be as simple as possible, and then some. Well, well, well. Sounds a little contradictory, doesn’t it?

As Ralph Waldo Emerson put it, “a foolish consistency is the hobgoblin of little minds.” But actually, I don’t think the two posts really contradict each other. When I talked about oversimplification, the example I gave of the Photoshop dialog box wasn’t actually a problem with oversimplification, it was a problem with not enough simplification. Or, wrong simplification — take your pick. Presumably they “simplified” the dialog box by not including a full explanation of why you would ever choose to uncheck the “maximize compatibility” box. They probably should have simplified further by removing the option altogether. Instead, they left a corner case baked into the UI. In other words, the overfitted their solution to the problem.

Maybe I should have stuck with my original title for the first post: Don’t Ask Stupid Questions.

This semester I’m taking a machine learning class with Geoffrey Hinton. The other day in class, he was talking about the balance between correctly learning a concept, and overfitting the data. Say you have a program that is trying to recognize people: an example of overfitting is if your program learns that only people between 5′4″ and 6′3″ are people, just it has never seen a person taller or shorter than that.

There’s a famous Einstein quote that goes something like: “Everything should be made as simple as possible, but no simpler.” According to Prof. Hinton, the principle in machine learning is more like: “Everything should be made as simple as possible, and then a bit simpler.”

This also seems like a good approach for designing software. Make things as simple as you can possibly bear, then remove a few features. Without fail, whatever you consider upon to be an absolutely minimal feature set, you can still remove a few features.

Today Mike and I went to see Joel Spolsky talk about FogBugz in Toronto. During the Q+A, there were two questions that I really liked Joel’s answer to:

1. Does FogBugz support cloning bugs?
2. Can FogBugz support create dependencies between bugs?

The answer to both was really “no”, but Joel said “Sure, just type ‘clone of case 123′” and “Sure, just type ‘depends on case 123′.”

That’s a perfect illustration of what I’m talking about. If someone was coming up with a list of features their bug tracking system must absolutely have, there’s a good chance they would include those two features. But specifically adding features to do those things is an example of overfitting — really, linking achieves 95% of what you need anyways, and it’s much simpler.

So my new design mantra is “as simple as possible, and then some.”

This morning Signal vs. Noise linked to a post by Paul Stovell called We are what we repeatedly code:

The best developers I know write great quality code every time they touch an IDE. This is because they realize that writing good code is something you have to practice, something that you have to do over and over again to be able to do right. They realize that writing great code is something you do all of the time, not something you save for a party trick.

I agree with him on this. But what exactly is “quality code”? Paul uses an example of a small, throw-away tool he wrote recently:

I could have written the tool as one huge Main method in a console application. Yet, instead, it’s all nicely factored. There are base classes, adapters to reduce the dependencies on the outside systems, encapsulation, interfaces, a couple of occurrences of the strategy pattern, and even the odd XML-doc comment thrown in here and there. Hell, I even gave the DLL a fully qualified company namespace.

I get what he means: write every piece of code as if it will ship. But I can’t agree with any definition of quality that is measured by the amount of design patterns you use. All the things he described — encapsulation, interfaces, design patterns — are all well and good when used appropriately, but their abundance, or even mere presence, does not indicate quality code, any more than the presence of salt and pepper indicates a good soup.

I’m reminded of my first co-op term at IBM on the SWT team. Steve Northover, the SWT technical lead, has a couple of golden rules. One of them is “that which obscures my code is bad”. Encapsulation, interfaces, the adapter pattern, the strategy pattern…all ways of solving specific problems, but also ways of obscuring your code. So many people seem to believe that adding more structure will produce better results. We see a similar pattern in government (endless bureaucracy), education (standardized testing), and business (meetings, reports, yearly reviews, middle management). These things begin with the best of intents, but often end up causing more harm than good.

In software development, there’s a growing movement of people who believe that “less is more.”

Joel raises a good point in his post Choices = Headaches. His complaint is that Vista has WAAAAAY too many options for saying “see ya” to your computer: sleep, hibernate, shut down, restart, log off, and switch user. I agree with him here. I was just thinking the other day how silly it is that there is even a restart option. It’s basically only there because of brain-dead software, and if you really, really need to restart, couldn’t you just turn the computer off then on again?

Joel’s solution is a single action, which he calls b’bye:

When you click b’bye, the screen is locked and any RAM that hasn’t already been copied out to flash is written. You can log back on, or anyone else can log on and get their own session, or you can unplug the whole computer.

He calls it b’bye, but it’s just another name for off. If you implement it the way he described though, you’re still missing a true reset option. Sure, it may be a cop-out for poorly-written software, but I think it’s still necessary.

The big-picture idea that Joel is touching on here is that more is less. Having too many options is a bad thing, because you actually have to invest significant mental effort to choose between them. Sometimes this can be enough to turn you away altogether. I procrastinated on buying a digital camera for years, because it was such a monumental effort to just learn about the choices I had. Too many choices can also make you feel belittled, because you don’t understand the differences. The menu at Starbucks has this effect for many people.

In software, adding a configuration option is the ultimate design cop-out. I’ve seen this happen many times with Eclipse since I was a developer in pre-1.0 days. Would you like to double-click to open files, or single-click? Would you like to use curvy tabs or square tabs? Having so many options makes it really difficult to find the important ones. (In fairness to the Eclipse developers, they have a very diverse set of stakeholders, and this is the only way to keep most of them happy)

What it really comes down to is having the courage to make those tough design design decisions. By removing those unnecessary options, you risk alienating a certain group of users — the people that actually want them. But would you rather by stuck in the zone of mediocrity?