Guiding Principles

Where the mission statement attempts to capture what we've set out to do these guiding principles provide the motivation behind how things get done.

Computers should make life easier, not harder

The value of a computer system (hardware + software) should not be judged solely by how thoroughly it solves a problem. Often, a minimal subset of features is sufficient. Instead, it should be judged by the overall impact it has on the users quality of life. A system that is powerful, but difficult to use, is likely to have less utility than a less powerful system with an "intuitive" interface. At the extreme, a system may even have negative value due to poor interface, lack of features, or both - such a system should never have been implemented in the first place, and replacing it will likely result in long-term cost savings.

When in doubt, stay flexible

The antithesis of this principle is "get it right upfront". Software development by its very nature tends to involve a lot of guesswork. All too often projects get backed into a corner due to an assumption made early on that gets invalidated mid-way into the project, or perhaps, invalidated by an enhancement request in the next release. A deeply ingrained assumption often gets hardcoded (because its easier that way) resulting in significant rework. A careful design, with an appropriate amount of "softcoding" (also known as "what if") is the best defense here.

Software evolves as much as it is planned

Not to downplay the value of upfront design (which is especially appropriate for complex projects), we firmly believe that software evolves. Often many aspects of the design do not become apparent until implementation begins. This "design by discovery" is to be expected with any non-trivial project, as many details stay hidden until the appropriate level of granularity is reached. If the design has managed to stay flexible, these discoveries need not become setbacks.

Make it so simple it cannot possibly go wrong

This is the Japanese concept of poka-yoke (mistake-proofing). It differs from "idiot-proofing", since, after all, most people are not idiots. All else equal, a simple and elegant solution is better than a complex one. This principle has been stated other ways, by other people, perhaps the two most well known are "Keep It Simple, Stupid" (aka the KISS principle) and "Do the simplest thing that could possibly work" (from the agile methods camp). But whereas KISS implies something that has already become tangled and needs to simplified, and the agile mantra hints at a dangerous lack of functionality, poka-yoke is neither than these. It aims towards simplicity, but with a recognition that what is simple for the end user may, in fact, be quite complex for the programmer to implement.