Is YAGNI always a good thing?

I am not sure that YAGNI really is good practice in all situations.

A minimalistic "only do what we need to right now" approach is appropriate under a wide range of situations, but really dramatic agility and performance comes about when you have developed a set of capabilities that are well-matched to emerging requirements.

I admit that this partly comes down to luck, but it is a powerful and uplifting experience when it happens.

So, typically, the business hands us a requirements spec, and we do some analysis to plan out how to tackle the project; a work breakdown is done, tasks are created, and we work away at those tasks to make a product that meets the spec. So far so conventional. All stakeholders are focussed on the product, and really do not think beyond the immediate project, because to do so would be wasteful, right? As software engineers, we have been told that modularity and reuse are good things, so we over-engineer components according to imagined modes of variation, but because everything is being done in the context of this one project, nothing ever stands any real chance of being reused anyway, because the organizational communication channels that are required to support that reuse simply do not exist. As a result, the software ends up being overcomplicated and expensive.

There are two (not necessarily exclusive) ways of tackling this problem. The first is pure YAGNI: "do not be precious". Your work is probably going to get thrown away anyway, so do the simplest thing that works for the immediate problem. This is, I think, a healthy way of thinking about problems, but it only gets you so far. The second is capability-building, which says: OK, while I am working away on this problem, let me make a bunch of libraries so that the next time I come to the same problem, I can move faster. Each of the libraries can start out simple, but as I move from project to project, product to product, my capabilities will improve and increase over time.

This is, in a sense, the opposite of YAGNI, but has helped me out on more than one occasion, when requirements come in that fit in very well with the capabilities at my disposal. On one particularly memorable occasion, I was able to turn around a small piece of functionality in about 45 minutes that one of our partner organizations had been working on for over a month. This simply because I had tools at my disposal that were a very good fit to the problem at hand.

My point is this; unless we build real capabilities (software libraries) that provide strategic differentiation and competitive advantage to the organizations for which we work, we will be forever stuck in a cottage industry, reinventing the wheel over and over and over and over again.

So:- whilst for many bike-shedding things it might be true that You Ain't Gonna Need It, if you choose carefully, maybe for some things You Are Gonna Need It, and when you do, you will be grateful that you have a capability to hand that enables you to spin on a sixpence and get product out the door FAST.