Incremental Development

So my recent exploration of tackling my personal game projects in a different way has been paying off massive ways.  I have been far more productive and creative.  With that comes excitement for the project and even more excitement to show people the game because it is a constant state of completion.  I was digging around the internet more and watching programming talks and reading papers on software creation when I came across one that I had heard about but never read.  It is a paper called "No Silver Bullet" by Fred Brooks.  It is a wonder paper and I was super excited when I came across this section towards the end because it turns out it is exactly the approach I have been taking and I have been experiencing the same results from a personal and production level.

Incremental development--grow, don't build, software. I still remember the jolt I felt in 1958 when I first heard a friend talk about building a program, as opposed to writing one. In a flash he broadened my whole view of the software process. The metaphor shift was powerful, and accurate. Today we understand how like other building processes the construction of software is, and we freely use other elements of the metaphor, such as specifications, assembly of components, and scaffolding.

The building metaphor has outlived its usefulness. It is time to change again. If, as I believe, the conceptual structures we construct today are too complicated to be specified accurately in advance, and too complex to be built faultlessly, then we must take a radically different approach.

Let us turn nature and study complexity in living things, instead of just the dead works of man. Here we find constructs whose complexities thrill us with awe. The brain alone is intricate beyond mapping, powerful beyond imitation, rich in diversity, self-protecting, and selfrenewing. The secret is that it is grown, not built.

So it must be with our software-systems. Some years ago Harlan Mills proposed that any software system should be grown by incremental development. [10] That is, the system should first be made to run, even if it does nothing useful except call the proper set of dummy subprograms. Then, bit by bit, it should be fleshed out, with the subprograms in turn being developed--into actions or calls to empty stubs in the level below.

I have seen most dramatic results since I began urging this technique on the project builders in my Software Engineering Laboratory class. Nothing in the past decade has so radically changed my own practice, or its effectiveness. The approach necessitates top-down design, for it is a top-down growing of the software. It allows easy backtracking. It lends itself to early prototypes. Each added function and new provision for more complex data or circumstances grows organically out of what is already there.

The morale effects are startling. Enthusiasm jumps when there is a running system, even a simple one. Efforts redouble when the first picture from a new graphics software system appears on the screen, even if it is only a rectangle. One always has, at every stage in the process, a working system. I find that teams can grow much more complex entities in four months than they can build.

The same benefits can be realized on large projects as on my small ones. [11]

I found this piece of the paper to really jump out for me, but I think that is because it most closley matches my mental thinking lately.  However there are absolute gems in the entire paper so treat yoru self and give it a good read, and then another read and another.  My hope is that it might kick start something exciting for your own work too!