Critical mass (software engineering): Difference between revisions
Content deleted Content added
Antonielly (talk | contribs) |
m Changing short description from "Software engineering term; stage in the life cycle when the source code grows too complicated to effectively manage without a complete rewrite" to "Software engineering term" (Shortdesc helper) |
||
| (27 intermediate revisions by 24 users not shown) | |||
| Line 1: | Line 1: | ||
{{Short description|Software engineering term}} |
|||
{{Unreferenced|date=February 2007}} |
|||
In [[software engineering]], '''critical mass''' is a stage in the [[Product lifecycle (engineering)|life cycle]] when the [[source code]] grows too complicated to effectively manage without a complete rewrite.<ref>{{cite web|url=http://www.testingreflections.com/node/view/8429|title=Sharks, Debts, Critical Mass and other reasons to Sustain Quality|access-date=15 February 2010|url-status=dead|archive-url=https://web.archive.org/web/20100121185859/http://www.testingreflections.com/node/view/8429|archive-date=21 January 2010}}</ref> At the critical mass stage, fixing a [[Software bug|bug]] introduces one or more new bugs.<ref name="catb.org">{{cite web|url=http://catb.org/jargon/html/C/critical-mass.html |title=critical mass |publisher=Catb.org |date= |access-date=2013-09-08}}</ref> |
|||
| ⚫ | |||
'''Critical mass''' in [[software engineering]] is a term used to describe a stage in software [[Product life cycle|life cycle]]: when the [[source code]] grows too large to effectively manage without a complete rewrite<ref>http://catb.org/jargon/html/C/critical-mass.html</ref>. At the Critical Mass stage, fixing one [[Software bug|bug]] can easily introduce several more bugs. |
|||
| ⚫ | Tools such as [[high-level programming language]]s |
||
== 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. |
|||
===Copy-and-paste programming=== |
|||
In order to solve a problem quickly, some developers simply copy 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 [[Bug tracking system|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. |
|||
| ⚫ | |||
<references/> |
|||
| ⚫ | |||
| ⚫ | |||
* [[High-level programming language]] |
* [[High-level programming language]] |
||
* [[Programming in the large]] |
* [[Programming in the large]] |
||
| Line 43: | Line 11: | ||
* [[The Mythical Man-Month]] |
* [[The Mythical Man-Month]] |
||
| ⚫ | |||
| ⚫ | |||
{{Reflist}} |
|||
[[Category:Software |
[[Category:Software project management]] |
||
[[fi:Kriittinen massa (ohjelmistotuotanto)]] |
|||
| ⚫ | |||
Latest revision as of 19:53, 14 February 2022
In software engineering, critical mass is a stage in the life cycle when the source code grows too complicated to effectively manage without a complete rewrite.[1] At the critical mass stage, fixing a bug introduces one or more new bugs.[2]
Tools such as high-level programming languages and techniques such as programming in the large, code refactoring and test-driven development, exist to make it easier to maintain large, complicated programs.
See also
[edit]- High-level programming language
- Programming in the large
- Code refactoring
- Test-driven development
- The Mythical Man-Month
References
[edit]- ^ "Sharks, Debts, Critical Mass and other reasons to Sustain Quality". Archived from the original on 21 January 2010. Retrieved 15 February 2010.
- ^ "critical mass". Catb.org. Retrieved 2013-09-08.
 | This software-engineering-related article is a stub. You can help Wikipedia by expanding it. |