YAGNI is very lean

In Extreme Programming (XP), there is an accepted principle with the acronym of YAGNI. What is it? Here's a good summary from Wikipedia:

The YAGNI principle of software development says that when there's a good chance that "you ain't gonna need it", it's better to postpone adding a program feature.

Even when it turns out that the functionality really is needed, the habit of writing code that is not necessary at the moment has some overlooked disadvantages:
* The time spent is taken from necessary functionality.
* The new features must be debugged, documented, and supported.
* Any new feature imposes constraints on what can be done in the future, so an unnecessary feature now may prevent implementing a necessary feature later.
* Until the feature is actually needed it is not possible to define what it should do, or to test it. This often results in such features not working right even if they eventually are needed.
* It leads to code bloat; the software becomes larger and more complicated while providing no more functionality.
* Unless there are specifications and some kind of revision control, the feature will never be known to programmers who could make use of it.
* Adding the new feature will inevitably suggest other new features. The result is a snowball effect which can consume unlimited time and resources for no benefit.

This principle very much supports both the concepts of Eliminating Waste and Defer Commitment. If you are not sure that code or functionality is really needed, you need to do some more homework. This homework could be additional research, talking with customers, or just waiting until you deliver higher priority functionality to the customer and really see if they need something else. In Lean, if there isn't direct Customer Value it is considered Waste. That is a bad thing. As mentioned above, it also leads to more complexity which can impact the long-term maintainability and quality of your code. Therefore, why not keep things as simple as possible until you absolutely need to put more into it?

I have seen in many design sessions where things get into a frenzy because the developers have figured out something cool with the technology they are using and are very eager to implement their ideas. This is fine, as long as the technology and their ideas translate into something the customer really wants or needs. Too many times, customers are usually forced into having something new that the development team thought they needed only to find they hardly use it. What happens next? Well, usually both the customer and the development team live with this unused, most likely complicated functionality forever. In the end, nobody is really happy about it.

However, when you find yourself in such a meeting (and you will at some point), remind the team about YAGNI. This will be a good reminder to them about the important of value and to wait until it is the right time to implement such functionality.

Values, Principles and Practices

When I was creating this blog, I wanted to make sure I had a tag line that accurately reflected what the focus and goals of this blog were to be. Here's what I came up with:

A manager's quest to improve his organization through Lean and Agile development values, principles and practices.


Technoetic had a post awhile back that I found to be a great representation of the overall goals - values, principles and practices. While some use these terms somewhat interchangably, I truly believed that each of them represented a particular piece of the whole. The author of this post apparently agreed with me and came up with perfect definitions of each of the parts. Here they are:

Values - A description of preference between alternatives. Often the alternatives represent candidate courses of action and the value guides the selection among the alternatives. Sometimes values are basically axioms. They can be irrational in the sense that we might not be able to explain them intellectually or they might be primarily based on emotions.

Principles - Statements describing a model. A scientific principle is a statement describing an aspect of physical reality. Principles might also describe a model of social activity, for example. Principles can be fundamental or logically derived from fundamental principles. It’s commonly believed that principles are derived from values, but sometimes people have certain values because of specific principles. For example, the “value” of communication can be derived from the principle that communication improves cooperation and coordination effectiveness. This circularity between values and principles can be confusing at times.

Practices - A pattern of activity that can be repeated to achieve goals within a context. A person defining a practice is applying principles within a framework of their values (preferences). A related collection of practices might be called a process or methodology.

To make it even simpler, I could summarize the difference between these as:

Values are the feelings of what the right things are for us to do.

Principles are the guidelines of how we are to demonstrate those values.

Practices are the actions of what we do to support those principles.

As I write future posts, I will refer to these terms frequently to describe the parts of both Lean and Agile. Before I went there, I thought it would be good for us to have the same context going forward.