| |
Keep it Simple
The best design is the simplest and most straightforward that will do the job. Depending on the problem, that
may not be simple in the abstract. Simple is easier to code, easier to maintain, and easier to
document.
|
Make it foolproof
If you can with reasonable cost prevent your users from making a mistake and you
don't then when they make that mistake it is your fault and not theirs. For example, if there
are a limited number of choices, don't make the user enter a value in a text field. Use a pull
down field or a auto-complete box or some other method of ensuring the data is entered correctly.
Obviously, not all systems can be foolproof, but a little design can save a lot of heartache.
|
Don't just add features
Programmers tend to add features they think their customers will eventually want. Substituting
your vision for theirs is a vanity. If you are wrong, you spent time and money for which your
customer did not recieve benefit. If you really believe they will want it, then convince them
now that they want the feature. Try to structure your code so changes will not cause a redesign,
but don't add unwanted features.
|
Instrument your code
Think of performance in general, but don't code elaborate algorithms to gain performance until
and unless you know the simplier code would not perform adequately. The best way to do that is
to provide logging and statistics in your programs. Then you can report actual performance data
and correct it when necessary. This also helps the production support crews to get early notice
of upcoming problems.
|
Provide audit trails
Logging provides statistics on how well we do something. Audit trails tell us what we did and
who did it. Programmers often think this is just overhead, but it is very useful in finding
problems. An audit trail may tell you that when the 700 other users do Action A, it always works,
but when Bob does it, it always fails. So it is a problem with Bob or his environment and not
a generic problem with the code. Audit trails may allow you to "replay" the code either to
debug a problem or to help in disaster recovery.
|
And much more
It would be impossible to list the hundreds and maybe thousands of lessons we have learned in
our years of designing programs. Many only apply to special circumstances, but are very important
when they apply. Many are obvious once they are stated, but are frequently violated. Our staff
has been consulting for decades. This gives us both depth and breadth in many industries and
many types of clients. We have seen what works and what does not and can help you choose the best
options to save you time and money.
|