TRUST

We recruit carefully; a seat at ITVORX table is a valuable thing, and our recruiting process is built around making sure that we reserve job offers to programmers who will hit the ground running and produce great work. Numerous studies have shown that the difference in productivity between an excellent programmer and an average one can be a factor of 10:1.

Our development practices must be built on the assumption that we have a group of programmers occupying the high end of the scale, and wherever possible, we err on the side of trusting our people to take the right actions for the client, the project, and ITVORX.

VERIFICATION

As Reagan said, though -- “Trust, but verify.” The main components of this verification are:

• Management review. Projects must be managed in a way that provides easy, regular visibility into the state of the project, in terms of outstanding tasks, remaining budget, risks, etc. Standard project documentation is the most visible mechanism for management review.
• Peer review. We must regularly perform peer reviews of designs and code to ensure that all work remains at a consistently high level, and to provide a low-impact way to transfer new skills, techniques, and ideas across the company.
• Automatic review. All code should be designed for test -- a standard unit testing framework simplifies the process of writing code that verifies its own correctness. Not only does this allow us to be confident in the robustness and correctness of our code, but it also allows us to evolve our designs as the needs of the client change over time without introducing subtle refactoring or regression errors.
• QA. Before clients are allowed to see the code we’ve developed, a set of eyes outside the development team should thoroughly exercise the project, and send it back to the developers when needed.

FLEXIBILITY

Key to our practices is a recognition that our projects and the clients who own them occupy a wide range of complexity and sophistication. Beyond a core set of practices (coding style, source management, bug tracking, consistent release procedures), the level of methodological “heaviness” must be tailored to the specifics of each project and client. When beginning a project, we must consciously decide whether it’s more appropriate to perform a big design up front and commit to it before writing a line of code, or to use an iterative, evolutionary design approach. A poor match could mean a failed project.

JUST-SUFFICIENCY

The principle driving our flexibility needs to be a quest for “just-sufficiency” -- the practices are at the service of completing a project successfully, not just to follow blindly. When selecting individual practices to follow on a project, each must be chosen with an eye to the appropriate level of rigor that will produce a successful project, and also aid the success of future iterations of the project. A project that expends too much effort documenting its design and code will not be able to finish on time. A project that expends too little effort on this documentation threatens the success of maintenance programmers in the future who will need to waste time reverse engineering the project just to understand it.

Wherever possible, we prefer to use approaches and tools that are as simple and as lighweight as is appropriate.

“Discipline is never an end in itself, only a means to an end.”

-- Robert Fripp

KAIZEN

“KAIZEN means improvement. When applied to the workplace KAIZEN means continuing improvement involving everyone - managers and workers alike.”

-- Masaaki Imai

Our approach to software development must not be allowed to ossify. Beyond the basic philosophy of ITVORX, we must count on all our developers to continue to look for ways that we can continually improve our practices and our work, both in detail and in broad strokes. New ideas that are consistent with the ITVORX way will be tested on pilot projects, evaluated, refined, and if successful, adopted company-wide.