This post originated from an RSS feed registered with Java Buzz by Michael Cote. Original Post: Some Excerpts from Lean Software Development Feed Title: Cote's Weblog: Coding, Austin, etc. Feed URL: https://cote.io/feed/ Feed Description: Using Java to get to the ideal state. Latest Java Buzz Posts Latest Java Buzz Posts by Michael Cote Latest Posts From Cote's Weblog: Coding, Austin, etc.

I'm a nut for any book from Cockburn's series. (Please pause so Chip can have his usual chuckle at the name, not to mention those of the book at hand [no pun intended] authors....OK, thanks.)

As Carl pointed out a few weeks ago, the knowledge in the book may just be old wine in new bottles (or is that the other way around? ...whatever), but, what the hell. Us programmin'-type could guzzle all sorts of this wine, new or old, and we'd still end up scratching our heads all the time, asking, "Now, why didn't that project work out?"

Determining the need for paperwork:

A good test of the value of paperwork is to see if there is someone waiting for what is being produced. If an analyst fills out templates, makes tables, or writes use cases that others are eager to use -- for coding, testing, and writing training manuals -- then these probably add value. [Otherwise, they don't, and are "waste."]

"Development" vs. "Production":

Development is quite different than production. Think of development as creating a recipe and production as following the recipe. These are very different activities, and they should be carried out with different approached. Developing a recipe is a learning process involving trail and error. You would not expect an expert chef's first attempt at a new dish to be the last attempt. In fact, the whole idea of developing a recipe is to try many variations on a theme and discover the best dish.

On variation in response to different demands from different customers:

The difference between providing a service and manufacturing a product is that in service, dynamically shifting customer expectations require variation, while in manufacturing, variation is the enemy.

[...]Somehow, the idea that variation is bad has found its way into software development, where people have tried to develop standardized processes to reduce variation and achieve repeatable results every time. But development is not intended to produce repeatable results; development products appropriate solutions to unique customer problems.