Team Oriented. Typical development approaches break down due to inter-module dependency. Developer A may be creating source code that depends on the functionality of a class being developed by Developer B. If developer B has not created the class correctly, or the class is still under development, the functionality that Developer A depends on suffers. Our approach of using dependency injection, where classes are handed the resources they depend on versus acquiring them directly reduces the need for complex and cumbersome plumbing code and allows for the use of Mock Objects for testing.
Using this modular approach allows each component to be developed, tested and verified in isolation and reduces the coupling between application layers. This is a state of Zen for the professional programmer -- developing to an application interface instead of an implementation. In doing so, the planned work may be better shared among a development team, dividing units of work into more atomic segments.
Results Oriented. Because of our quality driven design, source code assets don't exist until automated tests exist for them. When the components of systems are wired together, they have already been largely tested and verified in isolation, resulting in a less complex and smaller integration testing phase. Components developed using our approach allow our teams to:
- Develop true developer (unit) tests
- Isolate behaviors at the most granular level
- Develop components that are more reliable and suitable for reuse
- Develop faster implementations because of up front confidence of components
- Create elegant designs that are well abstracted and truly pluggable
- Refactor Fearlessly
Additionally, we measure the work produced quantitatively. Using a combination of Open Source analytics tools, we produce detailed reports of:
- Developer Unit and Integration Test results.
- Code coverage reports that show how much of your source code is being tested, and where deficiencies in testing may exist. These reports quickly allow your development team to visualize how much of the system is being covered by testing by looking at lines of code developed and logic branching to make sure you are achieving a minimum coverage level.
- Cyclomatic complexity reports (CC). Cyclomatic complexity is the most widely used method of static software quality metrics. CC may be considered a broad measure of soundness and confidence for a program. Introduced by Thomas McCabe in 1976, it measures the number of linearly-independent paths through a program module. This measure provides a single ordinal number that can be compared to the complexity of other programs. This analysis helps to identify complex hot-spots.
Proven Success. Our processes are based on years of experience on hundreds of projects and reflect the current thinking of modern software design. Our practices have been grown and field tested from the largest, most advanced research in the world, the National Institute of Child Health and Human Development at the NIH.
During our tenure at NIH, we developed bioinformatics applications used by researchers for gene discovery and gene prediction -- where quality of systems and information was paramount to the understanding of diseases.
