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.
Top comments (2)
The problem is that is like saying live well and you'll be happy, the goal is not the hard part, is the how; the SW industry seems desperate to find "absolute truths", "catch phrases" that will solve everything; sadly and gladly is not that simple; you can't replace experience and good old common sense, which is hard to get and not common at all. Some decisions I've taken in the beginning of projects had taken an extra hours and avoided weeks of work later; can I always be that wise, hell no, blindly work just foreseeing the next 2m will not take you to anywhere close to the top of the mountain. Those principles are useful to keep in mind, not forget that they are important, but they are not rules, simple today sometimes is extra complex tomorrow, cheap and fast today can lead to a dead end, a very expensive and time consuming end. What is the secret to know what is what, well, no idea, and I really distrust anyone who claim they know. Like almost everything is about balance.
Extreme YAGNI can lead to the need to re-write everything for every new feature or change and extreme KISS can lead you to the st terminal, that being so extreme in that, ended very lacking in features, unnecessarily annoying to use and consuming more RAM doing much much less than more feature rich terminal emulators.
I know that balance is a non-answer but I don't think there are an answer, just experience, earned and learned; no shortcuts, no cheats, no recipes. Keep the principles in minds, follow them as you see fit.
I respect Uncle Bob for his contributions to software engineering, but I rarely agree with him because his example scenarios and anecdotal proofs for his rules are never realistic. I find myself working on more and more projects where clear requirements do not exist because the client doesn't even know what they want. They have a vague innovative idea, and we need to make it happen. We have to think ahead and identify potential complications NOW, because if I wait a month doing the simplest thing possible, I won't have time to refactor when we realize half our architecture needs to be created anew.
Granted, not everyone works on software projects like this. But even on e-commerce websites, I have had instances where my intuition told me that my team could not trust a subcontractor at all; I had a hunch they were lying and the constant refusal to share basic details with us made me even more vigilant. It turns out they were adding service layers that did absolutely nothing except add an order of magnitude worth of latency to requests and break every other PROD build. I designed my API integration framework to generate itself based upon request and response objects and a XML mapping of endpoints to objects. My strategy allowed us to remove the subcontractor's APIs entirely and communicate directly with the client. My "overengineering" took 2 days to solve the issue.
We will never know everything in software. We aren't even aware of what we don't know most times. By following patterns and idiomatic coding styles for our environment, we end up with the best we can do while someone forces the client to provide more details.