Critical mass (software)

Critical mass in software engineering is a term used to describe a stage in software life cycle: when the source code grows too large to effectively manage without a complete rewrite [http://catb.org/jargon/html/C/critical-mass.html] . At the Critical Mass stage, fixing one bug can easily introduce several more bugs.

Tools such as high-level programming languages, object-oriented programming languages [http://duramecho.com/ComputerInformation/WhatIsObjectOrientedProgramming.html] , and techniques such as test-driven development, are being developed to make it easier to maintain large, complicated programs.

Causes

Any or all of the following can contribute to a project reaching the disorganized state of Critical Mass:

Poor Planning

Large software projects are often poorly planned. Sometimes, in an effort to attract investment capital, a "quick and dirty" project is completed. This could succeed completely in its goals — getting investment. The next step is to use the investment and interest to reformulate the project into a more mature and stable version; however, this revision is often skipped, and the flawed initial design is used as a base for adding features. This can quickly lead to a very disorganized and unmaintainable codebase.

Developer Turnover

If the original developers of a project leave, newcomers must move the project forward. Poor, nonexistent, or ignored documentation can lead to several incompatible implementations that attempt to solve the same problems. Additionally, the techniques of newcomers might be inherently incompatible with what already exists in the codebase.

Cut-and-paste programming

In order to solve a problem quickly, some developers simply cut and paste in code that addresses a similar problem. This code is then modified to address the specific problem at hand. This is considered sloppy programming, and can lead a developer to easily overlook errors in the pasted code.

Solutions

Tools

* Good core development tools (e.g. a capable compiler) should be used with higher warning levels and a commitment to eliminate all warnings.
* Sufficient documentation should exist. It should be concise and comprehensive, and it should be maintained thoroughly.
* Bugs should be fixed as soon as possible to prevent developers from forgetting them. A system for tracking and prioritizing bugs is essential.
* A revision control system should be used, and its ability to include comments should be taken advantage of.

Techniques

* Functions "created" for tasks instead of using cut-and-paste to duplicate functionality.
* If a function's interface can be improved or simplified, the change should be made to the function and anything that calls it.
* The implementation of a function should be isolated from the function's interface. This is a goal of object oriented programming.
* Disorganized code should be isolated from cleaner code to enhance readability.
* Large applications frequently are built on top of workhorse functions that are invoked as needed. If a workhorse function is going to be used in many places, the function should be easy to use. Complexity belongs in the implementation of the function itself.
* Source formatting conventions should be planned before the project begins. The formatting should be well-documented and consistently used.

See also

* Programming in the large
* The Mythical Man-Month
* Refactoring