Friction and the software architect

Scientific American’s article, Make Technology–and the World–Frictionless, describes user experience design wonderfully but never calls it that. Actually, they describe the evil opposite of user interface design. They call it friction. Friction is making things harder than they have to be for others: be they your customer, viewers, or constituents. The writer describes examples of friction in both the retail market and politics.

This idea of friction can be expanded much more and I thought of examples in the design of frameworks, coding languages and APIs. There are several ways to add or remove friction for the software developer. One way to lower friction is to make sure that everything makes sense. There are common models for organizing code that attempt to bring an understandable structure to code. Some examples are object oriented, model/view/controller, and service oriented programming. Another way to lessen friction is to reduce the number of magic strings that have to be memorized. This can be done by using constants instead of numbers, strings, or flags that need to be memorized. These constants need to be extremely simple (LogEventLevel.DEBUG) or available via code hinting within the IDE. Another way to reduce friction in programming is to use conventions. If there were twenty Java classes, each with a String property called, title, most of the classes will probably have a getter method, String getTitle(). And most the classes that allow this property to be set will have a setter method, void setTitle(String value).

I consider the language, Perl, to be an example of how friction can be removed from coding. But, perversely enough, the stripping of friction can increase friction. A great way to decrease friction for a person coding in a language is to provide several different ways to accomplish the same task. Perl does that. Another way to help the programmer is to reduce the amount of typing that needs to be done. Perl does that as well by using several implicit variables that don’t need to be referenced directly to use. The increase of friction in Perl is when one person has to edit the code someone else has written. The very things that have reduced friction have made it hard to read someone else’s code.

I tend to believe that the software architect’s role is to Keep It Simple Stupid for the other developers. Many times that means adding complexity to the architecture.

For example, when I write code I try to never trust that someone else’s code will do what they are supposed to. For me, that means always verifying the arguments that come into a method. If someone provides null for an argument that really never should be null I throw an illegal argument exception and say which argument is the offender. Not doing that can be a big problem. If a value is not verified, it is easy to pass that same null value into another method, which does the same, which does the same. Finally, an exception is thrown and the programmer ends up with a NullValueException and a long stack trace with no idea what value was the culprit.

There is an art to writing a good framework or API. And a large part of this art is to consider the user experience design. It is not enough to be clever. It has to be usable.

Comments are closed.