Home‎ > ‎

Choosing Mechanisms

  1. When in doubt, make it a Console application
    If you've reached the stage where you've identified a need, but not a user interface, create a "Console App" project that reads and writes to stdin & stdout. These are easier to use as components in systems and user interfaces once the requirements for those have finally materialized, too

  2. Don't create a Windows Service when a Scheduled Task will do
    Windows Services are not meant to invoke periodic tasks with a timer

  3. REST for the deterministic, SOAP for the spontaneous
    REST is a superior interface for databases, but commands and actions--such as turning on a pump or announcing the arrival of a delivery truck--are spontaneous in nature and better handled with SOAP

  4. Use a Queue for all inputs to a system
    The inputs to a program aren't the same as the inputs to the system. A mouse click is an input to a program, but a purchase order is an input to a system. Funnel all system inputs through a Queue and keep a high-fidelity archive of everything that goes to the Queue. Build tools that can re-submit the archive to any Queue as if it was original input

  5. Invent your own config-file formats to cover broad concepts, then write tools to convert them into specific manifestations
    For example, instead of hand-making configuration files for your FTP tool, your scheduler, and your import tool to handle purchase orders from a business partner, create an XML file with your own syntax to describe all of the parameters for anything relevant to that partner, then write tools that convert these files into FTP scripts, cron jobs, import mappings and so-on

  6. Vendor First, Third-Party Second, Homebrew as a last resort
    This is the principle of getting someone else to do the most work and someone else to pay for it (especially debugging). If your platform's vendor doesn't provide the tool or abstraction you need, then look for a third-party solution. Resort to homebrew only when a) there's no other option, and b) you actually need whatever it is

  7. Don't anticipate the vendor
    Similar to the above, if you know the vendor is going to add a feature to your platform then wait for it rather than making homebrew versions to get it early. Platform upgrades will make stepchildren out of your homebrew language extensions and force you to either re-write working code, or waste time training your new hires to deal with the technical debt

  8. Horses are usually better than zebras
    The naive Bayes algorithm produces better results in less time than proprietary AI algorithms in almost every situation. You probably don't need an exotic algorithm, data structure or patented process to make your program better than the competition