YAGNI – You Ain’t Gonna Need It – is a useful principle in software development and rework. But should it be a hard rule? I will argue that it should be a guide, not a rule. But also, that the context is a major factor in determining which view should apply.
The first and obvious context is that of a module in the application you are developing. YAGNI holds that the inclusion of routines for which you have no immediate use is at best, unproductive, and at worst, counterproductive. These ideas are not incorrect, as there are multiple costs to any code you write:
- the cost of coding
- the cost of testing
- the cost of maintaining
The second context to consider is that of a library or shared module. In either case, I am speaking of a module which will be used in multiple applications. A library generally stands apart from any particular application, being designed to provide broadly useful operations. A shared module, on the other hand, will generally have narrower scope — it may be used in several of your applications, but may otherwise be very specific to the problem domain your applications address.
While developing a module for a single application, I submit that YAGNI should be treated as a rule. You write no code for which there is not an immediate need. This narrow focus will minimize the costs enumerated above, and will help keep your code tight.
In writing a shared module, then you may rightly include routines which you can anticipate will be needed in applications other than the one on which you are currently working. A) you can anticipate using these in another application, and b) your are working in the realm where adding some routines which are very similar to others in the module costs little. You can certainly argue against doing so, but the that argument is weak.
Writing a library is a much different affair. You will usually write libraries to address a broad range of needs independent of any particular application. YAGNI applies less in the broad context of a library. You have no way to be sure what routines will be needed, since the context is the set of all applications you will write.
Keep these things in mind, remembering that the rationales given in no way reduce the truth of the costs enumerated above. Those costs are real, and you will bear maintenance costs for the life of the code.