Contribution 21 - Revision history

Kevlin at 21:03, 2 July 2008

Kevlin — Wed, 02 Jul 2008 21:03:18 GMT

←Older revision		Revision as of 21:03, 2 July 2008
Line 1:		Line 1:
	== Simplicity before generality, use before reuse ==		== Simplicity before generality, use before reuse ==

-	A common problem ~~we find~~ in component frameworks, class libraries, foundation services, and other infrastructure code is that many are designed to be general purpose without reference to concrete applications. This leads to a dizzying array of options and possibilities that are often unused, misused, or just not useful. Most developers work on specific systems ~~and~~ the quest for unbounded generality rarely serves them well, if at all. The best route to generality is through understanding known, specific examples and focusing on their essence to find an essential common solution. Simplicity through experience rather than generality through guesswork.	+	A common problem in component frameworks, class libraries, foundation services, and other infrastructure code is that many are designed to be general purpose without reference to concrete applications. This leads to a dizzying array of options and possibilities that are often unused, misused, or just not useful. Most developers work on specific systems: the quest for unbounded generality rarely serves them well (if at all). The best route to generality is through understanding known, specific examples and focusing on their essence to find an essential common solution. Simplicity through experience rather than generality through guesswork.

	Favoring simplicity before generality acts as a tiebreaker between otherwise equally viable design alternatives. When there are two possible solutions, favor the one that is simpler and based on concrete need rather than the more intricate one that boasts of generality. Of course, it is entirely possible (and more than a little likely) that the simpler solution will turn out to be the more general one in practice. And if that doesn't turn out to be the case, it will be easier to change the simpler solution to what you now know you need than to change the 'general' one that turns out not to be quite general enough in the right way.		Favoring simplicity before generality acts as a tiebreaker between otherwise equally viable design alternatives. When there are two possible solutions, favor the one that is simpler and based on concrete need rather than the more intricate one that boasts of generality. Of course, it is entirely possible (and more than a little likely) that the simpler solution will turn out to be the more general one in practice. And if that doesn't turn out to be the case, it will be easier to change the simpler solution to what you now know you need than to change the 'general' one that turns out not to be quite general enough in the right way.

-	Although well meant, many things that are designed just to be general purpose often end up satisfying no purpose~~. A somewhat hyped and optimistic notion of reuse is undoubtedly responsible for many components and frameworks that, with hindsight, turn out to be awkward to use~~. Software components should, first and foremost, be designed for use and to fulfill that use well. ~~Designing for all seasons~~ is ~~both difficult~~ and ~~not always desirable~~, a ~~realization~~ that ~~helps explain~~ the ~~small markets for thermal bikinis~~ and ~~Ford Edsels~~, ~~as well as~~ the ~~challenge of designing general-purpose software components~~.	+	Although well meant, many things that are designed just to be general purpose often end up satisfying no purpose. Software components should, first and foremost, be designed for use and to fulfill that use well. Effective generality comes from understanding, and understanding leads to simplification. Generalization can allow us to reduce a problem to something more essential, resulting in an approach that embodies regularity across known examples, a regularity that is crisp, concise, and well grounded. However, too often generalization becomes a work item in itself, pulling in the opposite direction, adding to the complexity rather than reducing it. The pursuit of speculative generality often leads to solutions that are not anchored in the reality of actual development. They are based on assumptions that later turn out to be wrong, offer choices that later turn out not to be useful, and accumulate baggage that becomes difficult or impossible to remove, thereby adding to the accidental complexity developers and future architects must face.

-	Effective generality comes from understanding, and understanding leads to simplification. Generalization can be used as a cognitive tool, allowing us to reduce a problem to something more essential, resulting in an approach that embodies regularity across known examples, a regularity that is crisp, concise, and well grounded. However, too often generalization becomes a work item in itself, pulling in the opposite direction, adding to the complexity rather than reducing it. The initial sweetness of a general solution can become overwhelmingly syrupy as it grows. The pursuit of speculative generality often leads to solutions that are not anchored in the reality of actual development. They are based on assumptions that later turn out to be wrong, offer choices that later turn out not to be useful, and accumulate baggage that becomes difficult or impossible to remove, thereby adding to the accidental complexity developers and future architects must face.	+	Although many architects value generality, it should not be unconditional. People do not on the whole pay for (or need) generality: They tend to have a specific situation, and it is a solution to that specific situation that has value. We can find generality and flexibility in trying to deliver specific solutions, but if we weigh anchor and forget the specifics too soon, we end up adrift in a sea of nebulous possibilities, a world of tricky configuration options, overburdened (not just overloaded) parameter lists, long-winded interfaces, and not-quite right abstractions. In pursuit of arbitrary flexibility you can often lose valuable properties, accidental or intended, of alternative, simpler designs.
-		+
-	Flexibility is a double-edged sword. If flexibility is based on variability found in known examples, the design will be sharper. But if flexibility is driven by "maybe"s and "what if"s, this is not concrete enough to start adding hooks, options, and other bells and whistles. This kind of speculation is a potentially unbounded set -- "There are more things in heaven and earth, Horatio, than are dreamt of in your philosophy" -- leading to features that are no longer justifiable in terms of common usage or priority. Speculation is a powerful tool in architecture, but for exploration and evaluation not for embellishment and embodiment.	+
-		+
-	~~If we equate flexibility with degrees of freedom, then the degrees of freedom in a design should be reasonable and reasoned.~~ Although many architects value generality, it should not be unconditional. People do not on the whole pay for (or need) generality: They tend to have a specific situation, and it is a solution to that specific situation that has value. We can find generality and flexibility in trying to deliver specific solutions, but if we weigh anchor and forget the specifics too soon, we end up adrift in a sea of nebulous possibilities, a world of tricky configuration options, overburdened (not just overloaded) parameter lists, long-winded interfaces, and not-quite right abstractions. In pursuit of arbitrary flexibility you can often lose valuable properties, accidental or intended, of alternative, simpler designs.	+

	By [[Kevlin Henney]]		By [[Kevlin Henney]]

-	(Edited RMH 2008-05-28, re-edited KH 2008-06-11)	+	(Edited RMH 2008-05-28, re-edited KH 2008-06-11 & 2008-07-02)

	This work is licensed under a		This work is licensed under a

Kevlin at 13:02, 11 June 2008

Kevlin — Wed, 11 Jun 2008 13:02:51 GMT

←Older revision		Revision as of 13:02, 11 June 2008
Line 15:		Line 15:
	By [[Kevlin Henney]]		By [[Kevlin Henney]]

-	(Edited RMH 5/28/2008)	+	(Edited RMH 2008-05-28, re-edited KH 2008-06-11)

	This work is licensed under a		This work is licensed under a

Kevlin at 13:01, 11 June 2008

Kevlin — Wed, 11 Jun 2008 13:01:41 GMT

←Older revision		Revision as of 13:01, 11 June 2008
Line 1:		Line 1:
	== Simplicity before generality, use before reuse ==		== Simplicity before generality, use before reuse ==

-	A common problem we find in component frameworks, class libraries, foundation services, and other infrastructure code is that many are designed to be general purpose without reference to concrete applications. This leads to a dizzying array of options and possibilities that are often unused, misused, or just not useful. Most developers work on specific systems and the quest for unbounded generality ~~does~~ rarely ~~serve~~ them well, if at all. The best route to generality is through understanding known, specific examples and focusing on their essence to find an essential common solution. Simplicity through experience rather than generality through guesswork.	+	A common problem we find in component frameworks, class libraries, foundation services, and other infrastructure code is that many are designed to be general purpose without reference to concrete applications. This leads to a dizzying array of options and possibilities that are often unused, misused, or just not useful. Most developers work on specific systems and the quest for unbounded generality rarely serves them well, if at all. The best route to generality is through understanding known, specific examples and focusing on their essence to find an essential common solution. Simplicity through experience rather than generality through guesswork.

-	~~This maxim, of favoring~~ simplicity before generality, acts as a tiebreaker between otherwise equally viable design alternatives. When there are two possible solutions, favor the one that is simpler and based on concrete need rather than the more intricate one that boasts of generality. Of course, it is entirely possible (and more than a little likely) that the simpler solution will turn out to be the more general one in practice. And if that doesn't turn out to be the case, it will be easier to change the simpler solution to what you now know you need than to change the 'general' one that turns out not to be quite general enough in the right way.	+	Favoring simplicity before generality acts as a tiebreaker between otherwise equally viable design alternatives. When there are two possible solutions, favor the one that is simpler and based on concrete need rather than the more intricate one that boasts of generality. Of course, it is entirely possible (and more than a little likely) that the simpler solution will turn out to be the more general one in practice. And if that doesn't turn out to be the case, it will be easier to change the simpler solution to what you now know you need than to change the 'general' one that turns out not to be quite general enough in the right way.

-	~~Many~~ things that are designed just to be general purpose often end up satisfying no purpose. A somewhat hyped and optimistic notion of reuse is undoubtedly responsible for many components and frameworks that, with hindsight, turn out to be awkward to use. Software components should, first and foremost, be designed for use and to fulfill that use well. Designing for all seasons is both difficult and not always desirable, a realization that helps explain the small markets for thermal bikinis and Ford Edsels, as well as the challenge of designing general-purpose software components.	+	Although well meant, many things that are designed just to be general purpose often end up satisfying no purpose. A somewhat hyped and optimistic notion of reuse is undoubtedly responsible for many components and frameworks that, with hindsight, turn out to be awkward to use. Software components should, first and foremost, be designed for use and to fulfill that use well. Designing for all seasons is both difficult and not always desirable, a realization that helps explain the small markets for thermal bikinis and Ford Edsels, as well as the challenge of designing general-purpose software components.

-	Effective generality comes from understanding, and understanding leads to simplification. Generalization can be used as a cognitive tool, allowing us to reduce a problem to something more essential, resulting in an approach that embodies regularity across known examples, a regularity that is crisp, concise, and well grounded. However, too often generalization becomes a work item in itself, pulling in the opposite direction, adding to the complexity rather than reducing it. The initial sweetness of a general solution can become ~~overwhelming~~ syrupy as it grows. The pursuit of speculative generality often leads to solutions that are not anchored in the reality of actual development~~, making~~ assumptions that later turn out to be wrong, ~~offering~~ choices that later turn out not to be useful, and ~~adding~~ baggage that becomes difficult or impossible to remove, thereby adding to the accidental complexity developers and future architects must face.	+	Effective generality comes from understanding, and understanding leads to simplification. Generalization can be used as a cognitive tool, allowing us to reduce a problem to something more essential, resulting in an approach that embodies regularity across known examples, a regularity that is crisp, concise, and well grounded. However, too often generalization becomes a work item in itself, pulling in the opposite direction, adding to the complexity rather than reducing it. The initial sweetness of a general solution can become overwhelmingly syrupy as it grows. The pursuit of speculative generality often leads to solutions that are not anchored in the reality of actual development. They are based on assumptions that later turn out to be wrong, offer choices that later turn out not to be useful, and accumulate baggage that becomes difficult or impossible to remove, thereby adding to the accidental complexity developers and future architects must face.

-	~~Design involves compromise, and flexibility~~ is a double-edged sword. If ~~the~~ flexibility is based on variability found in known examples, the design will be sharper. But if ~~the~~ flexibility is driven by "maybe"s and "what if"s, this is not concrete enough to start adding hooks, options, and other bells and whistles. This kind of speculation is a potentially unbounded set -- "There are more things in heaven and earth, Horatio, than are dreamt of in your philosophy." ~~Features~~ are no longer ~~based on~~ common usage or priority~~, and so the justification for their proper inclusion is missing~~. Speculation is a powerful tool in architecture, but for exploration and evaluation not for embellishment and embodiment.	+	Flexibility is a double-edged sword. If flexibility is based on variability found in known examples, the design will be sharper. But if flexibility is driven by "maybe"s and "what if"s, this is not concrete enough to start adding hooks, options, and other bells and whistles. This kind of speculation is a potentially unbounded set -- "There are more things in heaven and earth, Horatio, than are dreamt of in your philosophy" -- leading to features that are no longer justifiable in terms of common usage or priority. Speculation is a powerful tool in architecture, but for exploration and evaluation not for embellishment and embodiment.

-	If we equate flexibility with degrees of freedom, then the degrees of freedom in a design should be reasonable and reasoned. Although many architects value generality, ~~people~~ do not on the whole pay for (or need) it: They tend to have a specific situation, and it is a solution that ~~gives them~~ value. We can find generality and flexibility in trying to deliver specific solutions, but if we weigh anchor and forget the specifics too soon, we end up adrift in a sea of nebulous possibilities, a world of tricky configuration options, overburdened (not just overloaded) parameter lists, long-winded interfaces, and not-quite right abstractions. In pursuit of arbitrary flexibility you can often lose valuable properties, accidental or intended, of alternative, simpler designs.	+	If we equate flexibility with degrees of freedom, then the degrees of freedom in a design should be reasonable and reasoned. Although many architects value generality, it should not be unconditional. People do not on the whole pay for (or need) generality: They tend to have a specific situation, and it is a solution to that specific situation that has value. We can find generality and flexibility in trying to deliver specific solutions, but if we weigh anchor and forget the specifics too soon, we end up adrift in a sea of nebulous possibilities, a world of tricky configuration options, overburdened (not just overloaded) parameter lists, long-winded interfaces, and not-quite right abstractions. In pursuit of arbitrary flexibility you can often lose valuable properties, accidental or intended, of alternative, simpler designs.

	By [[Kevlin Henney]]		By [[Kevlin Henney]]

Kevlin at 12:50, 11 June 2008

Kevlin — Wed, 11 Jun 2008 12:50:35 GMT

←Older revision		Revision as of 12:50, 11 June 2008
Line 1:		Line 1:
	== Simplicity before generality, use before reuse ==		== Simplicity before generality, use before reuse ==

-	A common problem we find in component frameworks, class libraries, foundation services, and other infrastructure code is that many are designed to be general purpose without reference to ~~actual systems~~. This leads to a dizzying array of options and possibilities that are often unused, misused, or just not useful. ~~However, most~~ developers work on specific systems, and the quest for generality does ~~not always~~ serve them well. The best route to generality is through understanding ~~well-defined~~ specific examples and focusing on their essence to find an essential common solution. Simplicity through experience, rather than generality through guesswork.	+	A common problem we find in component frameworks, class libraries, foundation services, and other infrastructure code is that many are designed to be general purpose without reference to concrete applications. This leads to a dizzying array of options and possibilities that are often unused, misused, or just not useful. Most developers work on specific systems and the quest for unbounded generality does rarely serve them well, if at all. The best route to generality is through understanding known, specific examples and focusing on their essence to find an essential common solution. Simplicity through experience rather than generality through guesswork.

-	This maxim, of favoring simplicity before generality, acts as a tiebreaker between otherwise equally viable design alternatives. When there are two possible solutions, favor the one that is simpler and based on concrete need rather than the more intricate one that boasts of generality. Of course, it is entirely possible (and more than a little likely) that the simpler solution will turn out to be the more general one in practice. And if that doesn't turn out to be the case, it will be easier to change the simpler solution to what you now know you need than to change the general one that turns out not to be quite general enough in the right way.	+	This maxim, of favoring simplicity before generality, acts as a tiebreaker between otherwise equally viable design alternatives. When there are two possible solutions, favor the one that is simpler and based on concrete need rather than the more intricate one that boasts of generality. Of course, it is entirely possible (and more than a little likely) that the simpler solution will turn out to be the more general one in practice. And if that doesn't turn out to be the case, it will be easier to change the simpler solution to what you now know you need than to change the 'general' one that turns out not to be quite general enough in the right way.

-	Many things that are designed just to be general purpose often end up satisfying no purpose. A somewhat hyped and optimistic notion of reuse is undoubtedly responsible for many components and frameworks that, with hindsight, turn out to be awkward to use. Software components should, first and foremost, be designed for use, and to fulfill that use well. Designing for all seasons is both difficult and not always desirable, a realization that helps explain the small markets for thermal bikinis and Ford Edsels, as well as the challenge of designing general-purpose software components.	+	Many things that are designed just to be general purpose often end up satisfying no purpose. A somewhat hyped and optimistic notion of reuse is undoubtedly responsible for many components and frameworks that, with hindsight, turn out to be awkward to use. Software components should, first and foremost, be designed for use and to fulfill that use well. Designing for all seasons is both difficult and not always desirable, a realization that helps explain the small markets for thermal bikinis and Ford Edsels, as well as the challenge of designing general-purpose software components.

-	Effective generality comes from understanding, and understanding leads to simplification. Generalization can be used as a cognitive tool, allowing us to reduce a problem to something more essential, resulting in an approach that embodies regularity across known examples, a regularity that is crisp, concise, and well grounded. However, too often generalization becomes a work item in itself, pulling in the opposite direction, adding to the complexity rather than reducing it. The initial sweetness of a general solution can become overwhelming as it grows~~, to the point that we feel like we are drowning in syrup~~. The pursuit of speculative generality often leads to solutions that are not anchored in the reality of actual development, making assumptions that later turn out to be wrong, offering choices that later turn out not to be useful, and adding baggage that becomes difficult or impossible to remove, thereby adding to the accidental complexity developers and future architects must face.	+	Effective generality comes from understanding, and understanding leads to simplification. Generalization can be used as a cognitive tool, allowing us to reduce a problem to something more essential, resulting in an approach that embodies regularity across known examples, a regularity that is crisp, concise, and well grounded. However, too often generalization becomes a work item in itself, pulling in the opposite direction, adding to the complexity rather than reducing it. The initial sweetness of a general solution can become overwhelming syrupy as it grows. The pursuit of speculative generality often leads to solutions that are not anchored in the reality of actual development, making assumptions that later turn out to be wrong, offering choices that later turn out not to be useful, and adding baggage that becomes difficult or impossible to remove, thereby adding to the accidental complexity developers and future architects must face.

-	Design involves compromise, and flexibility is a double-edged sword. If the flexibility is based on variability found in known examples, the design will be sharper. But if the flexibility is driven by "maybe"s and "what if"s, this is not concrete enough to start adding hooks, options, and other bells and whistles. This kind of speculation is a potentially unbounded set -- "There are more things in heaven and earth, Horatio, than are dreamt of in your philosophy." Features are no longer based on common usage or priority, and so the justification for their proper inclusion is missing. Speculation is a powerful tool in architecture, but for exploration and evaluation, not for embellishment and embodiment.	+	Design involves compromise, and flexibility is a double-edged sword. If the flexibility is based on variability found in known examples, the design will be sharper. But if the flexibility is driven by "maybe"s and "what if"s, this is not concrete enough to start adding hooks, options, and other bells and whistles. This kind of speculation is a potentially unbounded set -- "There are more things in heaven and earth, Horatio, than are dreamt of in your philosophy." Features are no longer based on common usage or priority, and so the justification for their proper inclusion is missing. Speculation is a powerful tool in architecture, but for exploration and evaluation not for embellishment and embodiment.

	If we equate flexibility with degrees of freedom, then the degrees of freedom in a design should be reasonable and reasoned. Although many architects value generality, people do not on the whole pay for (or need) it: They tend to have a specific situation, and it is a solution that gives them value. We can find generality and flexibility in trying to deliver specific solutions, but if we weigh anchor and forget the specifics too soon, we end up adrift in a sea of nebulous possibilities, a world of tricky configuration options, overburdened (not just overloaded) parameter lists, long-winded interfaces, and not-quite right abstractions. In pursuit of arbitrary flexibility you can often lose valuable properties, accidental or intended, of alternative, simpler designs.		If we equate flexibility with degrees of freedom, then the degrees of freedom in a design should be reasonable and reasoned. Although many architects value generality, people do not on the whole pay for (or need) it: They tend to have a specific situation, and it is a solution that gives them value. We can find generality and flexibility in trying to deliver specific solutions, but if we weigh anchor and forget the specifics too soon, we end up adrift in a sea of nebulous possibilities, a world of tricky configuration options, overburdened (not just overloaded) parameter lists, long-winded interfaces, and not-quite right abstractions. In pursuit of arbitrary flexibility you can often lose valuable properties, accidental or intended, of alternative, simpler designs.

Rmonson at 14:10, 28 May 2008

Rmonson — Wed, 28 May 2008 14:10:33 GMT

←Older revision		Revision as of 14:10, 28 May 2008
Line 7:		Line 7:
	Many things that are designed just to be general purpose often end up satisfying no purpose. A somewhat hyped and optimistic notion of reuse is undoubtedly responsible for many components and frameworks that, with hindsight, turn out to be awkward to use. Software components should, first and foremost, be designed for use, and to fulfill that use well. Designing for all seasons is both difficult and not always desirable, a realization that helps explain the small markets for thermal bikinis and Ford Edsels, as well as the challenge of designing general-purpose software components.		Many things that are designed just to be general purpose often end up satisfying no purpose. A somewhat hyped and optimistic notion of reuse is undoubtedly responsible for many components and frameworks that, with hindsight, turn out to be awkward to use. Software components should, first and foremost, be designed for use, and to fulfill that use well. Designing for all seasons is both difficult and not always desirable, a realization that helps explain the small markets for thermal bikinis and Ford Edsels, as well as the challenge of designing general-purpose software components.

-	Effective generality comes from understanding, and understanding leads to simplification. Generalization can be used as a cognitive tool, allowing us to reduce a problem to something more essential, resulting in an approach that embodies a regularity across known examples, a regularity that is crisp, concise, and well grounded. However, too often generalization becomes a work item in itself, pulling in the opposite direction, adding to the complexity rather than reducing it. The initial sweetness of a general solution can become overwhelming as it grows, to the point that we feel like we are drowning in syrup. The pursuit of speculative generality often leads to solutions that are not anchored in the reality of actual development, making assumptions that later turn out to be wrong, offering choices that later turn out not to be useful, and adding baggage that becomes difficult or impossible to remove, thereby adding to the accidental complexity developers and future architects must face.	+	Effective generality comes from understanding, and understanding leads to simplification. Generalization can be used as a cognitive tool, allowing us to reduce a problem to something more essential, resulting in an approach that embodies regularity across known examples, a regularity that is crisp, concise, and well grounded. However, too often generalization becomes a work item in itself, pulling in the opposite direction, adding to the complexity rather than reducing it. The initial sweetness of a general solution can become overwhelming as it grows, to the point that we feel like we are drowning in syrup. The pursuit of speculative generality often leads to solutions that are not anchored in the reality of actual development, making assumptions that later turn out to be wrong, offering choices that later turn out not to be useful, and adding baggage that becomes difficult or impossible to remove, thereby adding to the accidental complexity developers and future architects must face.

	Design involves compromise, and flexibility is a double-edged sword. If the flexibility is based on variability found in known examples, the design will be sharper. But if the flexibility is driven by "maybe"s and "what if"s, this is not concrete enough to start adding hooks, options, and other bells and whistles. This kind of speculation is a potentially unbounded set -- "There are more things in heaven and earth, Horatio, than are dreamt of in your philosophy." Features are no longer based on common usage or priority, and so the justification for their proper inclusion is missing. Speculation is a powerful tool in architecture, but for exploration and evaluation, not for embellishment and embodiment.		Design involves compromise, and flexibility is a double-edged sword. If the flexibility is based on variability found in known examples, the design will be sharper. But if the flexibility is driven by "maybe"s and "what if"s, this is not concrete enough to start adding hooks, options, and other bells and whistles. This kind of speculation is a potentially unbounded set -- "There are more things in heaven and earth, Horatio, than are dreamt of in your philosophy." Features are no longer based on common usage or priority, and so the justification for their proper inclusion is missing. Speculation is a powerful tool in architecture, but for exploration and evaluation, not for embellishment and embodiment.

-	If we equate flexibility with degrees of freedom, then the degrees of freedom in a design should be reasonable and reasoned. Although many architects value generality, people do not on the whole pay for (or need) it: They tend to have a specific situation, and it is a solution ~~for~~ that ~~which~~ gives them value. We can find generality and flexibility in trying to deliver specific solutions, but if we weigh anchor and forget the specifics too soon, we end up adrift in a sea of nebulous possibilities, a world of ~~tricksy~~ configuration options, overburdened (not just overloaded) parameter lists, long-winded interfaces, and not-quite right abstractions. In pursuit of arbitrary flexibility you can often lose valuable properties, accidental or intended, of alternative, simpler designs.	+	If we equate flexibility with degrees of freedom, then the degrees of freedom in a design should be reasonable and reasoned. Although many architects value generality, people do not on the whole pay for (or need) it: They tend to have a specific situation, and it is a solution that gives them value. We can find generality and flexibility in trying to deliver specific solutions, but if we weigh anchor and forget the specifics too soon, we end up adrift in a sea of nebulous possibilities, a world of tricky configuration options, overburdened (not just overloaded) parameter lists, long-winded interfaces, and not-quite right abstractions. In pursuit of arbitrary flexibility you can often lose valuable properties, accidental or intended, of alternative, simpler designs.

	By [[Kevlin Henney]]		By [[Kevlin Henney]]
		+
		+	(Edited RMH 5/28/2008)

	This work is licensed under a		This work is licensed under a

Kevlin at 21:48, 15 May 2008

Kevlin — Thu, 15 May 2008 21:48:55 GMT

←Older revision		Revision as of 21:48, 15 May 2008
Line 1:		Line 1:
	== Simplicity before generality, use before reuse ==		== Simplicity before generality, use before reuse ==

-	A common problem we find in component frameworks, class libraries, foundation services, and other infrastructure code is that ~~they~~ are designed to be general purpose without reference to actual systems. This leads to a dizzying array of options that are often unused, misused, or just not useful. However, most developers work on specific systems, and the quest for generality does not always serve them well. The best route to generality is through understanding well-defined specific examples and focusing on ~~the~~ essence ~~and their~~ essential common solution. Simplicity through experience, ~~not~~ generality through guesswork.	+	A common problem we find in component frameworks, class libraries, foundation services, and other infrastructure code is that many are designed to be general purpose without reference to actual systems. This leads to a dizzying array of options and possibilities that are often unused, misused, or just not useful. However, most developers work on specific systems, and the quest for generality does not always serve them well. The best route to generality is through understanding well-defined specific examples and focusing on their essence to find an essential common solution. Simplicity through experience, rather than generality through guesswork.

-	This maxim, of favoring simplicity before generality, acts as a tiebreaker between otherwise equally viable design alternatives. When there are two possible solutions, favor the one that is simpler and based on concrete need rather than the more intricate one that boasts of generality. Of course, it is entirely possible (and ~~quite~~ likely) that the simpler solution will turn out to be the more general one. And if it doesn't, it will be easier to change the simpler solution to what you need than to change the general one that turns out not to be quite general enough in the right way.	+	This maxim, of favoring simplicity before generality, acts as a tiebreaker between otherwise equally viable design alternatives. When there are two possible solutions, favor the one that is simpler and based on concrete need rather than the more intricate one that boasts of generality. Of course, it is entirely possible (and more than a little likely) that the simpler solution will turn out to be the more general one in practice. And if that doesn't turn out to be the case, it will be easier to change the simpler solution to what you now know you need than to change the general one that turns out not to be quite general enough in the right way.

-	Many things that are designed just to be general purpose often end up satisfying no purpose. Software components should, first and foremost, be designed for use, and to fulfill that use well. Designing for all seasons is both difficult and not always desirable, a realization that helps explain the small markets for thermal bikinis and Ford Edsels, as well as the challenge of designing general-purpose software components.	+	Many things that are designed just to be general purpose often end up satisfying no purpose. A somewhat hyped and optimistic notion of reuse is undoubtedly responsible for many components and frameworks that, with hindsight, turn out to be awkward to use. Software components should, first and foremost, be designed for use, and to fulfill that use well. Designing for all seasons is both difficult and not always desirable, a realization that helps explain the small markets for thermal bikinis and Ford Edsels, as well as the challenge of designing general-purpose software components.

-	~~Generality should equate to simplicity~~ and simplification. Generalization can be used as a cognitive tool, allowing us to reduce a problem to something more essential, resulting in an approach that embodies a regularity across known examples, a regularity that is crisp, concise, and well grounded. However, too often generalization becomes a work item in itself, ~~and pulls~~ in the opposite direction, adding to the complexity rather than reducing it. The initial sweetness of a general solution can become overwhelming as it grows, to the point that we feel like we are drowning in syrup. The pursuit of speculative generality often leads to solutions that are not anchored in the reality of actual development, making assumptions that later turn out to be wrong, offering choices that later turn out not to be useful, and adding baggage that becomes difficult or impossible to remove, thereby adding to the accidental complexity developers and future architects must face.	+	Effective generality comes from understanding, and understanding leads to simplification. Generalization can be used as a cognitive tool, allowing us to reduce a problem to something more essential, resulting in an approach that embodies a regularity across known examples, a regularity that is crisp, concise, and well grounded. However, too often generalization becomes a work item in itself, pulling in the opposite direction, adding to the complexity rather than reducing it. The initial sweetness of a general solution can become overwhelming as it grows, to the point that we feel like we are drowning in syrup. The pursuit of speculative generality often leads to solutions that are not anchored in the reality of actual development, making assumptions that later turn out to be wrong, offering choices that later turn out not to be useful, and adding baggage that becomes difficult or impossible to remove, thereby adding to the accidental complexity developers and future architects must face.

-	Design involves compromise, and ~~all~~ flexibility is a double-edged sword. If the flexibility is based on variability found in known examples, ~~there is a win to~~ be ~~had~~. But if the flexibility is driven by "maybe"s and "what if"s, this is not concrete enough to start adding hooks, options, and other ~~features~~. This kind of speculation is a potentially unbounded set -- "There are more things in heaven and earth, Horatio, than are dreamt of in your philosophy." ~~Once you start down that road, it is difficult to know where to stop.~~ Features are no longer based on common usage or priority, and so the ~~rationale~~ for their proper inclusion is missing.	+	Design involves compromise, and flexibility is a double-edged sword. If the flexibility is based on variability found in known examples, the design will be sharper. But if the flexibility is driven by "maybe"s and "what if"s, this is not concrete enough to start adding hooks, options, and other bells and whistles. This kind of speculation is a potentially unbounded set -- "There are more things in heaven and earth, Horatio, than are dreamt of in your philosophy." Features are no longer based on common usage or priority, and so the justification for their proper inclusion is missing. Speculation is a powerful tool in architecture, but for exploration and evaluation, not for embellishment and embodiment.

-	If we equate flexibility with degrees of freedom, then the degrees of freedom in a design should be reasonable and reasoned. Although many architects value generality, people do not on the whole pay for (or need) it: They tend to have a specific situation, and it is ~~the~~ solution for that which gives them value. We can find generality and flexibility in trying to deliver specific solutions, but if we weigh anchor and forget the specifics too soon, we end up adrift in a sea of nebulous possibilities, a world of tricksy configuration options ~~and~~ parameter lists, long-winded interfaces, and not-quite right abstractions. In pursuit of arbitrary flexibility you can often lose valuable properties, accidental or intended, of alternative, simpler designs.	+	If we equate flexibility with degrees of freedom, then the degrees of freedom in a design should be reasonable and reasoned. Although many architects value generality, people do not on the whole pay for (or need) it: They tend to have a specific situation, and it is a solution for that which gives them value. We can find generality and flexibility in trying to deliver specific solutions, but if we weigh anchor and forget the specifics too soon, we end up adrift in a sea of nebulous possibilities, a world of tricksy configuration options, overburdened (not just overloaded) parameter lists, long-winded interfaces, and not-quite right abstractions. In pursuit of arbitrary flexibility you can often lose valuable properties, accidental or intended, of alternative, simpler designs.

	By [[Kevlin Henney]]		By [[Kevlin Henney]]

Kevlin at 20:04, 15 May 2008

Kevlin — Thu, 15 May 2008 20:04:02 GMT

←Older revision		Revision as of 20:04, 15 May 2008
Line 1:		Line 1:
	== Simplicity before generality, use before reuse ==		== Simplicity before generality, use before reuse ==

-	A common problem we find in frameworks, libraries and other infrastructure code is that they are designed to be general purpose without reference to actual systems. This leads to a dizzying array of options that are often unused, misused, or just not useful. However, most developers work on specific systems, and the quest for generality does not always serve them well. The best route to generality is through understanding well-defined specific examples~~. So, this principle acts as a tiebreaker between otherwise equally viable design alternatives. When there are two possible solutions, favor the one that is simpler~~ and ~~based~~ on ~~concrete need rather than~~ the ~~more intricate one that boasts of generality. Of course, it is entirely possible (~~and ~~quite likely) that the simpler~~ solution ~~will turn out to be the more general one~~. ~~And if it doesn't~~, ~~it will be easier to change the simpler solution to what you need than to change the general one that turns out~~ not ~~to be quite general enough in the right way~~.	+	A common problem we find in component frameworks, class libraries, foundation services, and other infrastructure code is that they are designed to be general purpose without reference to actual systems. This leads to a dizzying array of options that are often unused, misused, or just not useful. However, most developers work on specific systems, and the quest for generality does not always serve them well. The best route to generality is through understanding well-defined specific examples and focusing on the essence and their essential common solution. Simplicity through experience, not generality through guesswork.

-	Many things that are designed to be general purpose often end up satisfying no purpose. Software components should, first and foremost, be designed for use, and to fulfill that use well. Designing for all seasons is both difficult and not always desirable, a realization that helps explain the small markets for thermal bikinis and Ford Edsels, as well as the challenge of designing general-purpose software components.	+	This maxim, of favoring simplicity before generality, acts as a tiebreaker between otherwise equally viable design alternatives. When there are two possible solutions, favor the one that is simpler and based on concrete need rather than the more intricate one that boasts of generality. Of course, it is entirely possible (and quite likely) that the simpler solution will turn out to be the more general one. And if it doesn't, it will be easier to change the simpler solution to what you need than to change the general one that turns out not to be quite general enough in the right way.
		+
		+	Many things that are designed just to be general purpose often end up satisfying no purpose. Software components should, first and foremost, be designed for use, and to fulfill that use well. Designing for all seasons is both difficult and not always desirable, a realization that helps explain the small markets for thermal bikinis and Ford Edsels, as well as the challenge of designing general-purpose software components.

	Generality should equate to simplicity and simplification. Generalization can be used as a cognitive tool, allowing us to reduce a problem to something more essential, resulting in an approach that embodies a regularity across known examples, a regularity that is crisp, concise, and well grounded. However, too often generalization becomes a work item in itself, and pulls in the opposite direction, adding to the complexity rather than reducing it. The initial sweetness of a general solution can become overwhelming as it grows, to the point that we feel like we are drowning in syrup. The pursuit of speculative generality often leads to solutions that are not anchored in the reality of actual development, making assumptions that later turn out to be wrong, offering choices that later turn out not to be useful, and adding baggage that becomes difficult or impossible to remove, thereby adding to the accidental complexity developers and future architects must face.		Generality should equate to simplicity and simplification. Generalization can be used as a cognitive tool, allowing us to reduce a problem to something more essential, resulting in an approach that embodies a regularity across known examples, a regularity that is crisp, concise, and well grounded. However, too often generalization becomes a work item in itself, and pulls in the opposite direction, adding to the complexity rather than reducing it. The initial sweetness of a general solution can become overwhelming as it grows, to the point that we feel like we are drowning in syrup. The pursuit of speculative generality often leads to solutions that are not anchored in the reality of actual development, making assumptions that later turn out to be wrong, offering choices that later turn out not to be useful, and adding baggage that becomes difficult or impossible to remove, thereby adding to the accidental complexity developers and future architects must face.

-	Design is compromise, and all flexibility is a double-edged sword. ~~Many people mistakenly see design decisions made in~~ the ~~name of~~ flexibility as win~~-only situations~~, a ~~narrowness~~ that ~~belies reality~~. If we equate flexibility with degrees of freedom, then the degrees of freedom in a design should be reasonable and reasoned. Although many ~~in software development~~ value generality, people do not on the whole pay for (or need) it: ~~they~~ tend to have a specific situation, and it is the solution for that which gives them value. We can find generality and flexibility in trying to deliver specific solutions, but if we weigh anchor and forget the specifics too soon, we end up adrift in a sea of nebulous possibilities, a world of tricksy configuration options and parameter lists, long-winded interfaces, and not-quite right abstractions. In pursuit of arbitrary flexibility you can often lose valuable properties, accidental or intended, of alternative designs.	+	Design involves compromise, and all flexibility is a double-edged sword. If the flexibility is based on variability found in known examples, there is a win to be had. But if the flexibility is driven by "maybe"s and "what if"s, this is not concrete enough to start adding hooks, options, and other features. This kind of speculation is a potentially unbounded set -- "There are more things in heaven and earth, Horatio, than are dreamt of in your philosophy." Once you start down that road, it is difficult to know where to stop. Features are no longer based on common usage or priority, and so the rationale for their proper inclusion is missing.
		+
		+	If we equate flexibility with degrees of freedom, then the degrees of freedom in a design should be reasonable and reasoned. Although many architects value generality, people do not on the whole pay for (or need) it: They tend to have a specific situation, and it is the solution for that which gives them value. We can find generality and flexibility in trying to deliver specific solutions, but if we weigh anchor and forget the specifics too soon, we end up adrift in a sea of nebulous possibilities, a world of tricksy configuration options and parameter lists, long-winded interfaces, and not-quite right abstractions. In pursuit of arbitrary flexibility you can often lose valuable properties, accidental or intended, of alternative, simpler designs.

	By [[Kevlin Henney]]		By [[Kevlin Henney]]

Kevlin: New page: == Simplicity before generality, use before reuse == A common problem we find in frameworks, libraries and other infrastructure code is that they are designed to be general purpose withou...

Kevlin — Thu, 15 May 2008 06:18:14 GMT

New page: == Simplicity before generality, use before reuse == A common problem we find in frameworks, libraries and other infrastructure code is that they are designed to be general purpose withou...

New page

== Simplicity before generality, use before reuse ==

A common problem we find in frameworks, libraries and other infrastructure code is that they are designed to be general purpose without reference to actual systems. This leads to a dizzying array of options that are often unused, misused, or just not useful. However, most developers work on specific systems, and the quest for generality does not always serve them well. The best route to generality is through understanding well-defined specific examples. So, this principle acts as a tiebreaker between otherwise equally viable design alternatives. When there are two possible solutions, favor the one that is simpler and based on concrete need rather than the more intricate one that boasts of generality. Of course, it is entirely possible (and quite likely) that the simpler solution will turn out to be the more general one. And if it doesn't, it will be easier to change the simpler solution to what you need than to change the general one that turns out not to be quite general enough in the right way.

Many things that are designed to be general purpose often end up satisfying no purpose. Software components should, first and foremost, be designed for use, and to fulfill that use well. Designing for all seasons is both difficult and not always desirable, a realization that helps explain the small markets for thermal bikinis and Ford Edsels, as well as the challenge of designing general-purpose software components.

Generality should equate to simplicity and simplification. Generalization can be used as a cognitive tool, allowing us to reduce a problem to something more essential, resulting in an approach that embodies a regularity across known examples, a regularity that is crisp, concise, and well grounded. However, too often generalization becomes a work item in itself, and pulls in the opposite direction, adding to the complexity rather than reducing it. The initial sweetness of a general solution can become overwhelming as it grows, to the point that we feel like we are drowning in syrup. The pursuit of speculative generality often leads to solutions that are not anchored in the reality of actual development, making assumptions that later turn out to be wrong, offering choices that later turn out not to be useful, and adding baggage that becomes difficult or impossible to remove, thereby adding to the accidental complexity developers and future architects must face.

Design is compromise, and all flexibility is a double-edged sword. Many people mistakenly see design decisions made in the name of flexibility as win-only situations, a narrowness that belies reality. If we equate flexibility with degrees of freedom, then the degrees of freedom in a design should be reasonable and reasoned. Although many in software development value generality, people do not on the whole pay for (or need) it: they tend to have a specific situation, and it is the solution for that which gives them value. We can find generality and flexibility in trying to deliver specific solutions, but if we weigh anchor and forget the specifics too soon, we end up adrift in a sea of nebulous possibilities, a world of tricksy configuration options and parameter lists, long-winded interfaces, and not-quite right abstractions. In pursuit of arbitrary flexibility you can often lose valuable properties, accidental or intended, of alternative designs.

By [[Kevlin Henney]]

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