Keep It Simple, Stupid (!)
Friday, 9. May 2008, 15:34:21
One of the most successful principles of engineering, including software development, is KISS = Keep It Simple, Stupid. (I sometimes think of it as Keep It Simple, (you) Stupid!). Here are a few of my personal experiences with this principle.
Last year, a few co-workers developing a ticketing project came to me asking for advice regarding a role, permission and resource based access control system. The presentation of the requirements took about 30 minutes, and I was still confused on some points. Therefore, I stopped the discussion after the requirements presentation, asking them if the customer knows how intricate and difficult it is to define such a system. I told them that no matter which bright hacker they would have as consultant, the effort required will be immense. I mean, its complexity was similar to the Windows implementation of permissions. My message was, basically, keep it simple.
Talking about Windows, does anyone really understand Windows permissions?
For example, can you tell me what “Special permissions” are about? Did you ever see the advanced permissions? What is “Write Extended Attributes”? Honestly, to me, it makes no sense. I've never passed the phase where you create some users, add them in a group and give full control to the group on specific resources. The whole thing is too complex, and it's not really useful for most users.
Contrast this with the Linux way:
Not only you can read and understand it in 30 seconds, but you can also relate immediately to what it talks about. It's useful, it's usable, it works. You don't have to think about whether you should:
inherit from parent, reset permissions, or overwrite them.
Another example is what happened about a month ago. We were discussing the GUI for editing a number of items organized in a hierarchical structure. Trouble was, save and cancel actions had the potential to create strange side effects. You would open a popup dialog, edit something in it, save it and the question was if all the items needed saving at that point. If not, then the referential integrity was not preserved. If yes, you saved the items from a popup who was supposed to save only the thing you edited in it.
After throwing a few ideas, we realized that there's a simple way to solve it: automatically and always save everything in background, like Gmail, Makagiga and other modern applications. This not only solves the referential integrity problem, simplifies the logic of the application but also proved to have benefic side effects in the code. A perfect example of KISS.
Another example is Mantis. Mantis is an incredibly effective issue tracker system, both easy to use and full-featured. It also happens to have a few touches of genius.
The first thing that made me say that was the fact that the issue number in mantis is unique, no matter in which project it is contained. This means that you can discuss with your customer about issue no. 1234566 and go directly to it, without having to navigate through the 100 projects of your organization.
Another splendid idea is the presentation of issues reported by a person who left your team. In mantis, you still see the name of the person, but it is presented with strike through, like this:Alex. Simple and effective.
Certainly, simple solutions are the most difficult to find. You need to invest time, involvement and lots of brain power into it. You need to keep reading, seeing what others are doing, searching ideas and have the courage to use them. It may not look so smart when you implement it, but it will certainly raise a few eyebrows when it's ready... Or, if you're really good at it, you'll say in the end: "I was so stupid. How didn't I think of this before?"
For anyone who's interested, here's some additional reading about how to apply the KISS principle:
Personal advertisement: I am PassionIT and I help teams develop high quality software. I train, I help improving and I work hands-on, depending on the needs. Contact me if you need help. Alexandru Bolboaca-Diaconu
Last year, a few co-workers developing a ticketing project came to me asking for advice regarding a role, permission and resource based access control system. The presentation of the requirements took about 30 minutes, and I was still confused on some points. Therefore, I stopped the discussion after the requirements presentation, asking them if the customer knows how intricate and difficult it is to define such a system. I told them that no matter which bright hacker they would have as consultant, the effort required will be immense. I mean, its complexity was similar to the Windows implementation of permissions. My message was, basically, keep it simple.
Talking about Windows, does anyone really understand Windows permissions?
For example, can you tell me what “Special permissions” are about? Did you ever see the advanced permissions? What is “Write Extended Attributes”? Honestly, to me, it makes no sense. I've never passed the phase where you create some users, add them in a group and give full control to the group on specific resources. The whole thing is too complex, and it's not really useful for most users.
Contrast this with the Linux way:
(whole article here)Every file or folder in Linux has access permissions. There are three types of permissions (what allowed to do with a file):
- read access
- write access
- execute access
Permissions are defined for three types of users:
- the owner of the file
- the group that the owner belongs to
- other users
Thus, Linux file permissions are nine bits of information (3 types x 3 type of users), each of them may have just one of two values: allowed or denied.
Simply put, for each file it can be specified who can read or write from/to the file. For programs or scripts it also can be set if they are allowed to be executed.
Not only you can read and understand it in 30 seconds, but you can also relate immediately to what it talks about. It's useful, it's usable, it works. You don't have to think about whether you should:
inherit from parent, reset permissions, or overwrite them.
Another example is what happened about a month ago. We were discussing the GUI for editing a number of items organized in a hierarchical structure. Trouble was, save and cancel actions had the potential to create strange side effects. You would open a popup dialog, edit something in it, save it and the question was if all the items needed saving at that point. If not, then the referential integrity was not preserved. If yes, you saved the items from a popup who was supposed to save only the thing you edited in it.
After throwing a few ideas, we realized that there's a simple way to solve it: automatically and always save everything in background, like Gmail, Makagiga and other modern applications. This not only solves the referential integrity problem, simplifies the logic of the application but also proved to have benefic side effects in the code. A perfect example of KISS.
Another example is Mantis. Mantis is an incredibly effective issue tracker system, both easy to use and full-featured. It also happens to have a few touches of genius.
The first thing that made me say that was the fact that the issue number in mantis is unique, no matter in which project it is contained. This means that you can discuss with your customer about issue no. 1234566 and go directly to it, without having to navigate through the 100 projects of your organization.
Another splendid idea is the presentation of issues reported by a person who left your team. In mantis, you still see the name of the person, but it is presented with strike through, like this:
Certainly, simple solutions are the most difficult to find. You need to invest time, involvement and lots of brain power into it. You need to keep reading, seeing what others are doing, searching ideas and have the courage to use them. It may not look so smart when you implement it, but it will certainly raise a few eyebrows when it's ready... Or, if you're really good at it, you'll say in the end: "I was so stupid. How didn't I think of this before?"
For anyone who's interested, here's some additional reading about how to apply the KISS principle:
-
Getting real, a free online book by the developers of Ruby on Rails, BaseCamp and other successful applications
-
The Art of Unix Programming, chapter Basics of the Unix Philosophy, a free online book about sound design, a must read for any serious software developer. If you don't have time, read at least this page; it's an amazing resource
-
The Humane Interface, a book about GUIs written by the man behind the MacOS interface, Jeff Raskin. It's not free, but you can find its summary online, along with many other essays by the same author.
Personal advertisement: I am PassionIT and I help teams develop high quality software. I train, I help improving and I work hands-on, depending on the needs. Contact me if you need help. Alexandru Bolboaca-Diaconu
WIDGETIZE
How to use Quote function: