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.
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.
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
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
for a discussion of why patterns aren't being adequately acknowledged in XP -- JoshuaKerievsky
fame has advocated ideas similar to PiecemealGrowth
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
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
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
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