My approach to coding and development is to create simple, obvious solutions that are easy to maintain in the long run. I develop and maintain many different projects across different platforms for long periods of time. If the code isn’t obvious and easily readable it makes the maintenance very difficult. If someone has a command of the programming language they should be able to easily understand the logic and flow of the code; I use simple constructs and descriptive variable names. I tend to only put comments in the code to explain why I did something and not how (unless I needed some complicated logic or construct).

Another habit that has served me well is to write explanations of the customer’s workflow (business logic) and how it ties into the data model; and if there is anything tricky that happens behind the scenes that isn’t immediately obvious. These write-ups typically consist a narrative describing how the data is populated, how it’s related and how to extract it along with any diagrams that might be helpful. It doesn’t take a lot to make a big difference when looking back on code and data models created years in the past.

I prefer to create a simple solution first but have no problem going back and refactoring code or SQL to improve performance. The simplistic version helps you solidify logic and functionality which will ultimately help you create a higher performance version. My first priority is maintainability but performance is a close second. The simple solutions are usually fast but it’s never been a problem to go back and optimize code and the data model to achieve the performance necessary on the few occasions where a higher level of performance was needed.

Bottom line: Simple, clean solutions are easier to develop and maintain; this is true for code, data models and extracting data.