Software Development: A Discipline, Not an Art

Software Development: A Discipline, Not an Art

on Nov 16, 05 • by Lynn Gayowski • with No Comments

Software Must Be Treated as a Critical Business Asset November 15, 2005 – For years, companies producing software have treated the development process as an art. Unlike the other operations of the company that are monitored, managed and measured using formal business process, software development projects are...

Home » Industry Articles » Software Development: A Discipline, Not an Art

Software Must Be Treated as a Critical Business Asset

November 15, 2005 – For years, companies producing software have treated the development process as an art. Unlike the other operations of the company that are monitored, managed and measured using formal business process, software development projects are often the result of ad hoc decisions and activities, with few metrics available to gauge the status or efficiency of a development effort.

The result? By not managing software as the critical business asset it is, companies face escalating development costs, mounting code quality and security issues, and continuous product delays. This art-based, ad hoc approach to software development impacts a company’s top and bottom line, erodes its ability to compete in a fast-paced market, diminishes its brand, and weakens its reputation with prospects, customers, partners and investors.

Art History

The root cause of why companies revert to treating software development as an art stems from the traditional way in which applications are developed over time.

Typically, the first release of a software product is built on an understandable and orderly architecture, reflects customer requirements and is created by a stable and dedicated team of developers and managers. These greenfield development projects may not rely on formal processes and tools, but the project itself tends to be organized, and the codebase is built from scratch to meet the initial product requirements.

The real problems arise with subsequent releases. Ironically, over time development projects are the victims of their own success. With a successful application launch, management and customers will demand a continuous stream of updates that add new features and capabilities to the once relatively elegant and simple codebase. Follow-on development efforts must overcome three major hurdles: new development teams, an existing code and constantly shifting requirements.

By the time the second or subsequent releases of an application gain momentum, the original development team has disbanded.

The new team is usually composed of a few holdovers as well as new coders — both internal and often others from offshore service providers — many of which have no knowledge of the original architecture, design decisions and codebase. And instead of the ability to create a pure architecture that reflects current project requirements, the new team must modify the application or create new modules on top of an existing, increasingly bloated codebase.

In addition, with an invested customer base requesting bug fixes and new capabilities, and an internal marketing organization attempting to influence the feature set to out-deliver the competition, the project must deal with constantly morphing system requirements.

With an increasingly complex application and compressed project schedules, and no way to monitor and manage the process, the codebase quickly erodes in quality. The ever-present pressure to meet corporate deadlines leads to shortcuts and other bad coding practices.

In order to get a release out the door, well-meaning managers and developers eschew the initial more disciplined approach and rely on process and activities that look more like art. Software defects, security vulnerabilities and project delays plague subsequent application releases. And after each release, the next development team faces an even more fragile, dependency-riddled codebase full of complex, hard-to-understand code.

Breaking the Cycle

Since most development projects do not start from a blank sheet of the paper, how can companies break this cycle? Organizations need to replace the art of coding with the discipline of software development. In other words, companies need to start managing software assets in the same way that they manage other business assets. They need to introduce and embrace a more formal way to mange the entire development process.

Historically, companies have avoided going this route.

Why? Because managers felt the solutions the industry offered or proposed were too time-consuming to implement and too costly to justify given their well-known limitations.

And mangers knew that any attempted imposition of formalized processes without a means to monitor and manage them doomed efforts to overhaul software development.

But now, the situation is ripe for change. The top- and bottom-line impact of bloated, fragile code that is a result of this inefficient, art-based process is becoming impossible to ignore. A codebase that may have once contained a few annoying bugs that customers and the company were willing to live with has now become a business liability and a playground for global hackers.

Even nontechnical, senior executives can’t avoid this situation anymore. They can feel directly how low-quality software degrades their business, and they are constantly reminded of the price of poor coding from the never-ending stream of high-profile media reports of failed software.

Executive interest to improve the development process, coupled with the introduction of new ways to analyze and improve code, means that companies are now motivated and capable of moving to a disciplined software development approach.

But to be successful, companies must get their developers to buy into the discipline approach. Coders need to understand how a discipline-based development approach will improve their work life by helping them write code that adheres to corporate guidelines; reducing the monotony of testing for errors, tracking down defects and implementing fixes; and improving their coding quality and productivity.

In addition, by enabling their managers to better gauge the status of a project and the impact of requirement changes, developers will have a better understanding of how realistic project deadlines are.

The payoff? One large development corporation reports that embracing a discipline-based approach has cut the time its developers need to understand an application’s context in half. Another company says that a code analysis that typically required one week now takes only one hour.

With both managers and developers buying into discipline-based development practices, companies can expect to deliver high-quality, secure software for a lower cost and at a quicker pace.

Djenana Campara is founder, CTO and chairman of Klocwork, which sells code quality assurance and security testing tools.

About Klocwork

Klocwork® offers a portfolio of development productivity tools designed to ensure the security, reliability and maintainability of complex code bases. Using proven static analysis technology, Klocwork’s tools identify critical security vulnerabilities and reliability defects, optimize peer code review, and help developers create more maintainable code. Klocwork’s tools are an integral part of the development process for over 1000 customers in the consumer electronics, mobile devices, medical technologies, telecom, military and aerospace sectors.

Media Contact:
Meranda Powers


Klocwork and the Klocwork logo are registered trademarks of Klocwork, Incorporated in the United States and other countries. All other names are trademarks or registered trademarks of their respective companies.

Related Posts

Leave a Reply

Your email address will not be published. Required fields are marked *

Scroll to top