How we write software

Our principal aim is to reduce risk as much as possible. You should not be unpleasantly surprised at any time during development; necessary but important changes should have as little impact as practicable. To that end, we employ many software-industry best practices, including evolutionary delivery, automated testing, appropriate "build-or-buy" (or "get for free") decision-making, and intelligent documenting.

For starters

All of our solutions are based on the Inner Drive Extensible Architecture™—the Idea™, a complete software foundation representing two years of development and testing. The Idea handles all the plumbing of the application, like email, error handling, internationalization, and user preferences.

Evolutionary delivery

We don't lock ourselves in a room for six months and throw something over the wall to you. We use an industry best practice called evolutionary delivery, in which software is released in small steps with user requirements being continually re-assessed at each milestone.

We will develop your software in short, visible stages, one sub-feature at a time. This method ensures that you always have control over the project, because you can always see it moving forward. Once the core architecture is designed, but even before it's fully implemented, we will have a build for you. After that, you can expect a new release every four weeks. The software will do very little initially—say, just taking a single transaction from the UI to the database—but it will work correctly, and be fully documented. If a build you receive contains an error, it can be quickly fixed for the next release.

During the design and build process, the software stays in a constant near-release state, which gives you flexibility and control over the timetable. After we release each build, we'll have a short meeting to decide what will be next. We'll give you continuous, clear guidance about the project's risks and schedule. The release schedule is designed to be amended mid-stream, if your needs change or if you decide to raise or lower a feature's priority. More commonly, you can decide to extend or contract a particular feature and know right away how this will affect the software. And because the release increments are small, we can quickly and accurately estimate the costs or savings of schedule changes.

Comprehensive testing

Evolutionary delivery is possible only through the disciplined, conscientious approach that we've learned from 15 years of delivering software in high-pressure environments. Each piece, or unit, of the application has a series of unit tests associated with it, which we run after every change to the software. It sounds tedious, but it's automated. Because of this automation, and because thorough unit testing uncovers errors immediately (so we can fix them immediately instead of hunting for them later), it actually takes a lot less time to develop software with full testing than without it, and reduces the risk of costly errors slipping in.

We also believe in frequent, low-cost usability testing. This doesn't mean spending thousands on a usability lab with hundreds of testers. Instead, we take the approach advocated by usability experts like Jakob Nielsen: periodic, 1-hour tests with a handful of testers each. This helps ensure that the software actually increases your productivity, and thus the return on your investment.

Appropriate "build or buy" decision-making

Where possible, we'll use free, low-cost, built-in, or off-the-shelf software. For example, an in-house application running on a local network may not need its own database of users and roles. Instead, it can use built-in security information. Since the network knows who you are and what role you're in, the application can simply ask the network for this information. The application immediately uses any change you make to the network user list.

Intelligent documenting

We don't wait until the end of the project to document what we've done. Instead, we follow the industry best practice of documenting as we go. Usually we write the documentation before writing the code, and we always update the documentation and code simultaneously.

This means that the code is easily maintained and, should it be required, easily transferred to another developer or team. It means that the documentation reflects how the application really works, all the time. And, it means we take less time to deliver the same product, for the same reason that a good outline makes writing a book easier.

For an example, see how we documented our own framework by checking out the IDEA™ Software Developer Kit (SDK).

Return home.

Copyright ©2014 Inner Drive Technology. Purveyors of fine, hand-crafted computer software. Legal information. Page printed 2014-12-20T15:01:33 UTC.