Candy Wrapper Theory of Development

I have come to believe in what I call the Candy Wrapper theory of development. Basically, it describes the true role of each part of an organization in creating a sustainable process that doesn't drive people crazy.

Basically, the width of the candy wrapper represents churn. A certain amount of churn is inevitable, but it will drive people crazy. So, you manage the churn at a couple of key points. This way you can sustain your development cycle and create certain points where you can see through the churn to check your work.

Let's look at the candy wrapper from left to right:

Basically, a lot of stuff comes in from a lot of sources on the left side of the candy wrapper:
- requirements from customers
- requirements from marketing and sales
- requirements (aka ideas) from engineers

Product management's job is to catch all of that stuff, condense it, organize it, and prioritize it. Then it gets fed in a nice small stream through to development.

Development works in the center of the candy. There is some churn (hence, the candy gets wider) as features are implemented, infrastructure is created, bugs are fixed, etc.

QA stands at the right side of the candy wrapper. It grabs everything that dev puts out and make sure it's packed up neatly. QA confirms that what's coming out is a coded version of what product management put in.

Then the candy wrapper gets very wide again as support, customers, sales people, etc. take the product in the myriad directions it could go.

Hence, development, Candy Wrapper style.