The Architect said, let there be a Software Specification Document (SSD) in the midst of the deep, and let it divide this software from that software. And the Architect made the SSD, and divided the software that already existed from the software that was to be, and it was so.

You can probably guess where this is going…

On the Seventh day, the software shipped and all was good.

Did you ever notice that there are a whole lot of words in Genesis that assume a whole lot of understanding? Like Waters, Heaven, Earth. Obviously these are understood a priori.

If you tried to write some code for Genesis, you would have some gaping holes. Turns out, Genesis does not include a Data Dictionary. Everything was created in its perfect form in those mythical 7 days. No chance to go back and change anything.

Sometimes it seems like this is how we’re expected to develop software. Even though we keep trying to do this, on average, this approach just doesn’t hack it.

Let’s call this the Creationism approach to software development. Everything is known up front and created in its perfect form.

If only it were so simple or even possible.

This is how the coding genesis chapter would have been written if we were using TDD:

In the beginning, the Product Owner identified a Need. And the Need was without form, and void; and darkness was upon the face of the deep. And the Spirit of the Team (Team) moved upon the face of the Need and asked some questions.

And the Product Owner added clarity to the need and the Team made the List and it was OK. The team worked on the List by first expressing What They Wanted (WTW), and they built the Software to make WTW be true. Of course the List was not perfect, so the team maintained it. When they thought they were done with the List, they showed what they had to the Product Owner.

Repeat.

In this approach, which we’ll call the Natural Selection approach, we try things. Unlike an omniscient Deity, the Product owner generally does not know exactly what is needed; they might not even know what some words mean. The Product Owner and Team work together to develop a solution. As the team works with the Product Owner, I’d hope they develop a suite of automated tests, preferably taking a Test First approach.

In a Creationism-based system, we clearly know what we’re doing and we even know what all the words mean. Therefore, it is OK to wait until the end to test. The level of clarity is such (again, we have omniscience working for us) that the only reason we need to test is because mere humans are solving a problem. And as we know, while an omniscient Deity does not make mistakes, we poor humans do.

Not so when using the Natural Selection approach. Whereas before we use a priori knowledge to build the system – which by its very nature is infallible, Natural Selection is all about trying things out. We build our understanding and express it in tests. When a system grows, we make sure that we do not break the tests (these are both the natural resources and environment). In some cases, the tests no longer work (the natural resources dry up or the environment changes). We need to change the tests to accommodate a better understanding of our system. The production code (that which is being selected) either survives under the tests or it gets changed. Sometimes new forms of the production code can exist in the same environment (refactoring).

So if you had your druthers, would you work on a Creationism-based project or a Natural-Selection-based project?