From time to time, we see someone making a feature more complex than necessary, but do you know that make simple is a principle in software development? Knowing the KISS and YAGNI principles.

When I started to develop software, I used to see many people talking about subjects like Design Patter. So, I read many books about It. As a consequence, I used to think that if I knew Architecture, Design Patterns, and other things, I would be a great developer, but how I used to thought was my error. Below I explain why.

When I started my first job, everything I used to do was complicated. A class obligatorily had a patter, A project must have the architecture "XPTO" and I loved that. I was happy when someone asked for an explanation because he/she didn't understand. I was the guy that used to complicate everything because the "Author" said this or that.

So, one day I saw someone like me. That person used to love to do just complicated things and our project were late. You may be asking yourself, how complicated? Well, here we go

• He created DTOs in the infrastructure layer and the same in the application layer. Why? Because an author said that each layer must have its own DTO. (I did not find this author, but...)
• All the devs knew very well about SQL Server or Oracle, but he wanted to use MongoDB. Why? For no reason, just because it was fashionable.
• Our coverage tests should be at 100%. He used to test until filter class from ASP.NET (Microsoft had tested this before :)).

As you can see, everything could be done in half the time, but we always used to do what he wanted because he was the project architect. Only to remember, our project was still late. So one day when our PO asked a feature to log all events from the user and our architect asks one month to do this because of "complexity" and we should do the patter "X", I exploded! :(.

Our system was very little, our company did not make money with this software, only wanted to make the customer happy to get others "problems" and make money.

Do you see this guy in your company? I see and sometimes I and you are this guy :(. Usually, when we want to make something more complex than it really is, it is because we want to challenge ourselves, prove that we are capable. Or sometimes we put many exceptions to the feature, that this feature gets more complex than necessary. For these reasons, we make things complex and not simple.

Make the simple is difficult, Steve Jobs said once a time:

Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple. But it’s worth it in the end because once you get there, you can move mountains.

For this, there are two principles, KISS and YAGNI.

You can see the kiss definition at https://en.wikipedia.org/wiki/KISS_principle

KISS, an acronym for "keep it simple, stupid" or "keep it stupid simple", is a design principle noted by the U.S. Navy in 1960.[1][2] The KISS principle states that most systems work best if they are kept simple rather than made complicated; therefore, simplicity should be a key goal in design, and unnecessary complexity should be avoided.

And the YAGNI you can see at https://deviq.com/yagni/

YAGNI, or “You Ain’t Gonna Need It” (or “You Aren’t Gonna Need It”), emerged as one of the key principles of Extreme Programming. Put another way, the principle states:
“Always implement things when you actually need them, never when you just foresee that you may need them.”

I love these principles because these help me to focus on a feature and doing just the necessary, but how can I think simple?

The first mistake, when we do not know about business value. You must know the business value, not only how to do. What does value this feature brings to the client? Will I make good money? I know that sometimes we do not know all about the feature, but you must not overload with many exceptions or things from your head (second mistake).

But in my code, how can I use this principles?

Martin Fowler in his article said a great example at https://martinfowler.com/bliki/Yagni.html. The example was two features similar but not the same, a feature was to do now and the second to six months later. But the team wanted to do the first feature already thinking in the second feature. How many times you and your team did not do that? "Let's get the code ready".

Where is the mistake?

First, you know about the first feature, you discussed this feature. The second feature you do not know everything still. Second, can you imagine the code that you will wast because you do not know everything? If did the P.O. passe a false information? If the second feature is not necessarily more? So you ain't gonna need it.

Someone can talk to me, "But in the future, I can change all the code because I did not prepare correctly". Yes, you will change the code, but now you need this code and now you know about the business.

My conclusion, if you do not need this still, not make it and if you will make, make it simple.

So I hope to help you to open your head, se you next time.