Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

I was reading Agile Manifesto Principles. Everything seems clear and reasonable except for one point:

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

I dont understand this. Does this mean that the work that wasn't done should be somehow exaggerated? If so, it doesn't really make sence.

share|improve this question
+1 to counter the down vote - you have a surprisingly interesting question here. –  GlenH7 Jul 14 '12 at 13:03
Also see Wu Wei and imagine how it can be applied to software development in general. It is the natural progression of the philosophy expressed in your question. –  Jarrod Roberson Jul 14 '12 at 18:44

5 Answers 5

up vote 30 down vote accepted

Remove the parenthetical comment. What remains is "Simplicity is essential", which by the way is an application of the principle to its expression itself.

Simplicity is essential, because you have distilled what you really need, removing what is making the task at hand heavier, less elegant: complex.

I have always interpreted in the sense of Pascal's take on brevity: "I would have written a shorter letter, but I did not have the time." You have to avoid what is unneded (from the letter, from the code) and this is an active task, and not an easy one. It is not something which happens by itself.

share|improve this answer
OMG that was so easy, and I didn't notice! You're answer is VERY nice. –  superM Jul 14 '12 at 18:29
you're welcome :-) –  Francesco Jul 15 '12 at 8:07

The idea is to avoid doing work that's not necessary, i.e. "maximize the amount of work not done".

So if in a traditional project you would plan and build a great abstract base system to allow for all your possible needs later one, you just skip that and build the simplest thing that can possible work for the current requirements. Don't build stuff that you don't need.

YAGNI is a related concept.

share|improve this answer
Coincidentally, this is probably the agile principle i agree least with. Taken to the extreme, abstract foresight is what separates us from other animals... I say we need to use it whenever we can. Of course I know what sort of atrocities the principle must be a reaction to - but a little bit of foresight won't hurt. Sometimes it's YAGNI, but I've seen some developers so dogmatic that they won't stop to even think a few hours ahead (and realize that the simplicity they are implementing now won't even suffice in 4-8 hours). –  Max Jul 14 '12 at 11:42
@Max, I think it is necessary to see foresee future possible changes. Here is where foresight is a great help. And the developers you describe are more like ostriches, who hide in sand. –  superM Jul 14 '12 at 11:45
@Max customers don't want to pay for what you think they might need in the future, they want to pay for what they need right now as as soon as possible. There are billions of $$$ of wasted effort every month on good intentions of "this will save so much time later" and that "later" never actually comes, but things are complex, buggy and late because of all that "foresight" –  Jarrod Roberson Jul 14 '12 at 12:37
@Max: YAGNI is about delaying decisions to the last responsible moment. What you are talking about is delaying the decision to the last possible moment, which is indeed a Bad Idea™. The thing is: you will never have less information to base a decision on than you have right now. In the worst case, you'll have the same information tomorrow. But usually, you will have learned something by then. In the case you mentioned, you know that you are gonna need it, so YAGNI simply doesn't apply. Trying to apply it is indeed stupid in that case. –  Jörg W Mittag Jul 14 '12 at 13:40
@Max: What you're describing here is the exact opposite of maximising the amount of work not done. It's doing twice as much work. –  pdr Jul 14 '12 at 13:44

This idea is very similar to a concept from the Toyota Production System (TPS), which led to the more generic Lean Manufacturing and then the application of those techniques to Lean Software Development. The TPS significantly predates the agile movement, with its roots in manufacturing in the late 1950s.

The concept of maximizing the amount of work not done is similar to eliminating waste. In the manufacturing environment, waste includes things like overproduction of goods, waiting for resources, unnecessary movement of people or products, too much inventory, and defective products. In Lean Software Development, these wastes were translated into unnecessary functionality, delays in the development process, unclear requirements that slow the production of software, a lack of testing, and communication delays.

The overall idea of both concepts is the same - things that don't add value are wasteful and should be minimized. The ultimate goal is to increase quality while reducing time and cost to produce.

share|improve this answer

We used to call this "gold plating". The requirement for a hammer is that it can bash a nail into a piece of wood. It doesn't do the job any better for being a gold plated hammer.

Many times a developer would suggest using a new cool framework or adding features which though cool were not necessary. We would note this idea down, but for this version we won't do it. We will maximize the work not done. It is hard enough to deliver software on time, so don't deliver any more code than you need to. If it needs to be done, eventually it will get in the plan and be done at the appropriate time.

share|improve this answer

Here's a quote from "Agile Principles, Patterns, and Practices in C#" By Micah Martin, Robert C. Martin

  1. Simplicity the art of maximizing the amount of work not done is essential. Agile teams do not try to build the grand system in the sky. Rather, they always take the simplest path that is consistent with their goals. They don’t put a lot of importance on anticipating tomorrow’s problems; nor do they try to defend against all of them today. Rather, they do the simplest and highest quality work today, confident that it will be easy to change if and when tomorrow’s problems arise.

I really don't get that. Does that means, instead of building a robust main engine which will be able to handle the features needed, one should just build one feature right ahead?

Because as far as I know this would most likely eventually turns out inefficient and less flexible.

Let's take an example:

Imagine ASP.Net without base Control/WebControl classes, because the .Net dev team would just have rushed doing "TextBox", "CheckBoxe", "Label", etc. immediatly. The .Net team dev would have taken the simplest path.

Woudln't that have made the whole framework's developpement a hell of trouble?

Can somebody tell me if I got the quote wrong of it's a really debatable rule?

share|improve this answer
This should be a new question, not an answer to someone else's question. –  Kent Anderson Aug 26 at 12:04
The idea is that if the ASP.NET Dev team, on day #1 of coding, tried to imagine what kinds of controls devs would need over the upcoming decade, that they would have failed miserably, and would NOT have been likely to correctly identify the more popular controls up front, since they would be operating in the vacuum of the Project Planning Room. –  Graham Aug 26 at 14:30

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.