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.
This work is licensed under a Creative Commons Attribution 3
Back to 97 Things Every Software Architect Should Know home page