Contribution 8

From WikiContent

(Difference between revisions)
Jump to: navigation, search
(Always ask for the value to be provided by a requested capability)
Current revision (20:00, 7 June 2008) (edit) (undo)
(Talk about the arch, but see the scaffolding beneath it)
 
(2 intermediate revisions not shown.)
Line 1: Line 1:
-
== Always ask for the value to be provided by a requested capability ==
+
== Talk about the arch, but see the scaffolding beneath it ==
-
Very often customers and end-users state what they think is a viable solution on a problem as a requirement. The classical story on this was first told by Harry Hillaker, the designer of the F16 Falcon. His team was requested to design a Mac 2 - 2.5 aircraft, a capability that is real hard to meet. When the design team asked the air force why, they was told that max speed in the magnitude of Mac 2 - 2.5 was required to escape from combat. When the real need was articulated the design team was able to provide a good solution, basically aircraft agility combined with an high thrust weight ratio, providing high acceleration, not maximum speed.
 
-
This lesson should be brought into software development as well. By asking for the value to be provided by a requested feature or requirement. By understanding the value and real need the designers are able address the real problem, and hopefully in the end provide a more elegant, better and hopefully cheaper solution compared to addressing the stated need in a head on approach.
+
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.
-
By [[Einar Landre]]
+
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
This work is licensed under a

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