Why Creative Chaos? - I

Five years ago I read Wicked Problems, Righteous Solutions, and it gave me words to express the way I understand software development to actually work.

Here's the deal: Software development is a creative process that you learn about as you do. That means that things change as you do them; more important than "getting it right the first time" is periodic assessment and course adjustment. That means that feedback is king.

For example, there are different ways to make soup: You can follow the directions (a prescription) or you can hire a world-class chef. If you follow the directions, what you get may be good, it may be bad, but it won't be great.

The chef isn't going to follow directions. He's going to start with something basic and flavor to taste. The college-edumacated people would call this an empirical process (one directed by feedback) instead of a controlled process.

The result of this is that if you want really great software, a predictive methodology isn't going to help much. It might be better to just put some bounds around the software (for example, a defined release process) and make it clear that like art, heavyweight methods actually stifle and hurt.

We seem to understand this idea for design; Tom Kelly has a book on it called The Art of Innovation. What bothers me is that so few people understand that, short of pressing the F5 key, all software development is a design activity. (Or, at least, if they understand it, they act as if it is not true.)

So, that's where Creative Chaos comes from. Because I specialize in software testing, I could have called it "Destructive Order", but that would just be too confusing. :-)