Andy’s Scribbles

Agile methods have proven time and again to produce better software quicker. Extreme programming, iterative development, and release early release often provide the designers and developers with more and better feedback from customers.

I recently helped develop a custom software package, and I learned very quickly into the project that knowing upfront what the product needed to do was near impossible. Incrementally adding functions as they we discovered they were needed turned out to be fairly quick and easy, since we kept the architecture simple adding only what we knew was necessary, and removing what we found to not work, or not be necessary.

Not only are these approaches better for the end result, but they are certainly more motivating for the developers themselves. At each stage of the process there is a prototype that compiles and runs, whether or not all the functionality is there. This helps avoid propagating early mistakes. Also, they can focus on one aspect of the product at a time, and receive verification from testing, and validation from the customer. In my limited experience the program ends up more efficient and maintainable in this process.

In the now dead waterfall approach to programming, where specifications are known upfront and the entire development is done together, and then all testing is done at the end, growing software one piece at a time deals with the fundamental issue that usually specs won’t be correct or complete at the beginning. The waterfall model also leaves testing for the end, so the code where bugs are found have long since left the developers memory. Finding bugs, usually the hardest part, is greatly simplified when only one module was added since the last successful prototype.

Though strictly speaking programs are deterministic and lifeless, I often see a personality (inadvertently instilled by the programmers) in software. When software is grown piece by piece rather than built from bottom to top, the software behaves better.