Software Methodology Wars

Breaking the fallacy of one correct process

By Andrew Anguelo

Software workers can get quite passionate discussing methodology. Many cling to the conviction that one methodology is better than all others. I am here to break that fallacy. There’s a degree of ignorance in thinking that one method or process can solve the needs of all projects, or help all businesses achieve their strategic and tactical initiatives. The truth is that each project and each business objective may demand different methods.

Because there are fundamental differences between development and engineering, understanding the origins of the two approaches is important when discussing software building methodology. Engineering is a discipline that has evolved over thousands of years and is behind many modern advances and successes. Development, on the other hand, isn’t quite as nostalgic in origin and begs some consideration.

Strictly speaking, software development as it’s practiced in business today has been around for just over a decade. It grew out of the Internet races when companies wanted to be first out with an online presence or an innovative Web product. Planning, quality, and reliability didn’t matter much to corporate decision makers whose primary objectives were driven by capturing new markets at any cost.

Although we know now that most of those early efforts were smoke and mirrors and didn’t produce tangible results, some in the development community appreciated the lack of structure back then. Engineering differs from development in two critical ways. First, engineering is quantified and disciplined. Development is random and not based on standards or metrics. Second, engineering applies the science of computing, while development is reactionary and based on trial and error. With these facts in mind, it’s easy to understand why there’s been no headway in debates between engineering and development methodologies.

About development methodologies

Development is based on iterations of trial and error in the absence of knowledge and facts. It’s most often found in organizations that don’t value their software technology as a critical business asset and treat it as a necessary evil or a cost of doing business. Business executives in these types of organizations operate very much like those during the dot-com boom days. It’s no surprise that today’s more popular development methodologies are based on principles that shun documentation, engineering thought patterns, and encourage the use of loosely conceived ideas in production environments under the guise of flexibility.

Over time, developed systems grow into unmanageable, poorly performing code bases that often require major modifications or rewrites to satisfy business needs and objectives. These methodologies are designed to appease technology-ignorant business demands and have very little to do with creating professional software. There’s a place for development methodologies in certain organizations, but they most certainly shouldn’t be considered end-all approaches to building software.

About engineering methodologies

Engineering methodologies are much more methodical than development methodologies. Consideration of past, present, and future, as well as adherence to standards and practices are all core principles of software engineering. Although not perfect, these methodologies facilitate the design of systems with intent and that embody the characteristics of reliability, maintainability, and scalability. Such results come at a price however.

Engineering methodologies aren’t designed to appease zealous demands for irrationally fast software. They’re designed for producing responsible quantifiable results. Consequently, it takes more time to produce a production-ready feature or product when using engineering methodologies. Just as with development methodologies, there’s a place for engineering methodologies and they too aren’t the end-all of building software.

Cost trade-off of methodologies

As with all things designed and built, there’s a cost to creating software as a product for market or as a supporting tool for business. How those costs are depreciated or leveraged should be a conscious business decision that drives technical choices. But surprisingly it’s often not even given a thought.

Adoption of a single methodology as a cultural element of creating software will have a profound impact on the long-term viability of software investments. A young company or product might not be able or willing to wait for sound design and engineering when it comes to software. Choosing speed over quality might produce desirable short-term perceived results, but the long-term cost can’t be avoided.

Think of the fast-track release of a new American car model to beat a foreign competitor to market. The car is designed, built, and released to market in record time, with the accepted risk that recalls, lawsuits, and costly changes to production lines are all acceptable risks to gaining market share. Given the present health of most US car manufacturers, it underscores what such risks can buy long-term.

Software development methodologies do produce faster deliverables, but they also place considerable risks on controlling long-term costs. Engineered systems have a longer time to market, and in some cases a higher initial cost, but they do provide long-term viability that can be leveraged.

In summary, choosing development over engineering must be a conscious business choice, not blind loyalty to any one methodology. As a business choice, there’s good reason for one approach over the other on a project-by-project basis, but when choosing one as a blanket policy you could be risking cost controls, market opportunities, or of most concern given our economy, long-term viability. CW (18 March 2009)

Andrew Anguelo has worked for an array of small and Fortune 500 companies during more than two decades in software engineering. Today he owns a number of diverse businesses and is an active software architect of business and finance systems.