Agile's Fifth Element

You have probably heard of the "Agile Manifesto". This was designed to enunciate Agile's fundamental approach by those who coined the term "Agile" software development (see Agile Manifesto).

• Favor individuals and interactions over processes and tools
• Favor working software over comprehensive documentation
• Favor customer collaboration over contract negotiation
• Favor responding to change over following a plan

Elements, Principles, ???

I'm never sure what to call the Agile Manifesto's 4 main statements. They can't be principles as there are also 12 Agile Principles (see Agile Principles).

I have seen various names, such a guidelines, values or statements. I think Elements is the logical choice as it emphasizes their fundamental importance.

For a long time now I have felt there is one thing missing from the above. It is at least as important as a couple of them. I call this Agile's Fifth Element.

• Favor simple design over reusability and generality

What is an Agile Element?

To see why we it should be added to the other four we need to decide how a statement qualifies to be an Agile Element. In my opinion an Agile Element needs to:

• challenge, or at least de-emphasize, (previously accepted) best practice
• be fundamental to the Agile approach
• be important enough not to simply be considered an Agile Principle

There are many books on software project management typical of the Waterfall era (mainly written from the 1960's to the 1980's) that emphasize the importance of following strict procedures, having everything well-documented, and having a water-tight contract with the customer. Most of all they talk about the importance of planning a project down to the smallest detail.

I won't go into why these ideas don't work (again), though the authors make them look very good on paper. Luckily Agile came along and turned all of this on its head. The four elements of the Agile Manifesto clearly highlight what was (and often still is) wrong with what was considered the correct way to develop software.

How Does it Qualify as an Agile Element?

Let's look at how the proposed fifth element satisfies the above criteria by looking at each criterion in turn.

Does it challenge accepted best practice?

The big paradigm to come out of the 1980's was the emphasis on reusability. Many in the Agile world now think that this emphasis was a mistake as I previously explained in Reusability Futility.

In brief, experience has shown that too much software is designed to be flexible and reusable for no purpose. This leads to increased complexity to the detriment of other attributes such as understandability, verifiability, efficiency, etc. The worst effect is that software becomes harder to maintain and cannot adapt to change.

OK, but why is it fundamental to the Agile approach?

Keeping things simple is part of the agile approach. In fact the 10th Agile Principle says:

Simplicity -- the art of maximizing the amount of work not done -- is essential.    

Simplicity is necessary in order to create small, frequent software releases - a major part of the Agile approach. Further, keeping things as simple as possible allows the software to more easily evolve, since unnecessary constraints interfere with continual refactoring -another fundamental feature of Agile development.

designing for flexibility
adds complexity

Of course, you may ask: can't you design software to be both simple and flexible? Sometimes you can find a design that is simpler and more flexible than any alternative but usually there is a trade-off, particularly as modules become larger. The overwhelming general experience is that designing for flexibility adds unnecessary complexity.

  

Is it really important enough to be the Fifth Element rather than just a principle?
  
Yes, it is! It counters one of the biggest problems currently facing software development - the tendency of developers to over-design and add unnecessary code. There are lots of reasons this occurs such as:

• temptation to add something now which is "sure to be needed later"
• desire to use some new design pattern that one has recently been read about
• hope that a general purpose module can have use in other projects
• use of particular new technology to have on your CV
• desire to avoid future code modifications

These reasons, and their consequences, are further elaborated in Gas Factory Anti-Pattern.

If you're still not convinced I recommend reading Chapter 18 of the excellent book 97 Things Every Software Architect Should Know. It is written by Kevlin Henney and entitled Simplicity Before Generality, Use Before Reuse. It says exactly what I have been trying to get people to understand for many years.

Why Is It Missing?

You would have to ask the authors of the Agile Manifesto why they left it out. I suspect that its importance was simply not appreciated at the time.

I guess the first four elements highlight problems with best practice that have been promulgated since the 1960's. The proposed fifth element highlights the problem of something that only became considered best practice later (1980's) - that is designing software for reusability.

Another theory is that many of the creators of the Agile Manifesto were heavily involved in OO (Object-Oriented) technologies. To de-emphasize reusability would be anathema to them, since reusability is a fundamental part of OO design.

A Different Fifth Element Proposal

As I write this post I have discovered that our dear old friend Uncle Bob (Martin) has also proposed an additional element for the Agile Manifesto:

• Favor craftsmanship over execution

In essence he is saying that many developers are only concerned with getting the code working without regard to the quality of the code they produce. I agree with Uncle Bob that this is a serious problem that affects much, if not most, software development.

But Uncle Bob's proposal, though eminently worthwhile, does not qualify as an Agile Element for the reasons mentioned above (see What is an Agile Element?).

First, it does not question accepted best practice since software quality experts have been emphasizing the importance of various quality attributes of software (such as maintainability) for decades. I also do not believe it is fundamental to the Agile approach, though many Agile practices, which could be considered as promoting craftmanship (such as pair programming), will improve code quality.

Summary

My proposal is for an additional element to be added to the existing four elements of the Agile Manifesto. I consider this new element to be a least as important as a couple of the big four - personally I would rank it third. I believe it to be fundamental to the Agile approach as it is practiced today. For example, many practitioners of XP (Extreme Programming) talk about the importance of YAGNI and simple design (see Simplicity is the Key). Similarly in Scrum, developers focus on solving current customer needs by concentrating solely on the most important backlog items.

... software is designed
for general purpose
and, ironically,
ends up being fit
for nothing at all!

The problem of unnecessary generality and reusability is largely unrecognized, but significant and growing. I believe it is mainly due to the training and mentality of developers, particularly software architects. Perhaps with the best intent, software is designed for general purpose and, ironically, ends up being fit for nothing at all!

Far better is to start with a simple design that can be easily modified (with the assistance of Unit Tests) into whatever the future requires. Without the burden of unnecessary complexity the software may be able to evolve forever or at least not become a "legacy" application almost immediately as most software tends to do.

So do you think this is a worthwhile proposal? I would be interested to hear your comments.