Y is for YAGNI - Python A to Z

Python A-Z is a blog series about Python. Each day, I share insights, ideas and examples for different parts of Python development that match with the letter of the day. Blaugust is an annual blogging festival in August where the goal is to write a blog post every day of the month.

While I like writing code to solve my technical problems and fulfill my software needs, I don’t like writing unnecessary code. Writing something because you thought it could be useful is often — unless you learned something from it — wasteful in terms of time and effort and added complexity.

YAGNI (You aren’t gonna need it) is a principle that arose from extreme programming methodology. While I have never worked in a project or company that followed any specific methodology to the letter, this one has been fundamental in my understanding of how to build software in a smart way. It hasn’t been without its faults though: one of my jobs ended due to a big clash with management around this idea.

The principle isn’t only helpful in focusing on what to do and by extent, saving money by not spending time and money on unnecessary things, it also brings about other positive effects. it’s not only about code we write but features we design.

Code you write stays simpler because less assumptions about future are introduced early. If you write code that is easy to extend and modify, you don’t need to prepare for every potential use case from day 1.

When it comes to designing software for its users (even if that’s just yourself), building something before you have a clear need for it and idea of how it needs to work, can lead to functionality that doesn’t match the expectations and can become more difficult to change in the future to match the actual expectations.

Remember, there’s always someone who depends on already implemented workflows:

I have so often — both in commercial context and my one-user hobby projects — encountered a situation where we think something needs to be built in a specific way. Only to then build it and later learn from actual user(s) using it that it doesn’t fit the need at all or that (almost) nobody uses it.