This book is a collection of generative projects: projects where our goal is the discovery of a new design, refining a novel invention, uncovering a solution to an unsolved puzzle, or some other sort of inspirational and unexpected surprise.

We'll use techniques and algorithms from the field of AI called Genetic Programming to work through these projects. You may have heard about Genetic Programming, and about "invention machines" that can produce "human-competitive results" "automatically" using "artificial intelligence".

That admirable research program is exciting and well-intentioned. But as I said our goal here is actually solving problems, so we're going to use tools and algorithms from Genetic Programming in ways that researchers and practitioners in Genetic Programming definitely don't approve of. I know—I've been one for nearly 20 years, and trust me when I say we're doing something different here.

I'm going to call this "GP". Let the resulting ambiguity mask the differences.

The technical side of GP is a big pile of trivia, at least in the context of solving problems. It's just thousands of variations on a few simple design patterns. There are no "theories" that can advise you on choosing one algorithm over another in a particular context, nor do you need to know anything about the analytical correctness of your procedures if you just want an answer. GP is just another flavor of software development. It's an idiomatic approach to answering questions using computers.

But when it's done right, GP can help you explore problems faster. Much faster than you can with pencil or paper, or by sitting and thinking in front of a whiteboard with a domain expert. It's a way of capturing and accelerating the repetitive parts of design, invention, and other creative efforts, in order to free your time for the more difficult tasks that never disappear.

When GP works, it does so by speeding up the rate at which you're usefully surprised. The lead compound for a drug is useful because it’s different from what everybody in the field thought they knew. The patentable design for an analog circuit or a bearing or an antenna isn’t useful because it’s “optimized”, it’s patentable because it’s different. Even the amiable workhorse of the GP world—arbitrary mathematical functions fit to data points—isn’t helpful as a way of doing statistics. It’s about the hints and surprises it shows an attentive watcher.

In other words, GP is useful for changing you, not for heating up the processors inside the “artificial” black box or filling a drive with the stuff a million random monkeys have typed. So in this book, we're not going to try to build "automatic invention machines" that use Genetic Programming.

We're going to build GP software systems that support your own creativity and inventive capacity: Answer Factories.

Like the manager of any real factory, you can't just set it up and tell it what to do. You need to be in a position to manage it. You need to be vigilant about your own goals, and what's being produced. You need to be able to see promise in a partial solution, and adapt your own needs to the emergent behavior of your complex factory. You can't just point and shoot, no more than you can "point and shoot" a human software development team and expect them to succeed at reading your mind, staying on track, and getting valuable results delivered to you on schedule and under budget.

We also need to cover the habits and techniques that can help you cope with the acclerated pace at which you receive surprising results. And the habits that help you define and direct goals, evaluate results, and direct your project to success before the heat death of the Universe.

It turns out there's a movement in software development that's specifically focused on coping with and embracing this sort of change. With helping human beings manage and adapt in the context of the projects they work in, and reducing the risk that they just heating up processors and filling hard drives.

We'll spend a lot of time learning from those folks.