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

This principle should be obvious enough. All you need to know is KISS: keep it simple, sucka! That's all. How complex can simple be?

Very.

Let's take the darling of the phone industry -- the iPhone. When it came on the scene, it was a game changer. So much functionality wrapped up in a simple package. It's so simple, it must have only taken a week or two to put together, right? Obviously not. We know it took years of development and countless man-hours to refine.

So, the lesson here is that brewing up a fresh batch of simplicity can itself be complex.

And as to the question of "why simplify?", the answer is straightforward: it is bad to waste. Having unnecessarily complex processes creates wasted energy. Especially in the US, one of the tenets of capitalism is "do more with less". The implication of this is to reduce waste. Even the whole environmental movement is tied to this principle of minimizing waste. Who would have thought Greenpeace and the Fortune 500 had so much in common?

As far as actually doing this, I see three methods:

1. finding things that are being done that don't produce value, and eliminating them
2. batching related things
3. automation

First, find things that aren't helping solve the problem at hand, and eliminate them. Elimination is better than improvement. You might automate something that takes a man-hour down to a man-minute, but it still takes a minute. If you eliminate it, you'll never spend another minute doing it.

As an example, Agile does away with heavy up-front documentation, and distributes planning over the life of the project. The reasoning is simple: the plans were constantly being changed and revised anyways, so why waste time up front when it was going to be thrown away? Do some thoughtful planning up front, but don't draw up blueprints. We're building software, not a 50-story office building -- unlike an office building, software is easy to change during the process. This makes heavy up-front documentation less valuable. Be ruthless at kicking out waste.

Next up is batching. Batching means to group related activities. A perfect example of this is the sprint planning meeting. The planning meetings are when we batch up all the thinking for the upcoming work, instead of doing bits of planning every day. By doing all the thinking at once, there's a nice bonus where connections between otherwise independent features become apparent. Also, batching lets us avoid the waste of context switching. Once we're going on something, we don't have to refocus attention, which means we're not wasting time or energy by refocusing. The group gets a sort of "mental momentum", and that's good.

Finally, let's talk about automation. When making web applications, automation comes to us in the form of tools. Either off the shelf, or custom-built. Let's take the example of an open source tool that we use at Cloudspace -- the configuration framework called Chef.

Configuring servers used to be a long and fairly manual process. A simple web app is going to require the installation of

• Operating System
• Web server
• Language libraries
• Database
• Caching mechanism
• Application code
• Monitoring

Each of these categories has several parts. Manually configuring each is a waste of time. Using Chef (and some homebrew magic), we've written scripts to automate all of this. Base web app servers can be turned on and set to configure themselves. It still takes a certain amount of time, but it's not human time. It's computer time, and that's ok.

The obvious way of thinking about automation is this: it's okay to spend as much time automating something as it would have taken to do it manually. Any savings in time after that is the bonus. So, if you have 10 servers to set up, and each takes 1 hour, then it's worth spending up to 9.9 hours automating it.

There's another way of thinking about automation, one that focuses on business value. If automating a process means it will get done faster (as is often the case), then even more things are worth automating -- those where the time that would be spent performing the task is very expensive. Let's take server setup again. If the business value of a server being online is $1,000/hour (considering SLAs, income, sales, whatever metrics you need), and a server crashes, it needs to be brought online fast. If bringing a server online takes a human an hour, but takes a script 15 minutes, that means it's worth $750 to automate that server setup. Automating that server setup means that less work is being done, which means the process is simple, which means Agile Principle #10 holds true. Simplicity -- the art of maximizing the amount of work not done -- *is essential*.