Piecemeal Growth

PiecemealGrowth is the process of building something a step at a time. Each step consists of evaluating the current system, deciding what should be done next (what should be fixed or improved) and then adding a piece or making a change.

ChristopherAlexander claims that the only way to make something that seems alive is through a process of PiecemealGrowth. For him, PiecemealGrowth is more fundamental than patterns. Since people are able to develop a community using PiecemealGrowth, and since there is no central coordination, they must be following the same patterns. The NatureOfOrder is also based on PiecemealGrowth, though not on patterns.

PiecemealGrowth used to be considered bad by many of those who thought about software development. It was a sign of not planning ahead. But now most people acknowledge that iterative development and phased delivery are good. PiecemealGrowth is not nearly as controversial as it used to be, though many large organizations still try to develop software with a MasterPlan.

PiecemealGrowth was what originally attracted me to ChristopherAlexander's work. PiecemealGrowth is why I think ReFactoring is so important. PiecemealGrowth is one of the strengths of ExtremeProgramming. It is a principle that needs to be emphasized more when we teach programming. -- RalphJohnson

This pattern applies more to user testing than refactoring. The architectural idea was that the user of a building should have a direct, visible impact on the final product. To say you are using PiecemealGrowth by simplifying your implementation is to ignore the context you are building in. ChristopherAlexander meant this as a focus on context. What you do to make the internals correct should be obvious and painless. Finding out what is correct should be done by PiecemealGrowth in conjunction with your end users. -- MarkLuffel?

The worry is that with piecemeal growth you may paint yourself into a corner. Patterns are a technique for avoiding that. They embody a kind of foresight - actually hindsight derived from other successful systems. -- DaveHarris

(see ExtremeProgrammingAndPatterns for a discussion of why patterns aren't being adequately acknowledged in XP -- JoshuaKerievsky)

LinusTorvalds of LinuxOs fame has advocated ideas similar to PiecemealGrowth (LinusOnDesign).

I think patterns shouldn't be planned. One should guide the code and refactor into them if they make the system simpler. I think most people have the idea that using DesignPatterns will keep them free from some atrocity down the road. But, in most experience, the opposite is true. An "architect" devises some grand pattern-rich architecture that is clearly not SimplestThingThatCouldPossiblyWork and it makes everyone do much more work than necessary. This is DefensiveProgramming without the defense and causes bloated, late software. -- JasonBedunah

Yeah, uh, see some of the CategoryArchitecture pages for alternative views on that.

In the context of wikis, PiecemealGrowth is encouraged by the WikiDesignPrinciples (esp. incremental).

In practice, PiecemealGrowth influences whether or not I create a new WikiPage. One criteria I use is that the new page must satisfy a TwoLinkMinimum?; that is, the creation of the new page must improve two existing pages.

Generally, when we're doing PiecemealGrowth, we actually have, inside our heads, an idea about how it's all going to come out, in the end. That is, I believe, we actually have a design in our head, that we're "filling out."

Sometimes, we just reach the end, and everything's great. PiecemealGrowth rocks!

But then, sometimes, we find we've painted ourselves into a corner. When that happens, we need to sit down, think, and redesign our system. Then rip out the old stuff that doesn't make sense, and redo it in the new direction.

Some people do not like this. "All this tearing apart what we've already built- can't we do better?" They wonder: If only we think hard enough, and cleverly enough, can we work without ever redesigning?

They may look over at their neighbor, and see someone else implementing a flawless MasterPlan.

It is possible that some people are "just brilliant." This may be possible. However, it seems likely to me that this person has actually just built design after design after design in the past, and understands the ins and outs of the problems she is working with. This neighbor has probably found the sweet spot after lots of both thinking and programming. The neighbor has probably ripped apart many systems, or at made many systems out of the lessons of the flawed past.

If you're writing alone, on some project, of a sort that you've never seen before, this may be the way to go: Work out a small design, over, say, 30 minutes- not long. Then start in on PiecemealGrowth. Should you find yourself cornering yourself in, figure out what your problem is, and redesign. Do not focus on perfect designs; Just focus on getting something that seems like it will work. Tear out, from your existing code, what you need to. Then go back to PiecemealGrowth. LatherRinseRepeat.

As you do this, the words of fellow travelers will begin to make more sense, and you'll gain a sense of the ins and outs of the system. Theory that was once impenetrable (and of no use to study, though you may have tried prematurely) will be clear, and the frontiers of your peers will be visible. You can now learn from their mistakes, with some casual study, and you can go to work at implementing them, again by PiecemealGrowth.

You're in trouble, if you think you can get it right in your first shot, having never seen such a system before. No amount of paper can help you. But, it is a lesson we all need to learn some time, both as individuals, and as groups.

In the field of IT, PiecemealGrowth much easier to practice using an AgileSoftwareDevelopment approach than with the traditional methodologies which encourage BigDesignUpFront (BDUF).

See ImprovisationalProgramming, WalledGardenDiscussion