Final Thoughts

I have been heartened by the emergence of what can be loosely called the Agile approach. In the area of design and coding practice, the general proposals address some of the issues I have written about here. You can find out more about Agile development here.

However, as with earlier methodologies, such as various "waterfall" approaches, it must be considered in light of the nature of the product, business model and team environment. Agile represents not just a reaction against cumbersome and poorly implemented methodologies manifesting the sort of problems I have eluded to in the previous discussion. It addresses the tremendous changes in the technology landscape and the speed of business these days, often characterized by short time to market and legitimate needs to modify requirements throughout the development cycle.   

But there is something underlying all of these discussions of techniques, best practices, and so on which is rarely touched on. It derives from one essential fact: software development is properly viewed as a craft, rather than a science. Let me stress that I am talking about the day to day activities of most developers, not the leading edge work by experts charting the course of emerging technologies, which can be properly described as computer science or software engineering research.

Traditional engineering disciplines, where the end products are physical objects whose fabrication and operation rely on fundamental physical principles, evolved standards and procedures for accurately and unambiguously recording essential information. No one starts building a bridge without final blueprints.

Software is fundamentally different. Program architecture does not spring from invariant underlying laws, but the expression of concepts in forms which are as varied as language itself.