Contribution 62 - Revision history

Rmonson at 16:52, 14 July 2008

2008-07-14T16:52:12Z

←Older revision		Revision as of 16:52, 14 July 2008
Line 1:		Line 1:
-	~~Work in progress~~	+	==Learn from Architects of Buildings==
-		+
-	==~~Lessons From Built Architecture?~~==	+

	''“Architecture is a social act and the material theater of human activity.”''—Spiro Kostof		''“Architecture is a social act and the material theater of human activity.”''—Spiro Kostof

Rmonson: /* Lessons From Built Architecture? */

2008-07-14T16:47:46Z

Lessons From Built Architecture?

←Older revision		Revision as of 16:47, 14 July 2008
Line 5:		Line 5:
	''“Architecture is a social act and the material theater of human activity.”''—Spiro Kostof		''“Architecture is a social act and the material theater of human activity.”''—Spiro Kostof

-	How many software architects see their role as exclusively, or primarily technical? Is it not rather that they are the conciliators, go–betweens and arbiters of the warring factions ~~within~~ the stake-holders? How many approach their work in a purely intellectual spirit, without giving proper weight to the human factors of their job?	+	How many software architects see their role as exclusively, or primarily technical? Is it not rather that they are the conciliators, go–betweens and arbiters of the warring factions among the stake-holders? How many approach their work in a purely intellectual spirit, without giving proper weight to the human factors of their job?

	''“A great architect is not made by way of a brain nearly so much as he is made by way of a cultivated, enriched heart.”''—Frank Lloyd Wright		''“A great architect is not made by way of a brain nearly so much as he is made by way of a cultivated, enriched heart.”''—Frank Lloyd Wright

-	What more strongly marks out the architects in your ~~organisation~~: raw intellectual horsepower and vast capacity to recall technical minutia, or taste, refinement and generosity of spirit? Under which tendency would you prefer to work?	+	What more strongly marks out the architects in your organization: raw intellectual horsepower and vast capacity to recall technical minutia, or taste, refinement and generosity of spirit? Under which tendency would you prefer to work?

	''“A doctor can bury his mistakes but an architect can only advise his client to plant vines.”''—ibid		''“A doctor can bury his mistakes but an architect can only advise his client to plant vines.”''—ibid
Line 31:		Line 31:
	''"It seems a fantastic paradox, but it is nevertheless a most important truth, that no architecture can be truly noble which is not imperfect."''—ibid		''"It seems a fantastic paradox, but it is nevertheless a most important truth, that no architecture can be truly noble which is not imperfect."''—ibid

		+
		+	(RMH edited 7/14/2008)

	By [[Keith Braithwaite]]		By [[Keith Braithwaite]]

KeithBraithwaite: /* Lessons From Built Architecture? */

2008-07-14T12:40:33Z

Lessons From Built Architecture?

←Older revision		Revision as of 12:40, 14 July 2008
Line 2:		Line 2:

	==Lessons From Built Architecture?==		==Lessons From Built Architecture?==
-	[note to editors: I don't have rock solid references for all of these yet, but will be hitting the British Library next weekend to check them out].

-	“Architecture is a social act and the material theater of human activity.~~”—Spiro~~ Kostof	+	''“Architecture is a social act and the material theater of human activity.”''—Spiro Kostof

-	How many software architects see their role as primarily technical? Is it not rather that they are the conciliators, go–betweens and arbiters of the warring factions within the stake-holders?	+	How many software architects see their role as exclusively, or primarily technical? Is it not rather that they are the conciliators, go–betweens and arbiters of the warring factions within the stake-holders? How many approach their work in a purely intellectual spirit, without giving proper weight to the human factors of their job?

-	“A great architect is not made by way of a brain nearly so much as he is made by way of a cultivated, enriched heart.~~”—Frank~~ Lloyd Wright	+	''“A great architect is not made by way of a brain nearly so much as he is made by way of a cultivated, enriched heart.”''—Frank Lloyd Wright

-	What more strongly marks out the architects in your organisation: raw intellectual horsepower and vast capacity to recall technical minutia, or taste, refinement and generosity of spirit? ~~Would~~ you ~~rather it were otherwise~~?	+	What more strongly marks out the architects in your organisation: raw intellectual horsepower and vast capacity to recall technical minutia, or taste, refinement and generosity of spirit? Under which tendency would you prefer to work?

-	“A doctor can bury his mistakes but an architect can only advise his client to plant vines.~~”—ibid~~	+	''“A doctor can bury his mistakes but an architect can only advise his client to plant vines.”''—ibid

-	Is the "maintenance" of "legacy" systems anything more than pruning vines?	+	Is the "maintenance" of "legacy" systems anything more than pruning those vines? Would you, as an architect, have the intestinal fortitude to scrap a piece of work that had failed? Or would you cover it up? Wright also said that the architect's best friend was the sledgehammer. What have you demolished recently?

-	“Architects believe that not only do they sit at the right hand of God, but that if God ever gets up, they take the ~~chair”—Karen~~ Moyer	+	''“Architects believe that not only do they sit at the right hand of God, but that if God ever gets up, they take the chair”''—Karen Moyer

-	~~“In architecture as in all other operative arts, the end must direct the operation~~. ~~The end is to build well. Well building has three conditions: Commodity, Firmness and Delight.”—Henry Watton~~	+	For "God" read "customer".

-	~~"No person who is not a great sculptor or painter can be an architect~~. ~~If he~~ is ~~not a sculptor or painter~~, ~~he can only be a builder"—John Ruskin~~	+	''“In architecture as in all other operative arts, the end must direct the operation. The end is to build well. Well building has three conditions: Commodity, Firmness and Delight.”''—Henry Watton

-	"It seems a fantastic paradox, but it is nevertheless a most important truth, that no architecture can be truly noble which is not imperfect."—ibid	+	When was the last time you saw a piece of software who's architecture gave you any ''delight''? Do you aim to give delight with your work?
		+
		+	''"No person who is not a great sculptor or painter can be an architect. If he is not a sculptor or painter, he can only be a builder"''—John Ruskin
		+
		+	Does artistry play its proper part in your architecture? Is the assemblage of components to make systems informed by a painterly concern for shape and texture, with a sculptural sense of balance and implied motion, of the importance of negative space?
		+
		+	And finally, no gloss is required on this comment, a sure remedy for the software architect's most damaging syndrome.
		+
		+	''"It seems a fantastic paradox, but it is nevertheless a most important truth, that no architecture can be truly noble which is not imperfect."''—ibid
		+

	By [[Keith Braithwaite]]		By [[Keith Braithwaite]]

KeithBraithwaite: /* Lessons From Built Architecture? */

2008-07-06T18:46:51Z

Lessons From Built Architecture?

←Older revision		Revision as of 18:46, 6 July 2008
Line 2:		Line 2:

	==Lessons From Built Architecture?==		==Lessons From Built Architecture?==
-	Simile and metaphor drawn form one professional domain is often of limited applicability in another. Calling the high–most technical lead of a software project the "architect" is some sort of mixture of hubris, grandiosity, (self)delusion and propaganda. What can we learn from the words of building architects that might help with that?
-
	[note to editors: I don't have rock solid references for all of these yet, but will be hitting the British Library next weekend to check them out].		[note to editors: I don't have rock solid references for all of these yet, but will be hitting the British Library next weekend to check them out].

KeithBraithwaite: /* Lessons From Built Architecture? */

2008-07-06T18:45:18Z

Lessons From Built Architecture?

←Older revision		Revision as of 18:45, 6 July 2008
Line 19:		Line 19:

	“Architects believe that not only do they sit at the right hand of God, but that if God ever gets up, they take the chair”—Karen Moyer		“Architects believe that not only do they sit at the right hand of God, but that if God ever gets up, they take the chair”—Karen Moyer
-
-	“Architecture is politics.”—Mitchell Kapor

	“In architecture as in all other operative arts, the end must direct the operation. The end is to build well. Well building has three conditions: Commodity, Firmness and Delight.”—Henry Watton		“In architecture as in all other operative arts, the end must direct the operation. The end is to build well. Well building has three conditions: Commodity, Firmness and Delight.”—Henry Watton

KeithBraithwaite: /* Quantify */

2008-07-06T18:45:02Z

Quantify

←Older revision		Revision as of 18:45, 6 July 2008
Line 28:		Line 28:
	"It seems a fantastic paradox, but it is nevertheless a most important truth, that no architecture can be truly noble which is not imperfect."—ibid		"It seems a fantastic paradox, but it is nevertheless a most important truth, that no architecture can be truly noble which is not imperfect."—ibid

-	== Quantify ==
-
-	"Fast" is not a requirement. Neither is "responsive". Nor "extensible". The worst reason why not is that you have no objective way to tell if they're met. But still users want them.
-
-	The architect's role is largely to help the system have these qualities. And to balance the inevitable conflicts and inconsistencies between them. Without objective criteria architects are at the mercy of capricious users ("no, I won't accept it, still not fast enough") and of obsessive programmers ("no, I won't release it, still not fast enough").
-
-	As with all requirements we seek to write down these desires. Too often then the vague adjectives come out: "flexible", "maintainable" and the rest. It turns out that in every case (yes even "usable", with effort) these phenomena can be quantified and thresholds set. If this is not done then there is no basis for acceptance of the system by its users, valuable guidance is stolen from its builders as they work, and the vision is blurred of those architecting it.
-
-	Some simple questions to ask: How many? In what period? How often? How soon? Increasing or decreasing? At what rate? If these questions cannot be answered then the need is not understood. The answers should be in the business case for the system and if they are not, then some hard thinking needs to be done. If you work as an architect and the business hasn't (or won't) tell you these numbers ask yourself why not. Then go get them.
-
-	The next time someone tells you that a system needs to be "scalable" ask them where from and why these users are going to come. Ask how many and by when? Reject "Lots" and "soon" as answers.
-
-	Uncertain quantitative criteria (which in mainstream development these will be—hard real–time folks have their own problems) must be given as a range: the least acceptable, the nominal, and the most worth paying for. If this range cannot be given, then the required behavior is not understood. As an architecture unfolds it can be checked against these criteria to see if it is (still) in tolerance. As the performance against some criteria drifts over time, valuable feedback is obtained.
-
-	Finding these ranges and checking against them is a time-consuming and expensive business. If no one cares enough about the system being "performant" (neither a requirement nor a word) to pay for performance trials, then more than likely performance doesn't matter. You are then free to focus your architectural efforts on aspects of the system that are worth paying for.
-
-	"Must respond to user input in no more than 1500 milliseconds. Under normal load (defined as...) the average response time must be between 750 and 1250 milliseconds. Response times less than 500 milliseconds can't be distinguished by the user, so we won't pay to go below that." Now ''that's'' a ''requirement''.
-
	By [[Keith Braithwaite]]		By [[Keith Braithwaite]]

KeithBraithwaite: /* Lessons From Built Architecture */

2008-07-06T18:44:13Z

Lessons From Built Architecture

←Older revision		Revision as of 18:44, 6 July 2008
Line 1:		Line 1:
	Work in progress		Work in progress

-	==Lessons From Built Architecture==	+	==Lessons From Built Architecture?==
	Simile and metaphor drawn form one professional domain is often of limited applicability in another. Calling the high–most technical lead of a software project the "architect" is some sort of mixture of hubris, grandiosity, (self)delusion and propaganda. What can we learn from the words of building architects that might help with that?		Simile and metaphor drawn form one professional domain is often of limited applicability in another. Calling the high–most technical lead of a software project the "architect" is some sort of mixture of hubris, grandiosity, (self)delusion and propaganda. What can we learn from the words of building architects that might help with that?

Line 27:		Line 27:

	"It seems a fantastic paradox, but it is nevertheless a most important truth, that no architecture can be truly noble which is not imperfect."—ibid		"It seems a fantastic paradox, but it is nevertheless a most important truth, that no architecture can be truly noble which is not imperfect."—ibid
		+
		+	== Quantify ==
		+
		+	"Fast" is not a requirement. Neither is "responsive". Nor "extensible". The worst reason why not is that you have no objective way to tell if they're met. But still users want them.
		+
		+	The architect's role is largely to help the system have these qualities. And to balance the inevitable conflicts and inconsistencies between them. Without objective criteria architects are at the mercy of capricious users ("no, I won't accept it, still not fast enough") and of obsessive programmers ("no, I won't release it, still not fast enough").
		+
		+	As with all requirements we seek to write down these desires. Too often then the vague adjectives come out: "flexible", "maintainable" and the rest. It turns out that in every case (yes even "usable", with effort) these phenomena can be quantified and thresholds set. If this is not done then there is no basis for acceptance of the system by its users, valuable guidance is stolen from its builders as they work, and the vision is blurred of those architecting it.
		+
		+	Some simple questions to ask: How many? In what period? How often? How soon? Increasing or decreasing? At what rate? If these questions cannot be answered then the need is not understood. The answers should be in the business case for the system and if they are not, then some hard thinking needs to be done. If you work as an architect and the business hasn't (or won't) tell you these numbers ask yourself why not. Then go get them.
		+
		+	The next time someone tells you that a system needs to be "scalable" ask them where from and why these users are going to come. Ask how many and by when? Reject "Lots" and "soon" as answers.
		+
		+	Uncertain quantitative criteria (which in mainstream development these will be—hard real–time folks have their own problems) must be given as a range: the least acceptable, the nominal, and the most worth paying for. If this range cannot be given, then the required behavior is not understood. As an architecture unfolds it can be checked against these criteria to see if it is (still) in tolerance. As the performance against some criteria drifts over time, valuable feedback is obtained.
		+
		+	Finding these ranges and checking against them is a time-consuming and expensive business. If no one cares enough about the system being "performant" (neither a requirement nor a word) to pay for performance trials, then more than likely performance doesn't matter. You are then free to focus your architectural efforts on aspects of the system that are worth paying for.
		+
		+	"Must respond to user input in no more than 1500 milliseconds. Under normal load (defined as...) the average response time must be between 750 and 1250 milliseconds. Response times less than 500 milliseconds can't be distinguished by the user, so we won't pay to go below that." Now ''that's'' a ''requirement''.
		+
		+	By [[Keith Braithwaite]]
		+
		+
		+	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

KeithBraithwaite: begun

2008-07-06T18:42:36Z

begun

New page

Work in progress

==Lessons From Built Architecture==
Simile and metaphor drawn form one professional domain is often of limited applicability in another. Calling the high–most technical lead of a software project the "architect" is some sort of mixture of hubris, grandiosity, (self)delusion and propaganda. What can we learn from the words of building architects that might help with that?

[note to editors: I don't have rock solid references for all of these yet, but will be hitting the British Library next weekend to check them out].

“Architecture is a social act and the material theater of human activity.”—Spiro Kostof

How many software architects see their role as primarily technical? Is it not rather that they are the conciliators, go–betweens and arbiters of the warring factions within the stake-holders?

“A great architect is not made by way of a brain nearly so much as he is made by way of a cultivated, enriched heart.”—Frank Lloyd Wright

What more strongly marks out the architects in your organisation: raw intellectual horsepower and vast capacity to recall technical minutia, or taste, refinement and generosity of spirit? Would you rather it were otherwise?

“A doctor can bury his mistakes but an architect can only advise his client to plant vines.”—ibid

Is the "maintenance" of "legacy" systems anything more than pruning vines?

“Architects believe that not only do they sit at the right hand of God, but that if God ever gets up, they take the chair”—Karen Moyer

“Architecture is politics.”—Mitchell Kapor

“In architecture as in all other operative arts, the end must direct the operation. The end is to build well. Well building has three conditions: Commodity, Firmness and Delight.”—Henry Watton

"No person who is not a great sculptor or painter can be an architect. If he is not a sculptor or painter, he can only be a builder"—John Ruskin

"It seems a fantastic paradox, but it is nevertheless a most important truth, that no architecture can be truly noble which is not imperfect."—ibid