YAGNI is an unfortunate response to an inability to comprehend form. Dealing with the surface features of the problem is a typical process for beginning programmers; and, programmers crank out code pretty quickly yielding a solution for the presented problem. Unfortunately the presented problem is never the actual problem. This is the core of the real issue here. The notion that we cannot know what we will need to produce next is an admission that we’re just fixing each presented problem or request by blindly coding up a fix. It implies that we cannot know the context around any problem. It implies that we cannot design a ten story building because the first story might be wrong.

Code developed from a disciplined understanding of the problem yields a straightforward solution that really doesn’t need to change much at all over the life of the product. When I served as lead architect for a publishing company, I encouraged the developers to solve the “class” not the “problem.” Each problem, at a glance, can be quickly corrected; but given some time to reflect, the problem may be found to be part of a class of problems. A correction addressing that class means that when Marketing comes back and says, “We also need this,” the developers can simply change a configuration and produce the desired new capability.

By understanding the form of the problem, the code is tighter and the result is a solution to the full class of needs, almost all of which will eventually require effort. YAGNI proposes that this is impractical, effectively denying thirty centuries of Engineering history.