Making Good Software

A blog by Alberto G (Alberto Gutierrez)

Written by Alberto Gutierrez

August 11th, 2009 at 6:20 pm

For god’s sake! Keep it simple!

with 17 comments

The simpler the better

The simpler the better, that’s something that we usually forget when we are developing software, lots of times we are tempted to use design patterns/frameworks/technologies/tools… without considering other simpler and less fancy options. If there are two ways to implement something and if they are equally functional and don’t add any repetition to your system, pick the simplest solution.

Considerations for not adding complexity to your project

If all you have is a hammer, everything looks like a nail

This is a common bad habit in developers that have just learn something new and they are anxious to apply it. Suddenly everything fits this new technology/tool/framework… Here are some examples:

  • ESB: “Let’s communicate the backend layer and the UI layer of this desktop application through the ESB!!!
  • Spring: “I have to create the class car, and it has 4 doors, I will better assign that dependency through Spring!!!!”

Because you can, it doesn’t mean you should

This is common in senior developer that are eager to show how advanced their designs can be. Example:

  • Abstraction: “The board class for this chess game software is too rigid. I will change it so that it will be a dynamic 2D grid which will allow us to create chess boards of 12*12, 4*6, or any other arbitrary dimension”

The more things that can fail, the more things that will fail.

There’s something that every developer must always remember. We always make errors. The number of errors we make is proportional to the number of things we develop and their complexity. So the safest path is not to write code at all or not to add complexity.

The more prepared is your code for change, the more difficult is to change your code.

This is a paradox which I believe I read in a Kent Beck book, (I think it was in “Xtreme programming explained”, if someone could please confirm this in a comment I will appreciate it very much).

It is a common scenario when a developer proudly shows some code and explains that because of his design, any future changes related with his class can be handled through configuration. Three months later, the first change request not only shows that the current code needs to be changed, but because of over-engineering, extra effort in refactoring is going to be necessary.

Add complexity if… makes things easier!

I hope I am not sending the wrong message with this post, I’m not saying that using frameworks/tools/new technologies… is bad, I’m saying that if not used appropriately the complexity they bring takes over any flexibility they may offer. So the key is to know when to use them. Here you can find three tips that may help you.

Use them to get rid of some duplication you have in your code.

This is one of the most legitimate causes to add a tool/framework/technology to your project, duplication makes your code maintenance a nightmare.

Use them because of the flexibility they provide

Spring, Hibernate and other frameworks are examples of frameworks that are great when you need flexibility.

Use them because is easier to use them than to implement their functionality by ourselves.

If you need a unit testing, don’t write your own, use any of the xUnit or TestNG, for example.

17 Responses to 'For god’s sake! Keep it simple!'

Subscribe to comments with RSS or TrackBack to 'For god’s sake! Keep it simple!'.

  1. Well, I understood your point of view, and I agree with it. Once I was called to improve a simple sales website (in Java), and it was made using nothing more than 17 frameworks!!! I seriously wanted to kill the developer!

    When I asked him why he used half of the frameworks, he simply answered: “I learned at school, and thought it was amazing, addinbg lots os capability to the system, so I used all of then”.

    And now, this is the site: when you want to change something as simple as a menu item, it gives a lot of unnecessary headache.

    Alys

    12 Aug 09 at 5:31 am

  2. Good article. Years ago, I came up with the following saying regarding programming:

    “If it’s getting complicated, you’re doing it wrong.”

    This philosophy has served me well.

    Peter Jagielski

    12 Aug 09 at 5:43 am

  3. Everybody agrees that simplicity is better than complexity. The problem is, we all define simplicity in different ways. I’ve always favored KISS and thus am sick and tired of colleagues who pull in frameworks left and right – a trend particularly witnessed in Java.

    The big question is, how does one go about convincing others when the obviously don’t share the same notion of simplicity as you?

    Casper Bang

    12 Aug 09 at 9:32 am

  4. Sorry about the bad English.
    It is a big problem to reach a common ground in what is simplicity, or how simple is the simplest. I’ve had cases in which the system was over-engineered to the point of being hard to maintain, but also had witnessed cases in which a complex part of the system was under-engineered so it was easier (and cheaper) to throw that whole module away and spend a couple of months redoing it.
    It is easy to acknowledge that we need the simplest solution. But can be very hard to define what is this solution.

    Renato Soffiatto

    12 Aug 09 at 9:21 pm

  5. [...] For god’s sake! Keep it simple! Making good software (tags: programming) [...]

  6. KISS is a valuable premise to go by.

  7. [...] Visit Article [...]

  8. [...] Visit Article [...]

  9. [...] Visit Article [...]

  10. [...] Visit Article [...]

  11. [...] Visit Article [...]

  12. simple is good. nice article.

    erkasoft

    13 Sep 09 at 3:32 am

  13. [...] Visit Article [...]

  14. I definitely enjoyed this article. I found this part somewhat dubious, though:

    “Use them because is easier to use them than to implement their functionality by ourselves. If you need a unit testing, don’t write your own, use any of the xUnit or TestNG, for example.”

    I think a lot of frameworks/libraries can be added to a project in the name of it being harder to implement something by hand, and those frameworks could add a lot of complexity that isn’t needed.

    I think using a framework because it is easier than coding the functionality yourself can conflict directly with other points you made:

    “The more things that can fail, the more things that will fail.”

    “The more prepared is your code for change, the more difficult is to change your code.”

    Do you have any further advice in this area? How to resolve these conflicts?

    Zachary Johnson

    14 Sep 09 at 8:39 pm

  15. I’ve been fiddling with a few new frameworks (L2S, L2E, etc etc) and have suddenly woken up. What is it i’m trying to do now, that I wasn’t doing 5 years ago? Why do I need to use these over my dataclasses and domain model??? Does this not work anymore cause we are in 2009 and MS have a brand new designer to show off?????

    The answer, nothing. The problems are still the same.

    Whats happened in my opinion is everybody including tools developers are wanting to come up with the majic framework that does everything and base a whole load of junk theory around it. What you end up with is you have this huge framework, complex classes and hierarchies, all to do the same thing, which lets face it is working with a back end database in most cases.

    Dont get me wrong, design patterns are good, and i’m a keen advocate of good OO techniques, but we’ve all forgotten the art of writing simple, clean, optimised, and fast code in my book, and rely too much on out the box frameworks.

    X X X

    Walt

    9 Oct 09 at 1:53 am

  16. [...] 或者,你可能知道更好的說法是:「保持簡單、愚蠢!」(Keep it simple, stupid! (KISS))。沒有必要的就捨棄吧,因為記住:「事情若有可能出錯,那就一定會出錯」(上述第二點)。 [...]

  17. [...] For god’s sake! Keep it simple! – Alberto Gutierrez provides an insightful post on something dear to my heart: keeping software simple!  The simpler the better [...]

Leave a Reply