In my career, I have worked for two firms representing opposite ends of the software development spectrum. It wasn’t until I changed jobs that I came to realize the far reaching effects of the development methodology used by each of them.

I joined the first company, a multi billion dollar international consulting group, right out of college. The software development methodology we used at this company was the typical bureaucratic method. Okay, I realize that isn’t an official name for a methodology, but it probably should be. We produced vast amounts of documentation. We attended regularly scheduled, automatically repeating and seemingly unending meetings. We employed armies of testers, managers, and architects. We also had a few programmers. This method was so extensive that we frequently had training sessions on it complete with marketing logos and taglines just so we would know what we were supposed to be doing. In my eighth year of working there, I was still in training on the method.

As a consequence, the development life cycle could take up to two years with only a small percentage of that time actually dedicated to coding and building the product. And the business was left with no delivery until the very end of the project. While I agree that a standardized process and a good design are key to developing a successful end product, it seemed the most reliable outcome of this particular method was the consulting fees billed to the customer as a result of the process overhead involved. The goal of defect elimination by focusing on planning, analysis and design never seemed to materialize.

When I joined Doozer, I was in for a quite a change. Doozer didn't give me an official name for the software methodology they use, but that’s mainly because they don't proclaim the use of a specific or even a single method. This doesn't mean Doozer is a haven for a bunch of cowboy coders. Everyone knows a complete absence of process is not a good thing.

Many aspects of what we do here at Doozer are accurately described by the Agile software development methodology. The Agile method promotes an iterative approach to development that focuses on delivering components of working functionality to the customer as often as possible. This is paired with a constant flow of feedback and input from the customer. Though one of our current projects will be in active development for more than a year, we have delivered formal releases to the customer throughout the entire course of the project. The timeframe between releases does vary from every few months to as often as every few weeks depending on the complexity and importance of the changes. As a result, we have adjusted quickly to customer input on general functionality, tools and reports.

This wouldn’t be possible if we coded for a year and then delivered the “whole” application. We’ve found it is much easier to be adaptive rather than predictive. Our approach has generated little, if any, unused code or wasted functionality. This methodology does tend to make everything in the development process fluid. Requirements can change a great deal using this approach. This can be disconcerting for some developers. I’ll have to admit, it did take a little adjustment on my part to get comfortable with the sense of changing direction using this type of development. In the end though, I have been able to see the overwhelming benefits. The customer is able to visualize the application in context so much better with interim deliveries. And they end up very satisfied because they get the software that they wanted.

The Doozer process, like the Agile methodology, focuses on people: strong teams of strong programmers. In addition, Doozer has a unique service offering called Project HQ. This is a development model that uses a project team consisting of our programmers working alongside our client’s in-house programmers in the development effort. Once again, this provides an instant feedback mechanism. It also makes maintenance transition a very natural extension of the project. The client’s programmers are trained and ready to support the custom application. Some developers might bristle at the idea of such direct customer involvement, but my experience has shown me how very productive this approach can be.

From the top down, Doozer believes that the process should never impede development. This seems like an obvious goal that any software house should strive for, but it isn't always the case. Having experienced two very different philosophies of software development, I can say I am much more in favor of the Doozer way of building. This is mainly because I feel more productive since I write more lines of code that will be called on regularly than lines in documents that will gather dust on a shelf.

I enjoy working with a strong team of coders who focus on building what the customer wants and giving it to them as quickly as possible.