Contribution 55 - Revision history

Balesd: Removing all content from page

Balesd — Mon, 14 Jul 2008 22:18:04 GMT

Removing all content from page

←Older revision		Revision as of 22:18, 14 July 2008
Line 1:		Line 1:
-	==It is better to be consistently wrong than it is to be inconsistent==

-	Doing things consistently, whether it is analysis, architecture, design, or coding, is critically important. Then, when you discover that you've made a mistake, you immediately know where to fix it. And we all make mistakes.
-
-	From a persistence perspective, if you start out consistently using a set of coding conventions for a database, for column names and widths, table names, etc., and it turns out one of your conventions was poorly conceived and needs to be changed, you can query the database’s data dictionary to identify what needs to be refactored, rather than examine every table and column individually.
-
-	From an application perspective, if you start out consistently using a set of coding conventions for your business rules, persistence mechanism, etc., and it turns out you need to change to a better implementation, you can query the file system to identify what needs to be refactored, rather than examine every class individually.
-
-	From a presentation perspective, if you start out consistently using a set of coding conventions for your forms, their layout, field size, and usage metaphors, and it turns out you need to change to a different look-and-feel, you can once again query the file system to identify what needs to be refactored, rather than examine every form individually.
-
-	The use of object-orientation to begin with greatly reduces inconsistency, that is, if the classes you create are documented so they are reused. I also like to employ the rule: “If you have to code it more than once it should be abstracted out into a class and method, or at least another method.” Consistency reduces errors and improves maintainability. And all software must change as the business it supports changes.
-
-	As an architect, if you consistently apply design metaphors you will create truly functionally software, and, if you consistently apply beautiful design metaphors you will create livable workplaces.
-
-	By [[Donald J. Bales]]
-
-	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

Rmonson at 07:13, 6 July 2008

Rmonson — Sun, 06 Jul 2008 07:13:27 GMT

←Older revision		Revision as of 07:13, 6 July 2008
Line 1:		Line 1:
		+	==It is better to be consistently wrong than it is to be inconsistent==
		+
	Doing things consistently, whether it is analysis, architecture, design, or coding, is critically important. Then, when you discover that you've made a mistake, you immediately know where to fix it. And we all make mistakes.		Doing things consistently, whether it is analysis, architecture, design, or coding, is critically important. Then, when you discover that you've made a mistake, you immediately know where to fix it. And we all make mistakes.

Balesd at 00:48, 6 July 2008

Balesd — Sun, 06 Jul 2008 00:48:37 GMT

←Older revision		Revision as of 00:48, 6 July 2008
Line 1:		Line 1:
-	Doing things consistently, whether it be analysis, architecture, design, or coding, is critically important. Then, when you discover that you've made a mistake, you immediately know where to fix it. And we all make mistakes.	+	Doing things consistently, whether it is analysis, architecture, design, or coding, is critically important. Then, when you discover that you've made a mistake, you immediately know where to fix it. And we all make mistakes.
		+
		+	From a persistence perspective, if you start out consistently using a set of coding conventions for a database, for column names and widths, table names, etc., and it turns out one of your conventions was poorly conceived and needs to be changed, you can query the database’s data dictionary to identify what needs to be refactored, rather than examine every table and column individually.
		+
		+	From an application perspective, if you start out consistently using a set of coding conventions for your business rules, persistence mechanism, etc., and it turns out you need to change to a better implementation, you can query the file system to identify what needs to be refactored, rather than examine every class individually.
		+
		+	From a presentation perspective, if you start out consistently using a set of coding conventions for your forms, their layout, field size, and usage metaphors, and it turns out you need to change to a different look-and-feel, you can once again query the file system to identify what needs to be refactored, rather than examine every form individually.
		+
		+	The use of object-orientation to begin with greatly reduces inconsistency, that is, if the classes you create are documented so they are reused. I also like to employ the rule: “If you have to code it more than once it should be abstracted out into a class and method, or at least another method.” Consistency reduces errors and improves maintainability. And all software must change as the business it supports changes.
		+
		+	As an architect, if you consistently apply design metaphors you will create truly functionally software, and, if you consistently apply beautiful design metaphors you will create livable workplaces.

	By [[Donald J. Bales]]		By [[Donald J. Bales]]

Balesd at 15:54, 19 June 2008

Balesd — Thu, 19 Jun 2008 15:54:29 GMT

←Older revision		Revision as of 15:54, 19 June 2008
Line 1:		Line 1:
	Doing things consistently, whether it be analysis, architecture, design, or coding, is critically important. Then, when you discover that you've made a mistake, you immediately know where to fix it. And we all make mistakes.		Doing things consistently, whether it be analysis, architecture, design, or coding, is critically important. Then, when you discover that you've made a mistake, you immediately know where to fix it. And we all make mistakes.
		+
		+	By [[Donald J. Bales]]
		+
		+	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

Balesd at 15:53, 19 June 2008

Balesd — Thu, 19 Jun 2008 15:53:12 GMT

←Older revision		Revision as of 15:53, 19 June 2008
Line 1:		Line 1:
-	Do things consistently, whether it be analysis, architecture, design, or coding, is critically important. Then, when you discover that you've made a mistake, you immediately know where to fix it. And we all make mistakes.	+	Doing things consistently, whether it be analysis, architecture, design, or coding, is critically important. Then, when you discover that you've made a mistake, you immediately know where to fix it. And we all make mistakes.

Balesd: New page: Do things consistently, whether it be analysis, architecture, design, or coding, is critically important. Then, when you discover that you've made a mistake, you immediately know where to...

Balesd — Thu, 19 Jun 2008 15:52:46 GMT

New page: Do things consistently, whether it be analysis, architecture, design, or coding, is critically important. Then, when you discover that you've made a mistake, you immediately know where to...

New page

Do things consistently, whether it be analysis, architecture, design, or coding, is critically important. Then, when you discover that you've made a mistake, you immediately know where to fix it. And we all make mistakes.