PTTP Systems

Eric's Software Architecture and Design Philosophy

Sustainable engineering and lowered cost of change should be a priority for any engineering group. The list below enumerates properties embodied by software that promotes those goals. Good software architecture and design arises from balanced combination of these properties. Of course, not all of these goals can be simultaneously optimized, so remember that the proper balance is derived from issues specific to the development of your software.

When in doubt, remember the first three: simple, secure, and robust.

• Simple

  Simple architectures and interfaces are easier to debug, change, and maintain and will promote the properties of security and robustness.

• Secure

  Security should be a primary objective for any software product. Think like a hacker. Prevent and defend against malicious and incorrect inputs.

• Robust

  Well designed software is not fragile. Small changes to behavior in one area of the product should not propagate errors to far reaching corners of the software in unanticipated or hard-to-diagnose ways.

• Modular

  Modularity is one requirement for software reusability. Software reuse produces a smaller code base that is easier to debug, change, and maintain.

• Decoupled

  Modularity is not sufficient to reduce complexity. Reduction of complexity also requires a decoupling of function. Examples of coupled operation include a module that operates using the threads of other modules, and a module that must maintain internal state for use by other modules.

• Explicit

  Implicit behaviors, configuration, and operation are very difficult to maintain and extend even when well documented. Although using implicit rules or configuration may be convenient when first envisioned, the increased cost of change militates against such practice.

• Consistent

  Programming interfaces that are named in a like fashion should behave in a like fashion. The simplest implementation of this property is software re-use.

• Extensible

  Software that is hard to extend has a high cost of change and causes creation of more software than necessary. How hard is it for someone else to correctly add a new method to your class?

• Transparent

  Transparency is a prerequisite for ease of debugging and maintenance. If we can’t look inside the software then the cost of solving problems and monitoring operation goes up significantly. Instrument your software and use standardized logs.

• Maintainable

  Software should be designed and written assuming that someone else will have to maintain it and that those individuals will not have the same training and/or background as the original designer/implementer.

• Measurable

  Without metrics on the operation of your software it will be difficult or impossible to understand when performance enhancements are taking affect, or which performance enhancements to implement. Instrument your software, measure the behavior, and then ponder performance.