Rules of the Road

When I sat down to write this article, I had the idea of trying to formulate philosophical perspectives and quantify them with clearly defined boundaries and examples of scenarios where each would apply. After about six or seven revisions, I gave up on the approach as the content was turning into voluminous, overlapping rants on ideas that were to be presented in respective isolation. Ultimately, I had been authoring the defeat of my own rules through inadvertent pleonasm, attempting to sound "more experienced" or "more professional". The reality of the subject is these rules are intended to be guidelines, not absolutes.

With this in mind, here are the rules in no particular order:

Keep it simple and stupid

Going from the joke, "don't use a big word when a diminutive word will do", is solutions should not be exaggerated expressions of mechanics and technical savvy. Keeping your approach grounded and as free of assumptions as possible will yield better results, both mechanically and aligning with business needs.

You cannot build what you do not understand

Here is a simple premise: I can hold no expectations of you if I were to give you a hammer to build a house when you understand neither what is a "house" nor the purpose of a "hammer". Success in projects relies on good communication, clear documentation, and solid efforts in reducing ambiguity.

1,000 to do a thing; 10 are valid, 5 are good

This speaks on the idea of a solution being sound in a mechanical sense but not necessarily aligning with the ideal, or even viable, needs of the problem domain or product owners. A valid solution is one that satisfies the problem domain without specific regard to solution lifespan or business behavior. Good solutions take into account mechanics and behavior, satisfying concerns of lifespan and cost of ownership. Development cycles should work in an approach to initially achieve validity while iterating toward good or ideal.

Perfect is the enemy of good

Perfection, in any state, is impossible for IT solutions. Attempting to develop or deliver perfection is a waste of time. Developers should strive at all times to deliver their best result with whatever resources they may have available. This comes with the understanding that not all avenues can be traversed, not all flaws can be resolved, not every behavioral facet is visible. Most solutions are interval sojourns for managing data which outlives the state of the solution.

While this list isn't exhaustive, these are the basic concepts I feel can be addressed in a single article. As always, I encourage discussion between team members and teams to better understand how best to achieve these goals. I encourage you to write down your own rules, and the same for teams, as a reminder of striving to do the best you can with what you have available.