YAGNI – YOU AREN’T GONNA NEED IT! WHAT DOES THAT MEAN FOR SOFTWARE?

Never write a single line of code before we really know that we need it. Don’t rely on experience from other systems we’ve written. A new project is never an exact copy of the old one, or there wouldn’t be a need for it. And a software project always changes the specifications during the process. Two facts that tells us that we have to wait to write the code until we really know that it is necessary. Or we will write code that we Aren’t Gonna Need.

Waterfall or Ad Hoc? Neither!

All software is developed with a goal in mind. An end product. A vision of what we want to create. That’s the starting point. It’s this we decompose, break out sub systems and eventually create a whole heap of user stories from.

Now, this is a narrow path to walk.

To start with, we shouldn’t just sit down and just code. Sure, we will eventually get to the goal, but not without rewriting a lot of the code several times, just because we didn’t do any analysis.

And we don’t want to do it the Waterfall way and analyse everything before we write one single line of code. Likewise, we will eventually get to the goal, but not without rewriting a lot of the specification several times, just because we didn’t have all the knowledge beforehand that we get from writing and trying the code.

What we have to do instead, is to break the entire system down into small enough chunks, design and code them. And then use the knowledge we have collected about the system so far, both from the users as well as form the code itself, to design the next step.

Then there’s the bias of using skilled and seasoned developers. The ones with tons of experience. They tend to “know” what is expected because they have already done it before. This is generally a good thing. But it can also make us do things that we shouldn’t have done.

It makes us do things You Aren’t Gonna Need.

Trimming the hedge (there is a lesson to learn here)

I was out trimming the hedge. This produces a lot of waste and my experience told me that I will fill up the recycle bin as well as a couple of sacks. So, I pulled out the sacks, the sack holder, and some clamps to hold the sack in place.

Now, what I didn’t factor in was that it had been a cold spring, so the hedge hadn’t grown that much. And also, we no longer have as much hedge as we used to since we replaced one section with a fence.

But I went only on my experience. And ended up with putting the sack, sack holder and clamps back unused. I didn’t need them.

Translate the hedge trimming into software projects

Now, consider a software project. It is orders of magnitudes more complex than trimming a hedge. And that means that a human can’t possible see all the details of the entire project. We will miss the fact that there isn’t as much hedge to be trimmed, we will miss that the spring was colder. Just because there are so many other details that we fill our heads with instead.

So, if we go ahead and write all these functions that we think we will need in the future, just because we needed them last time, we’re in for some bad news. Much of that code will never be used. Or even worse, have to be rewritten because the specs changed so that the code is useless in its current incarnation. And because humans are lazy, we will shoehorn in the current code into the new specs, and the fit will be bad.

The solution is, never write a single line of code until we need it!

— Cheers!

(Photo: “clean code” by traukainehm is licensed under CC BY 2.0)