On Using Programming To Discover A Good System
Why not just keep changing the program code until a good system has been discovered? This search for a good system by trying possibilities in programming has lamentable performance characteristics. The various methodologies are essentially concerned with improving the performance of the search for a good system even if they don’t state it in those terms. The generation of a new possibility regardless of quality level might be termed an iteration.
Every modern methodology uses iteration where the number of iterations is not pre-determined. However, each iteration has some cost. It is reasonable to attempt to minimize the number of iterations and to reduce the cost of iterations.
The cost of iterations where each new design possibility is expressed in program code is very high. A skilled designer may conceive of and evaluate thousands of possible solutions in a day. A single iteration in programming may take days, weeks or months. Secondly, the part of the search space explored in the next iteration by designers who need to iterate in programming has significantly smaller probability of payoff than the possibility selected by a designer who can think it through. There are three negative properties of iterating in code:
A skilled designer can think iterations through, briefly noting ideas resulting in possibilities of improved quality. Only on selecting the proposed final possibility is the write-up started. The write-up may be refined perhaps four times for the design of a complex project, and successive refinements are issued more widely. A programming prototype may optionally be undertaken after this to confirm the quality of the design.
The conceptual world in which the non-design development work for the project is done is quite well explored before programming begins. There is no search in iterations of programming for good conceptual foundations of the application. It needs to be said that the ability of the designer to think things through is paramount. By no means everyone who attempts design with a feeling of confidence has the skills for it. The skill of the designer is at a premium, and should you fail to attract a designer of sufficient skill, you will find yourself iterating through concepts in programming. This outcome is incompatible with project control.
The duration of education into the design is likely to be two weeks. Non-design developers are encouraged to write up their own understanding of the design, which serves two purposes:
· Examination of their comprehension of the design;
· Creation of tutorials in a variety of styles.
It is most cost effective for the designer to sketch diagrams on a white board and for people with a lower hourly rate to take the time to draw nice diagrams. Web content developers are just fine at this. A diagram records some aspect of a design and the production of a diagram should not be mistaken for the process of design.
Design in application development goes by a variety of names, some more widely understood than others. The term “Application Architecture” or just “Architecture” is often taken as if meaning Technical Architecture in which hardware and supplied software are selected, installed and configured. The terms “Domain Analysis and Modeling” and “Domain Object Modeling” are useful in avoiding this misunderstanding.
An expert in the domain being modeled is not placed to model that domain. During Domain Analysis and Modeling the brain of such an expert will be comprehensively picked for the facts of the matter, but this domain expert will be no expert with abstracting or modeling domains. There is much more to modeling a domain than immediate categorization abstractions such as “a car is a vehicle”, and great advantage in doing more than these categorizations.
Products that provide transparent object persistence can be expected to reduce your project cost by 20%. There is that much less to design, program and manage. A Domain Object Model can be expressed directly without in-house non-functional persistence infrastructure. The conservative figure of 20% reduction in development cost is quite compelling in these times of increasing competition. However, transparent object persistence in no way reduces the need for domain object modeling.
design@cognitivemachines.com
(your browser may not be configured to handle mailto: links correctly. If so,
just copy and paste the email address into your usual email program).