Contribution 8

From WikiContent

(Difference between revisions)
Jump to: navigation, search
(Removing all content from page)
Current revision (20:00, 7 June 2008) (edit) (undo)
(Talk about the arch, but see the scaffolding beneath it)
 
(One intermediate revision not shown.)
Line 1: Line 1:
 +
== Talk about the arch, but see the scaffolding beneath it ==
 +
 +
The arch is an architectural marvel. It bears its own weight and supports the weight of the wall above it. The challenge of building an arch is not making one that will stay up after its built. An unfinished arch has no strength. The real challenge is making sure it stays up at every moment before the keystone is in place.
 +
 +
Before the keystone, scaffolding is more important than the arch itself.
 +
 +
So, even while we tell stories and create a vision of the future, we still have to bridge the gap between "today" and "tomorrow" one self-supporting step at a time.
 +
 +
I've often seen large-scale attempts to violate this principle. These often come in the form of "enterprise" initiatives: Enterprise Data Model, Enterprise Application Integration, Enterprise Service Bus, and the like. These end in one of two ways, either a noisy disaster or a quiet attrition in scope and budget followed by shelving. Why? Mainly because these projects always try to go from nothing to a cathedral in one great leap forward. They should rather plan for incremental growth around a functioning system.
 +
 +
Conversely, Agile methods use this principle powerfully. From the first release, the system functions as an integrated whole. It may not do much, but it all holds together in a self-supporting structure.
 +
 +
 +
By [[Michael Nygard]]
 +
 +
This work is licensed under a
 +
[http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]
 +
 +
 +
 +
Back to [[97 Things Every Software Architect Should Know]] home page

Current revision

Talk about the arch, but see the scaffolding beneath it

The arch is an architectural marvel. It bears its own weight and supports the weight of the wall above it. The challenge of building an arch is not making one that will stay up after its built. An unfinished arch has no strength. The real challenge is making sure it stays up at every moment before the keystone is in place.

Before the keystone, scaffolding is more important than the arch itself.

So, even while we tell stories and create a vision of the future, we still have to bridge the gap between "today" and "tomorrow" one self-supporting step at a time.

I've often seen large-scale attempts to violate this principle. These often come in the form of "enterprise" initiatives: Enterprise Data Model, Enterprise Application Integration, Enterprise Service Bus, and the like. These end in one of two ways, either a noisy disaster or a quiet attrition in scope and budget followed by shelving. Why? Mainly because these projects always try to go from nothing to a cathedral in one great leap forward. They should rather plan for incremental growth around a functioning system.

Conversely, Agile methods use this principle powerfully. From the first release, the system functions as an integrated whole. It may not do much, but it all holds together in a self-supporting structure.


By Michael Nygard

This work is licensed under a Creative Commons Attribution 3


Back to 97 Things Every Software Architect Should Know home page

Personal tools