Software Philosophy

• Correct - Correctness is the key aspect of any software system. If a system doesn't do what it's supposed to, then what's the point?
• Simple - I adhere to the "Keep It Simple Stupid" (KISS) principle. Simple generally means small, so I strive to write small classes (generally under 100 lines) and small methods (generally under five lines). Doing so allows my classes and methods to adhere to the Single Responsibility Principle. I like to submit early and often, so that each submission is simple and easy for reviewers to understand. I believe in not writing code until it's actually needed, also known as the You Ain't Gonna Need It (YAGNI) principle. I agree with Donald Knuth's take on premature optimization - it is the root of all evil! I also love Tony Hoare's quote on simplicity - "There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult."
• Well-named - Naming is so important in software. A little extra time spent upfront deciding on a good name pays dividends in the short-term and years down the road.
• Free from duplication - I adhere to the Don't Repeat Yourself (DRY) principle. Relentlessly seek duplication in your software and work to remove it.
• Automatically tested - Write automated unit tests as you write your production classes. Treat the automated tests as a first-class user of the production classes, let them reveal code smells, and address those smells! Write automated functional tests early and build up a suite that takes the drudgery out of manual testing.
• Consistent - Each team should have a set of conventions and use an automated tool (such as Sonar) to ensure the conventions are adhered to. It's more important to remain consistent than to fight over the actual conventions used.
• Documented - Every public package, class, and method should be documented. Every parameter and possible return value should be explained. Note that I agree with Robert Martin in that comments are a failure. As a developer, I strive to express myself in code so that I don't have to rely on comments to communicate my intent.
• Reviewed - Software should be reviewed early and often and code authours should be open to any feedback from reviews.  Modern online code review tools (such asAtlassian Crucible) allow for painless reviews.