Bozhidar Bozhanov

About Bozhidar Bozhanov

Senior Java developer, one of the top stackoverflow users, fluent with Java and Java technology stacks - Spring, JPA, JavaEE. Founder and creator of Computoser and Welshare. Worked on Ericsson projects, Bulgarian e-government projects and large-scale online recruitment platforms.

KISS My YAGNI

We are all familiar with the KISS (Keep It Simple, Stupid) and YAGNI (You Ain’t Gonna Need It) principles. And yet, overly complicated software is everywhere.

Let’s use an application server. Definitely. We can’t go without distributed transactions. And a message queue – for the sake of decoupling. Oh, our business logic is likely to include a lot of business rules, let’s go for a rule engine. And an ESB, definitely an ESB – how else will we distribute our multiple modules without making them interdependent? Database? Oracle, of course. But also CouchDB and Cassandra, because relational databases are not good at some things and we will need very high performance. And we need a couple of additional layers. Some facades here and there. And modules – we just shouldn’t have a monolithic application, how else will we be able to reuse our components? You know, let’s try OSGi, it will suit us. Did I forget web services? SOA is so important. And the ESB requires it anyway.

Even if you don’t have designated architects, this is the sort of thing that happens. And each of the things has some seemingly legit reason to be there.

No. YAGNI. You are most probably building business software that will be used by not more than a few hundred users simultaneously. It is probably going to include some business logic and a lot of requirements for reports and statistics. And you don’t need any of the above in order to make a functional, easy to maintain piece of software.

Am I contradicting myslef when saying you should leave technologies and frameworks out, when I previously insisted that frameworks are there for your good and decrease the complexity of software? There’s nothing contradictory. And here’s why: if written properly, software can easily change.

If at some point it turns out you really need a message queue – add it, and replace the synchronous calls in the code with sending a message. If your postgresql/mysql does not perform well with the amounts of data, switch to Oracle. If you start having millions of users, consider Cassandra. Then simply rewrite a couple of DAO classes and you are done. If it happens that you need to integrate with many 3rd party software within the same system, research ESBs. If you realize you copy-paste functionality across projects, extract the common pieces into reusable components.

But not before the need arises. Because this architectural complexity makes it harder and slower to iterate, especially if not everyone on the team is familiar with all the technologies.

Am I advocating for laziness in planning? Isn’t our previous experience enough to let us decide in advance what will be needed? Yes, but only given enough data. And in the beginning of a project you almost never have it.

There are two types of “things” we know we will need. Firstly, utilities. Tools that simplify a task we know we will be doing. An ORM, for example, can often (but not always) simplify our data access. A dependency injection framework can simplify the way our pieces of code interact. And secondly, subsystems. A message queue, a NoSQL database, an ESB are subsystems in a way. They are not intrinsic part of the application, they aren’t tools. They add complexity to the development, configuration, deployment, and it’s our job to estimate whether they will really be beneficial and whether the tradeoff is worth it.

There’s a fine line between the “do-everything-yourself” framework denial attitude and the YAGNI principle. And it is common sense. That’s where our experience comes into play – deciding what are the best tools for the job, and not what tools are cool to use or “probably could help at some point”.

When someone comes to me and says “Let’s use X for Y”, I say: “No. Let’s keep it simple for now. Our existing stack can cover that”. The result is – simpler software. Easier to maintain, easier to introduce new people to. And yet functional.
 

Reference: KISS My YAGNI from our JCG partner Bozhidar Bozhanov at the Bozho’s tech blog blog.
Related Whitepaper:

Software Architecture

This guide will introduce you to the world of Software Architecture!

This 162 page guide will cover topics within the field of software architecture including: software architecture as a solution balancing the concerns of different stakeholders, quality assurance, methods to describe and evaluate architectures, the influence of architecture on reuse, and the life cycle of a system and its architecture. This guide concludes with a comparison between the professions of software architect and software engineer.

Get it Now!  

2 Responses to "KISS My YAGNI"

  1. hello i am currently studying masters and i made project based on dna layout and i have to create software tool for that will u plz guide me how to start to make software.right now i m making small codes but dont know how to merge all this code all in one
    waiting for your reply
    Thanks & Regards
    Deepak Gohil

    • Nishanth says:

      Dear Deepak,

      It is a common fault that students, especially from India makes , they think all the people with technology blog are people who teach you how to do student projects. There are many institutions there to help students on projects right?

Leave a Reply


5 − five =



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.

Sign up for our Newsletter

15,153 insiders are already enjoying weekly updates and complimentary whitepapers! Join them now to gain exclusive access to the latest news in the Java world, as well as insights about Android, Scala, Groovy and other related technologies.

As an extra bonus, by joining you will get our brand new e-books, published by Java Code Geeks and their JCG partners for your reading pleasure! Enter your info and stay on top of things,

  • Fresh trends
  • Cases and examples
  • Research and insights
  • Two complimentary e-books