Piecemeal Growth 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.
Christopher Alexander claims that the only way to make something that seems alive is through a process of Piecemeal Growth. For him, Piecemeal Growth is more fundamental than patterns. Since people are able to develop a community using Piecemeal Growth, and since there is no central coordination, they must be following the same patterns. The Nature Of Order is also based on Piecemeal Growth, though not on patterns.
Piecemeal Growth 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. Piecemeal Growth is not nearly as controversial as it used to be, though many large organizations still try to develop software with a Master Plan.
Piecemeal Growth was what originally attracted me to Christopher Alexander's work. Piecemeal Growth is why I think Re Factoring is so important. Piecemeal Growth is one of the strengths of Extreme Programming. It is a principle that needs to be emphasized more when we teach programming. -- Ralph Johnson
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 Piecemeal Growth by simplifying your implementation is to ignore the context you are building in. Christopher Alexander 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 Piecemeal Growth in conjunction with your end users. -- Mark Luffel
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. -- Dave Harris
(see Extreme Programming And Patterns for a discussion of why patterns aren't being adequately acknowledged in XP -- Joshua Kerievsky)
Linus Torvalds of Linux Os fame has advocated ideas similar to Piecemeal Growth (Linus On Design).
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 Design Patterns 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 Simplest Thing That Could Possibly Work and it makes everyone do much more work than necessary. This is Defensive Programming without the defense and causes bloated, late software. -- Jason Bedunah
Yeah, uh, see some of the Category Architecture pages for alternative views on that.
In the context of wikis, Piecemeal Growth is encouraged by the Wiki Design Principles (esp. incremental).
In practice, Piecemeal Growth influences whether or not I create a new Wiki Page. One criteria I use is that the new page must satisfy a Two Link Minimum; that is, the creation of the new page must improve two existing pages.
Generally, when we're doing Piecemeal Growth, 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. Piecemeal Growth 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 Master Plan.
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 Piecemeal Growth. 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 Piecemeal Growth. Lather Rinse Repeat.
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 Piecemeal Growth.
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, Piecemeal Growth much easier to practice using an Agile Software Development approach than with the traditional methodologies which encourage Big Design Up Front (BDUF).
See original on c2.com 