Programmer Musings

BPGB: YAGNI Overdone

One of the design ideas that came out of the early days of the agile movement was YAGNI. As I have written before, this idea is push back against the tendency of many programmers to over-engineer or over-complicate our designs. We normally use some variation of the flexibility argument to justify this tendency. In fact, it's often driven more by being impressed with our own cleverness.

Many very experienced programmers have always been aware of the need to simplify designs. But, not all of us were that experienced. In the early days of agile, the YAGNI principle was new enough that it made a good shorthand for less experienced programmers to learn to rein in their design exuberance.

A Good Idea Taken Too Far

As with any idea, eventually people begin to apply the principle without the supporting experience or history and the result is dogma. I have seen people create overly simplistic designs in the name of YAGNI, even though a slightly more complex design is obviously needed.

An Example: Database

For example, let's say that we are going to build a system for tracking patrons to a library, including their book borrowing history. For any library larger than a single shelf, we are obviously going to need to use a database of some sort.

For the YAGNI fanatic, it might seem reasonable to start with a flat file and only change to a RDMS when we actually have enough records to matter. They would then push back against the RDMS solution as long as we could possibly do the work in a flat file.

The obvious downside is that a large amount of code will be needed to implement features for the flat file, that are already supported by the database. This means that we will write extra code that in the best of cases will be thrown away as soon as we change to the right technology. Worse, the system might end up depending on some of the side effects of the simplistic solution that are hard to do with the better solution. Now we'll need extra work to fix the better solution.

An Example: Templates

If you are working on a web-based system, you learn quickly that much of your output will be wrapped in boilerplate HTML for display to a user. Most languages support at least one template library for merging data and text to generate output. People that have never used a template library, or have had a bad experience with one, often decide that templates are a YAGNI issue. After all, what could be easier than just writing text to the output or a file?

The result of YAGNIing the use of templates is usually one of two approaches. The first ties the output tightly to the actual code doing the work to the point that changing the output may modify the functionality of the code. The other approach ends up growing an ad hoc, crippled, half-way templating system that is specific to this code base.

Conclusion

In both of the examples above, the issue revolves around not thinking ahead. The YAGNI principle was intended to avoid thinking too far ahead. It was never intended to keep you from thinking ahead at all.

In the library example, if you are writing code for a library of a dozen books and five people, a flat file approach is probably fine. Moreover, the problem may not be worth the overhead of running a database server.

In the template example, if you are writing a single page webapp that is a simple report, the time to learn a templating system may not be worth while.

However, if either example moved beyond the most trivial example, the more advanced solution is not a frivolous complication. In both cases, You Really Are Going To Need It. Misapplying YAGNI in this case is just generating pain down the road.