A computer program is a tool, rather like a screwdriver or a soldering iron. Just like that screwdriver or soldering iron, there are some jobs that just can't be done without it. But one must never let the tool become an end unto itself. Tools are defined by their intended application, not vice-versa. With this philosophy in mind, Microcomm programmers will apply the following design rules when developing custom software to solve your engineering problems:
find out what problem the software is intended to solve
interview the end user to determine his or her working style
determine what previous software solutions have succeeded, and failed
fit the software to the application, not the other way around
identify the intended operating environment
ensure cross-platform interoperability to the extent possible
start with the flowchart, and end with the code
respect the client's language and OS preferences
thoroughly document every variable, subroutine, and function
prompt for input with something more meaningful than a "?" or an "enter data"
remember that cheap memory is no justification for bloatware
build expansion, enhancement, and modification into the initial design
know that somebody else is going to have to maintain the code
maintain an archive of every version and revision ever used
streamline code to minimize run-time
value the customer's time, fingers, eyesight, and pocketbook
solicit and act upon user feedback
know when it's time to abandon a line of thought and just start over
never forget that it's the software that serves the user, not vice-versa
consider that when your only tool is a screwdriver, every problem can look like ... a can of paint!