Simplicity: Keep It Simple Stupid (KISS)

I'm a huge fan of simplicity in software -- and I think its finally time to write about it.  First, let me reveal a little about myself to add a personal tone -- I'm not that smart!  Huh?  That's right, I'm not the smartest developer by any means, although I don't mean I'm stupid either.  Let's put it in perspective -- all developers are likely to be smarter than average, so yes I am "smart".  But there are many developers out there that have been far more schooled in computer science, along with algorithms and design patterns.  My background is actually pure math, with a fair dose of physics and philosophy and finance -- not computer science at all.  Thus, I really do think that I'm not that smart when comparing myself to the best in software development.

Why is this relevant to you?  Because by definition there are only so many people that can be the smartest -- the rest of us are all less than that -- in other words, "not that smart".  And while I have worked with some smart developers, I have also seen many more that are "not that smart", often more so (or is that lesser) than I!  Heck, as someone who spends a lot of time in forums and newsgroups answering questions (learning in the process myself), I can assure you that there are even some pretty "stupid" developers out there.  My point is that if you expect your software to be understood, and thus used, whether it be the external API or the internals for maintenance and extension, you really need to be targeting the "not so smart" developers too.

So what is simplicity?  Ockham's Razor says (paraphrased) that the simplest explanation that works is the most likely to be the best.  Einstein said "Everything should be made as simple as possible, but not simpler".  In software, Kent Beck defines four traits of simplicity: passes all tests, reveals intentions, no duplication, and smallest codebase.  In other words, "simple" software should do what it is supposed to do, but no more, and it should do it with the least amount of code possible, while still being easy to understand.  Finally, Martin Fowler said "... a complex design is more difficult to understand than a simple design.  Therefore any modification of the system is made harder by added complexity."  I think these sum up simplicity.

Why did I finally choose to blog about simplicity?  Because I'm seeing far too much complexity out there.  And finally, today in the forums there was actually someone trying to say his product was better than others because it was larger!  I want the opposite -- I want fewer classes and a much smaller external API so that my "users" will quickly understand how to use my product, or a simpler UI if its an end-user application.  I also want my internals to be minimal and obvious so that others (not to mention myself) can maintain and extend my software.  That last point is why I think I've been able to make a dent in the community with some of my ideas -- they get the job done and just as importantly are easy to extend when you need more than I've done!

I'm going to end here today -- and keep this post "simple".  I could add a lot more, but I think I'll make this into a series of posts instead.  That will also give some of you the opportunity to tell me what you think about simplicity, and it will probably look better in my stats.  :)

4 Comments

  • Complexity has a tendency of creeping into business requirements anyway so why add any unnecessary complexity into the code? Just look at the typical rules businesses have in their processes!



    Speaking of complexity in APIs (and without starting a flamewar!), I had this problem many times as a Java developer where many of the APIs (no matter how powerful and elegant) are just so much more complex than they need to be!

  • Paul, while I agree with your premise that simple is good; I think that calling yourself "not that smart" is perhaps duplicitous. How many "not that smart" people quote Ockham's Razor?



    It is actually your intelligence that allows you too see the forest, instead of just each individual tree. The ability to abstract is a hallmark of a good architect, and I beleive that your Maths background serves you well here, instead of the CS graduates firmly grounded in the intricacies of implementing yet another Stack, or Queue.





    Simplicity of Design.

    Simplicity of Implementation.

    Simplicity of Use.



    All of these are goals to strive for. That's why I'm interested in when Aspect Oriented Programming becomes mainstream. When you can declaratively state how your program will behave, without vomiting "plumbing" code throughout your application, then we've reached yet another plateau in our search for programming simplicity.

  • I prefer complexity, myself.

  • I have just read it blog and remembered my first steps when i tried too understand the community starter kit from asp.net. I agree with author of KISS, but i would like to add one rule that also help sometime for begginers and stupid programmers like I. It is small errors that must be in any read-to-use application. Why? Because it is one element of studing: "to find error you must learn more about structure and foundations of topic".

Comments have been disabled for this content.