Talk:Software Peter principle

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
Mid	This article has been rated as Mid-importance on the project's importance scale.
	This article is supported by WikiProject Software.

Systems Mid‑importance

	Systems science portal This article is within the scope of WikiProject Systems, which collaborates on articles related to systems and systems science.SystemsWikipedia:WikiProject SystemsTemplate:WikiProject SystemsSystems articles
Mid	This article has been rated as Mid-importance on the project's importance scale.
	This article is within the field of Systems engineering.

Greenspun's Tenth Rule

Surely this idea of the Software Peter principle overlaps very much with Greenspun's Tenth Rule of "Any sufficiently complicated [Cpp (heir of Fortran)] program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of [Python (heir of Lisp)]"? How then should we inter-link or merge those two articles? Pelavarre (talk) 17:40, 25 October 2013 (UTC)[reply]

So what is it?

I see three or four things in this article

the subject comes from a book
it has to do with projects dying by rising complexity
three seemingly random software project problems are listed as causes

What's missing is a definition of the subject. A "principle" is usually summarized in a brief statement, like Brook's Law or the Peter Principle. JöG (talk) 10:35, 20 January 2008 (UTC)[reply]

Agreed. Other causes could include frequent software engineer turn-over, for example. I like having a name for the problem, but the "causes" section suggests more than it's qualified to claim. Perhaps a title of "Examples" rather than "Causes"? 128.170.224.10 (talk) 21:52, 30 April 2010 (UTC)[reply]

Agreed - those sections under cause amount to original research in my mind. The author has selectively chosen items from various sources and drawn a conclusion these are the cause.— Preceding unsigned comment added by 122.56.25.130 (talk • contribs) 31 October 2019 (UTC)

Dated OR passage

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 by Fred Brooks[citation needed]. 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.
In projects without a strong software architecture team, the task of design is often combined with the task of implementation and is implicitly delegated among the individual software developers. Under these circumstances, developers are less likely to sacrifice personal interests in favor of the interests of the product. 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.

This passage mirrors the concept of Brooks' Surgical Team, which was still somewhat in vogue in the 1980s, but hasn't been seen much since. In the early stages of the PC revolution, more than half of all programmers had degrees in physics (by aptitude) or psychology (by necessity) or something of that nature. Additionally, the discipline wasn't terribly mature, and there wasn't a great body of practice to fall back upon (which is what made Mythical so exceptional, back in the day).

I'm not even sure this precept is still relevant to most software projects, which these days usually start with a substantial stack, with a fair amount of decomposition preordained.

My vote would be to rewrite portions of this article more in a diagnostic vein: here are some of the known shoot-self-in-foot software complexity failure modes, and here are some possible antidotes, should you need them. In doing so, we should back away from blanket wisdom, and programming lore that predates the Hudson's Bay point blanket. — MaxEnt 01:17, 20 May 2018 (UTC)[reply]