Software Peter principle

Last updated

The Software Peter principle is used in software engineering to describe a dying project which has become too complex to be understood even by its own developers.

Contents

It is well known in the industry[ citation needed ] as a silent killer of projects, but by the time the symptoms arise it is often too late to do anything about it[ citation needed ]. Good managers can avoid this disaster by establishing clear coding practices where unnecessarily complicated code and design is avoided.

The name is used in the book C++ FAQs (see below), and is derived from the Peter principle  – a theory about incompetence in hierarchical organizations.

Causes

Loss of conceptual integrity

The conceptual integrity of software is a measure of how well it conforms to a single, simple set of design principles, according to The Mythical Man Month . [1] When done properly, it provides the most functionality using the simplest idioms. It makes software easier to use by making it simple to create and learn[ citation needed ].

Conceptual integrity is achieved when the software’s design proceeds from a small number of agreeing individuals[ citation needed ]. For software to maintain conceptual integrity, the design must be controlled by a single, small group of people who understand the code (including the nature of how all the subroutines and variables interact) in depth[ citation needed ].

In projects without a strong software architecture team, the task of design is often [ weasel words ] combined with the task of implementation and is implicitly delegated among the individual software developers [ citation needed ]. Under these circumstances, developers are less likely to sacrifice personal interests in favor of the interests of the product[ citation needed ]. The complexity of the product grows as a result of developers adding new designs and altering earlier ones to reflect changes in fashion and individual taste[ citation needed ].

Programmer incompetence

Good software developers understand the importance of communicating with people over communicating with the computer, according to Code Complete . [2] Studies showed that programmers spends more than 50% of their time communicating with people, while the actual programming may only take up as little as 15% to 10%, depending on the level of seniority. [3] [4] [5] [6]

Maintenance programmers spend 50 to 60 percent of their time trying to understand the code they have to maintain and a software program will have, on average, 10 generations of maintenance programmers in its lifetime[ citation needed ].

Programmer inexperience

Programmers sometimes make implementation choices that work but have unintended negative consequences. The most common of these mistakes are cataloged and referred to as smells in the book Refactoring . [7] Over time, many such implementation choices degrade the software’s design, making it increasingly difficult to understand.

See also

Related Research Articles

<span class="mw-page-title-main">Martin Fowler (software engineer)</span> American software developer, author and public speaker

Martin Fowler is a British software developer, author and international public speaker on software development, specialising in object-oriented analysis and design, UML, patterns, and agile software development methodologies, including extreme programming.

In computer programming and software design, code refactoring is the process of restructuring existing computer code—changing the factoring—without changing its external behavior. Refactoring is intended to improve the design, structure, and/or implementation of the software, while preserving its functionality. Potential advantages of refactoring may include improved code readability and reduced complexity; these can improve the source code's maintainability and create a simpler, cleaner, or more expressive internal architecture or object model to improve extensibility. Another potential goal for refactoring is improved performance; software engineers face an ongoing challenge to write programs that perform faster or use less memory.

<i>The Mythical Man-Month</i> 1975 software engineering book by Fred Brooks

The Mythical Man-Month: Essays on Software Engineering is a book on software engineering and project management by Fred Brooks first published in 1975, with subsequent editions in 1982 and 1995. Its central theme is that adding manpower to a software project that is behind schedule delays it even longer. This idea is known as Brooks's law, and is presented along with the second-system effect and advocacy of prototyping.

<span class="mw-page-title-main">Software architecture</span> High level structures of a software system

Software architecture is the set of structures needed to reason about a software system and the discipline of creating such structures and systems. Each structure comprises software elements, relations among them, and properties of both elements and relations.

In computer programming, unit testing is a software testing method by which individual units of source code—sets of one or more computer program modules together with associated control data, usage procedures, and operating procedures—are tested to determine whether they are fit for use. It is a standard step in development and implementation approaches such as Agile.

<span class="mw-page-title-main">Unix philosophy</span> Software development philosophy

The Unix philosophy, originated by Ken Thompson, is a set of cultural norms and philosophical approaches to minimalist, modular software development. It is based on the experience of leading developers of the Unix operating system. Early Unix developers were important in bringing the concepts of modularity and reusability into software engineering practice, spawning a "software tools" movement. Over time, the leading developers of Unix established a set of cultural norms for developing software; these norms became as important and influential as the technology of Unix itself, and have been termed the "Unix philosophy."

Brooks's law is an observation about software project management that "Adding manpower to a late software project makes it later." It was coined by Fred Brooks in his 1975 book The Mythical Man-Month. According to Brooks, under certain conditions, an incremental person when added to a project makes it take more, not less time.

In computer programming, a code smell is any characteristic in the source code of a program that possibly indicates a deeper problem. Determining what is and is not a code smell is subjective, and varies by language, developer, and development methodology.

Rapid application development (RAD), also called rapid application building (RAB), is both a general term for adaptive software development approaches, and the name for James Martin's method of rapid development. In general, RAD approaches to software development put less emphasis on planning and more emphasis on an adaptive process. Prototypes are often used in addition to or sometimes even instead of design specifications.

Test-driven development (TDD) is a software development process relying on software requirements being converted to test cases before software is fully developed, and tracking all software development by repeatedly testing the software against all test cases. This is as opposed to software being developed first and test cases created later.

A programming tool or software development tool is a computer program that software developers use to create, debug, maintain, or otherwise support other programs and applications. The term usually refers to relatively simple programs, that can be combined to accomplish a task, much as one might use multiple hands to fix a physical object. The most basic tools are a source code editor and a compiler or interpreter, which are used ubiquitously and continuously. Other tools are used more or less depending on the language, development methodology, and individual engineer, often used for a discrete task, like a debugger or profiler. Tools may be discrete programs, executed separately – often from the command line – or may be parts of a single large program, called an integrated development environment (IDE). In many cases, particularly for simpler use, simple ad hoc techniques are used instead of a tool, such as print debugging instead of using a debugger, manual timing instead of a profiler, or tracking bugs in a text file or spreadsheet instead of a bug tracking system.

In computing, an interface is a shared boundary across which two or more separate components of a computer system exchange information. The exchange can be between software, computer hardware, peripheral devices, humans, and combinations of these. Some computer hardware devices, such as a touchscreen, can both send and receive data through the interface, while others such as a mouse or microphone may only provide an interface to send data to a given system.

"You aren't gonna need it" (YAGNI) is a principle which arose from extreme programming (XP) that states a programmer should not add functionality until deemed necessary. Other forms of the phrase include "You aren't going to need it" (YAGTNI) and "You ain't gonna need it".

Lean software development is a translation of lean manufacturing principles and practices to the software development domain. Adapted from the Toyota Production System, it is emerging with the support of a pro-lean subculture within the agile community. Lean offers a solid conceptual framework, values and principles, as well as good practices, derived from experience, that support agile organizations.

Extreme programming (XP) is an agile software development methodology used to implement software projects. This article details the practices used in this methodology. Extreme programming has 12 practices, grouped into four areas, derived from the best practices of software engineering.

Coding conventions are a set of guidelines for a specific programming language that recommend programming style, practices, and methods for each aspect of a program written in that language. These conventions usually cover file organization, indentation, comments, declarations, statements, white space, naming conventions, programming practices, programming principles, programming rules of thumb, architectural best practices, etc. These are guidelines for software structural quality. Software programmers are highly recommended to follow these guidelines to help improve the readability of their source code and make software maintenance easier. Coding conventions are only applicable to the human maintainers and peer reviewers of a software project. Conventions may be formalized in a documented set of rules that an entire team or company follows, or may be as informal as the habitual coding practices of an individual. Coding conventions are not enforced by compilers.

In software development, or any other IT field technical debt is the implied cost of future reworking required when choosing an easy but limited solution instead of a better approach that could take more time.

Software archaeology or source code archeology is the study of poorly documented or undocumented legacy software implementations, as part of software maintenance. Software archaeology, named by analogy with archaeology, includes the reverse engineering of software modules, and the application of a variety of tools and processes for extracting and understanding program structure and recovering design information. Software archaeology may reveal dysfunctional team processes which have produced poorly designed or even unused software modules, and in some cases deliberately obfuscatory code may be found. The term has been in use for decades.

<span class="mw-page-title-main">Extreme programming</span> Software development methodology

Extreme programming (XP) is a software development methodology intended to improve software quality and responsiveness to changing customer requirements. As a type of agile software development, it advocates frequent releases in short development cycles, intended to improve productivity and introduce checkpoints at which new customer requirements can be adopted.

In computer programming, a design smell is a structure in a design that indicates a violation of fundamental design principles, and which can negatively impact the project's quality. The origin of the term can be traced to the term "code smell" which was featured in the book Refactoring: Improving the Design of Existing Code by Martin Fowler.

References

Literature