Code Simplicity

Here are some clues that tell you that your code may be too complex:

• You have to add “hacks” to make things keep working.
• Other developers keep asking you how some part of the code works.
• Other developers keep mis-using your code, and causing bugs.
• Reading a line of code takes longer than an instant for an experienced developer.
• You feel scared to modify this part of the code.
• Management seriously considers hiring more than one developer to work on a single class or file.
• It’s hard to figure out how to add a feature.
• Developers often argue about how things should be implemented in this part of the code.
• People make utterly nonsensical changes to this part of the code very often, which you catch only during code review, or only after the change has been checked in.

That’s what I can come up with off the top of my head. What are some others?

-Max

In a user interface, similar things should look the same. But different things should look different.

Why do over 75% of Facebook’s users think that the new Facebook UI is bad? Because it makes different things look similar to each other. Nobody can tell if they’re updating their status or writing on somebody else’s wall, because even though the text is slightly different in the box depending on what you’re doing, the box itself looks the same. The new Chat UI (introduced a few days ago) makes idle users look basically identical to active users, except for a tiny icon difference. (It’s also important that different things are different enough, not just a little different, because people often won’t notice little differences.)

This is an easy pitfall for developers to fall into because developers love consistency. Everything should be based on a single framework, in the backend of an application. But that doesn’t mean that everything has to be displayed the same in the UI.

This fact–that different things should look different–is actually true with code, too, but people rarely think about it, because developers are actually pretty good about it. For example, accessing a value of an object should look different than calling a method on it, and in most programs, it does. For example, in Bugzilla’s code, accessing a value on an object looks like $object->value whereas calling a method on the object looks like $object->method(). It’s not all that different, but the () at the end is enough difference for the average programmer to notice “Oh, that’s a method call that does something–it’s not just accessing a value in the object.”

All in all, consistency is really important in both the backend and the frontend of an application. But that doesn’t mean that every single thing should look exactly the same–if we took that to extremes, we’d just have a solid white page, and that doesn’t seem all that usable (frontend) or readable (backend), does it?