Since the very beginning of my career as a software engineer, I developed a passion for clean code, especially after reading Uncle Bob's amazing book titled "Clean Code". It took me some years and a few projects to realize that being passionate about the code you write is good, but the end goal of the project is not the code, but the product itself.
Keep It Simple, Stupid (KISS)
KISS is one of the most underrated software design principles among developers. Sometimes writing simple code can be boring. No fancy design patterns used, no complex polymorphism implemented, just some lines of code in a few methods of a class that no one in the team cares about, written in maybe half of a day, unit testing and coffee or tea included. But, those few boring lines of code do the job perfectly, make the product better, and most importantly, help the product be closer to getting in the hands of its users.
You Aren't Gonna Need It (YAGNI)
Similar to KISS, YAGNI doesn't seem to be most developers' favorite design principle. It's part of human nature to try solving problems that we don't have, hoping that this makes us prepared for the unexpected. This willingness is even stronger in the case of software engineers, who are problem solvers by default. But truth is, we don't know the future and we aren't very good at guessing what's gonna happen with the code we write. We often spend plenty of valuable time creating huge levels of extensibility that can potentially bring value in the future, instead of investing our efforts in code that brings value here and now. We then end up refactoring that extensible piece of software because we simply didn't make use of it, and it also became hard to maintain with time.
Real-world Example
I recently had the chance to work for a startup for a few months, but it turned out I was late to the party. After spending a few years developing an MVP (a big question mark by itself), people realized that some services were built using some design patterns that were not the best fit for the product's needs and they must be redeveloped from scratch. After going through a round of estimations, decision-makers realized that the business is not viable anymore and the development of the product was stopped. Of course, I'm not saying this unwanted event happened just because KISS and YAGNI weren't followed, but creating an unnecessary complex code and architecture played a role in the story for sure.
Lessons Learned
To summarize, here are a few lessons I've learned from this experience:
- We write code to create a product, not vice-versa.
- Design patterns are good, but simplicity is king.
- Clean code is good. Clean code that does the job is better.
Conclusion
Software development became quite complex in recent years. New tools, libraries, and design and architectural patterns are appearing almost daily. While keeping up to date with the pace of the evolution in this world is quite important, we should always focus first on the products that we are building.