Time-boxed Iterations

We make the iteration release date sacred and then adjust our scope to deliver what we can within the iteration schedule – “Schedule is the most important aspect of the project”. Our development strategy then is to keep the quality constant and adjust the scope to meet the schedule. With every iteration, as the experience grows, productivity gains allow us to catch-up if the scope slips.

Incremental Releases

Timely initial releases with a steady stream of new features allow us to create a flywheel effect. This flywheel effect contributes to the momentum in the later releases. Feature prioritization is the key strategy here. High value and high-risk features are delivered first.

Test Driven Development

Basing tests on the code instead of documentation not just allows us to lower the cost of synchronizing the two, more importantly, it also prevents errors and omissions costs caused by out of date documentation. “Write tests first” strategy, bases the code on tests, guarantees testability and helps to ensure comprehensive test coverage. The automated testing scaffolding that we build ensures a low barrier to frequent testing. Upon system delivery, the test scaffolding is delivered with it, making future changes and extensions to it easier.

Nightly Builds

At Ishi, software development projects follow the discipline of unattended End-to-End (EtE) nightly builds. It is a process of taking a piece of software through the entire build/test/deploy cycle in a single step. This includes fetching the source, compiling it, packaging it, testing it, generating reports, sending (email) those reports to interested parties and finally, deploying the project. We use Ant and Maven for nightly builds for Java projects and NAnt for .NET projects.

Continuous Integration

Continuous integration is a step further to nightly builds. We integrate all newly checked-in code (at least) every few hours. To ensure this, we build an automated, continuous integration and test environment on a fast build machine running a daemon process. It periodically wakes up (such as every two minutes) and looks for newly checked-in code, which triggers the running of a rebuild and test script. We usually use CruiseControl for continuous integration for Java projects and CruiseControl.NET for .NET projects.

Documentation

Although we are experienced in using reverse engineering tools such as TogetherJ, we prefer to infuse Domain Model into the code itself using technologies such as JavaDoc. This allows us to lower the cost of maintaining Domain Models (Object, Process and Rules).