YAGNI is a well known acronym in agile software development, which is short for You Ain’t Gonna Need It. Originally this acronym suggests to programmers that they should not add functionality until it is really necessary.
"Always implement things when you actually need them, never when you just foresee that you need them," says Ron Jeffries. Quite often developers think of writing generic code; code that foresees in features that is likely to be required in the future. However, writing code that might be desirable in the future has a number of disadvantages, for instance in the time that is needed to write your future code, you will not be able to write the code you need now. Also, the current code base becomes unnecessarily more complicated to extend and test. And moreover, you can never really be sure that this generic code will actually meet future features, as features will change over time during any project.
A much better approach to write code would be to just write the code that you need to get your current work items done. Or slightly better put: only write the code you need to get to the next steps. In other words, in projects we try to maximize the amount of code not written.
Extending YAGNI to other activities
Although the YAGNI principle is best known when applied to writing code, it can be in fact very effectively applied to all kinds of activities executed in projects, such as analyzing requirements, step up software architecture, or design smart use cases. Just follow the following simple procedure will help you out:
- Identify next step. Identify what will be the next step to take.
- Identify work items to get you there. Sum up all the work items that need to be taken care of to get to starting this particular next step.
- Run work items. Do just this work, and expand all other work items.
Benefits of applying YAGNI
Applying this basic procedure to all work items in projects has a number of benefits.
First of all, when you are doing work items to get to the next step, you can be quite sure that this next step will be actually taken. To clarify, compare a traditional waterfall styled project to an agile Smart project. In the traditional project, all functional requirements are analyzed well before they are actually implemented. This means that if somehow some of these requirements change during the course of the project, most work regarding these changing requirements is done unnecessarily. And it gets even worse if any requirements are dropped. In this case, all work associated these requirements was useless.
Secondly, suppose your analyzing requirements early in a project. Analyzing a particular requirement might take you 30 hours. In a YAGNI requirements approach, requirements will not be analyzed before they are realized.
Applying YAGNI to Smart
In the agile methodology Smart, YAGNI becomes a very powerful principle. YAGNI guides the projects in each of the different types of iterations and all deliverables resulting. At each of Smart’s iteration types, and each of the deliverables and acitivities proposed, the project team needs to identify what the next steps is, and what the minimal amount of work is, to help get there.
Applying YAGNI to estimates
For instance, the primary goal of the Propose iterations is to derive a project proposal. In Smart projects there is no need to do a extensive requirements analysis during the early stages of the project.
The question should be: what activities do we need to run to be able to write the project proposal. And just run these activities. In Smart one of these proposed activities during Propose is to create an estimate for the project. This (initial) estimate again will be based on the smart use cases that need to be realized during the project. So you will need to establish either the smart use case model, or a relevant list of smart use cases. And there you are. There is no need to do a full analysis of your requirements, but just enough to help you get to the next step, which is creating the estimate.
It also needs to be noted that during a software development project there is only one single moment when the requirements are actually fixed. And that is at the end of the project, when the software is delivered. Any stage earlier in the project that tries to do a full requirements analysis is doomed to fail. As research shows, on average requirements change 20% up to 25% during the project.
Applying YAGNI to smart use case design
Another example of the effective use of the YAGNI principle in Smart is found in implementing smart use cases during Realize and Finalize iterations. It is not until here that the project team analyzes and (test) designs the individual smart use cases. But the team only does this for the current smart use case at hand. Only analyze one single use case at a time, design it, test design it and implement it. And only after this smart use case was accepted, start with the next.
Thus all work on smart use cases is done as late as possible, which make the work lighter, as later on during the project, the team will have more knowledge on the project domain, and need less time to do the design. Moreover, when starting the analysis and design for a particular smart use case, the team will be very sure that this use case will actually be built, and is unlikely subject to change, as it will be built right after the design is done.
For more information, check www.accelerateddeliveryplatform.com.