A typical custom application project is divided into two phases, plus of course delivery of the application, training, and ongoing support. The major parts of any job, however, are the following.

Analysis: figure out what the application needs to do

Development: build it

A typical ratio of effort between the two phases is 1 to 2. For every hour of analysis, it takes approximately 2 hours to actually write and test the code. Clearly it’s easier to plan something, than to actually do it.

However, at Reflexion we have an interesting situation. The focus of one principal, Paul Barkley, is on improving our ability to gather requirements and document them efficiently. So Paul’s job is to reduce that ratio by getting the requirements together as quickly and accurately as possible. By constantly shrinking the amount of time it takes to get requirements together, this phase can be as little as one fifth of the amount of time it takes to develop the system.

At the same time, the other principal, Pranav Desai, is constantly working to automate as much of the development process as possible, to reuse high quality code, and to generally improve our ability to actually develop systems from specifications. Pranav’s job is to try and turn that ratio around, so that for every hour that it takes to gather the requirements, it takes less than an hour to actually produce the code.

The result is a ratio that see-saws back and forth, as improvements in one area increase the ratio of the other area. What happens overall, however, is that these improvements continue to increase the quality of the systems while reducing the overall time to completion. The result is constant improvement in our processes, fostered by the internal division of responsibility and competition to improve the already high level of achievement in both facets of the development process.