The principle of “You aren’t going to need it!” found in Extreme Programming can be particularly valuable for keeping your programming workflows simple.
Jason McCreary explains principle of “You aren’t going to need it!” found in Extreme Programming, and how it can be valuable for keeping your programming workflows simple.
Programming practices like DevOps are undoubtedly at the forefront of programming trends. Without diminishing the real benefits that adopting DevOps can have for your project, these benefits are more evident on the project management end of the spectrum, whereas principles such as Extreme Programming (XP) relate more closely to the actual code written.
SEE: How to build a successful career as an IT consultant (free PDF) (TechRepublic)
Simplifying the development process by limiting the amount of work done to accommodate future requirements of a given program can pay dividends in time management. Jason McCreary spoke about the “You aren’t going to need it!” (YAGNI) aspect of Extreme Programming in August at Code PaLOUsa in Louisville, KY.
What is YAGNI intended to solve?
Opening an IDE and simply diving in is likely to result in poorly-focused spaghetti code, the process is not unlike starting a car without a destination in mind beforehand. It is possible to arrive somewhere, though the path taken to that point is far from efficient. Essentially, the principle of YAGNI is that developers should not add functionality until it is necessary for the product or intended use.
McCreary points to two quite dissimilar sources for understanding this. Ron Jeffries, one of the three co-founders of Extreme Programing, describes it as, “implementing things when you actually need them, not just when you foresee that you need them.” Similarly, French writer Antoine de Saint-Exupéry noted that, “Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.”
One of the common pitfalls of programming in modern frameworks—node.js is infamous for this—is the routine importation of packages to provide minimal features, thereby adding complexity and creating a dependency. When “taking a library, or buying some piece of software, or adopting a framework,” to accomplish a task, consider why this is being done. By writing your own code for your own needs, “there are benefits beyond just reducing complexity, the benefits [are that] the code is more approachable, readable, usable, and maintainable over time.”
When to invoke YAGNI in your development process?
McCreary notes that there are two perceptions of time. “Time is the most precious thing to me, it’s something that I’ll never have more of. It’s a double-edged sword. On one hand, it’s stressing me out, I’ve got a deadline, we’re right here, let’s do it, why are we wasting time? There’s another side to time: Let’s just relax, we’ll do it later, we’ll get to it. We have to get more on the comfortable side of time.”
Likewise, McCreary calls on developers to challenge their way of thinking when starting on development.
Do you really need to build it right now?
Do you have everything you need to start?
Do you fully understand the problem?
But there is a dark side to YAGNI, when it manifests as “Just Say No,” where McCreary cautions against calling YAGNI on things like testing, as there is not a level of “just tested enough.” Likewise, YAGNI does not apply to security, and attempting to call YAGNI on business requirements is not advisable. As an example, “If they say you have to use a SQL server, even when you know you can do it on a flat-file database, you can’t call YAGNI on that, even though it might be a simpler approach.” McCreary also warns developers to not sabotage yourself—don’t call YAGNI on a current design decision based on a future need.