What “4 Rules of Simple Design” Means to Me

About two years ago, my interest mostly focus on how to write a well performed code. I was enjoying it, I had a lot of research about it, and I love talking about it with people. Every time I wrote a code, I just jumped in to the code and type everything. “Yeaaah! I’ll write some freaking fast codes.”, that was what I thought. However, at one stage, I felt there was something missing in what I did. Something was wrong with the way I did my job (read: hobby).

The problem was I didn’t feel that I was confident with my code.

I was progressively better in writing well performed code, but it was linear with the bug amounts. How foolish I was, pushing some buggy codes to the production. What the hell!?

My habit also brought another problem. By jumping directly to the code and typed everything, made the codebase getting dirty, difficult to read, and hard to maintain. It took me a longer time to ship small feature, mostly because there are a lot of code duplications, it is unreadable, and super complicated. So what should I do?

I needed something that really could help me getting through with my confidence with my own code. Something that could help me writing a better and readable code. I just couldn’t do it myself, I needed someone to teach and guide me about it.

So, fast forwarded to the next year, I thought about moving to another company and that company should support me solving my problem. And I found my current company, PT. Kreatif Media Karya. I moved to the company 6 months ago and what I had until now just like what I expected.

KMK engineering division implement extreme programming. Owh! What the hell is that!?

It’s inefficient for me explaining it everything, so I think to have a better understanding of what we’re doing in the company with XP, this article (http://martinfowler.com/articles/designDead.html) really can depict it. It’s a long article, so please take your time reading it. I believe it will be super useful and probably can give you an interesting perspective on how you do your development.

To sum it up, change isn’t something that we can run from. We all know that changes cost us so much and these rules, can help us minimise the cost, significantly!. How can we achieve that? By making our code simple!

So let me try to introduce you to these rules.

1. Runs all the tests

We apply TDD (Test Driven Development) in our development. So, before we start writing the code, we need to remember some rules.

“Shit! There are rules inside rules. Where’s the exit? I want to get out, immediately!”

Wait, wait, wait. It is not that scary, dude. These are the rules that we need to remember:

  • You may not write production code until you have written a failing unit test.
  • You may not write more of a unit test than is sufficient to fail, and not compiling is failing.
  • You may not write more production code than is sufficient to pass the currently failing test.

For us, these rules are known as Red – Green – Refactor (the refactor part, will be explained in the following simple design rules). Just like the rules explained to you, we need to write a test first before we write the production code. Make sure it fails and then you’re allowed to write the production code. You can only write production code related to the test and make sure it passes the test.

What benefit does it bring to me?

This methodology, helped me solving my problem. I regain my confidence in writing the code. I admit that I still missed some things that allow bugs to be introduced in the system, but at least, I have a strong judgement to say : “Hey! I just wrote a bugless code because all of my tests are passed!”.

2. No duplication

“Hey! I just passed the test. So, what should I do next?”

Welcome to the refactoring realm! The first question that comes in my mind when I’m refactoring codes: “Is there any duplication code?”. Why should I remove duplication?

Let’s say I have some duplication in file A, B, C, D, E, F, and G. (That’s too many, are you a superman?)
Now, there’s a feature request that force you to make changes in part of file A which is duplicated in other files mentioned above. So what will you do? Of course! Modify all duplication in other files!


This condition is a picture of how change can cost us BIG time and this rule, remove all duplication, can save us from it, also BIG time!. That is what I get when I apply this rule. I save my self from doing useless things. The extra prize is your code base relatively smaller. How cool is that?

3. Reveals all the intention

“Hey! What actually is he trying to achieve in this code?”

I believe most of you, at least once, have asked this question to yourself or your pair. Do you want to hear the worse? I even sometimes asked that question to myself aaaand it’s the code that I write. Great, heh!?

You pay some time reading code that hard to understand and sometimes we make it even worse. We’re just wasting people’s important time, right?

So, what do I get from following this rule?

Like other rules give to me, I save my important time, moreover, I save people’s time. I put myself as a storyteller when I writing code. What do storytellers want to achieve? Of course! They want the story to be understood easily, plus, they also want to make people happy hearing their story.

From now on, I believe that I write code not for computer, but for human. So next time, please pick a good name for your variable, class name, or method name. You can save your time by following naming rules explained by Uncle Bob in his book titled Clean Code.

4. Fewest number of classes or methods

Now we arrive at the last rule. Are you still there? You’re still reading, right?

Have you ever asked yourself, whether a method you were looking at that time was really needed or not?
Have you experienced this condition, when you saw a method and it was unused and you just left it there because you were afraid that it would break the system?
Have you ever made a class containing only 1 method, just because you think that people will use it someday?

My answers for those questions are yes, yes, and yes. (Booooo!!)

This rule encourages me to keep everything simple. Remove unused class or methods and I should think YAGNI (You Aren’t Gonna Need It). By thinking YAGNI, I will careless about the future, but instead, I should pay a lot more attention on what product needs from me, today, now! From what I’ve experienced, this rule helped me making everything simple.


That shows how “4 rules of simple design” means to me. It shows me path to a better world. It helps me to be a better and more professional software engineer. And I think for you guys who are in the state like I had in the past, those rules are the solution. You should practice that and it will be better if you have a partner that guides you through it.

Hey! I just realised that I wrote a long post. I think this could be my longest post. Anyway, are enjoy reading it? Am I a good storyteller? :D


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s