Through our many years of experience building software, we've accumulated methodologies and principles that lead to quality software.
Listed below are our methodologies.
Applications are graphs of components, each with dependencies and inputs and outputs. DI and IOC are a simple and powerful way of building testable, flexible and easily replaced components.
A large part of writing good, clean code is to restrict your options. Avoid nullable data. Avoid mutable data. Avoid state. Code is not a poem: it's actually preferable if it all looks the same and seems "easy" and "obvious".
Use tests to execute your code. Automate them to guard against future changes. Make testing easy for developers by building nice integration suites. Tests are code.
Finished code is reviewed before it is committed. Reviews make sure that the other parts of the design process were followed (documentation, tests, etc.) and that errors are fixed as quickly as possible.
Software without documentation is not maintainable. Good naming conventions, logical designs and well-built tests help make code self-documenting. High-level tutorials explain how the different components are intended to work together.
Low-overhead releases lead to faster turnaround and higher quality. Automated (or nightly) builds pinpoint software errors before they can become problems.
Components encapsulate specifications. Software is designed to balance reuse and abstraction against the project goals, all the while optimizing maintainability.
The specifications are built right into the code. Software publishes its assumptions instead of leaving its contract implicit.
Tests are a central part of building software. All component features have application-independent tests which can be run automatically and throughout development.