A Note on the Relationship of Brooks Law and Conway Law

By Dr. Nikolai Bezroukov

Version 1.0, December, 2018

Copyright 2011-2018, Dr. Nikolai Bezroukov. This is a copyrighted unpublished work. All rights reserved.

• Abstract

• Introduction

• Critique of Wikipedia "Exceptions"

• Critique of Scott Berkun Observations on Brooks Law

• Supplement

Abstract

First and foremost, not too much zeal
~ Talleyrand advice to young diplomats

Contrary to popular perception Brooks law is not about shortcoming of man-month metric, or even side effect of adding the developers at the late stage of the project.  It is not even about the negative correlation of the length of the project and number of developers added at the later stages (when the project is already behind the schedule). Like Conway law it is about complex relationship between structure of the project and structure of the team of developers involved. 

The real message of Brooks law is that, grossly simplifying, adding manpower to the late project is not trivial task,  unless the structure of the team has "free spaces" they can fit. The second factor is that the history of development of a large software project is typically unwritten saga known  only to long time members  of the team; without knowing the history and agreed compromises, side pressures, and dead ends eliminated, the new developer can easily get into serious troubles and their efforts can be counterproductive and slow down the team. Especially if they have excessive enthusiasm. That's why their contribution can be negative -- they can make late project even more late.

But there is third factor that often escape attention -- there is a natural limit the number of productive team members in each project (and not only because a real software development talent is a rare commodity), as the areas of responsibility need to be carved very carefully according to adopted architecture. that's why development of  complex software that requires multiple developers is much more complex art that a development of a project in which a single developer can be used.  Adding additional developers changes organization organization structure and that in turn affects adopted architecture. The effect might be positive, neutral or negative.  The latter can even doom the project, not only make it more late. 

It is simplistic to assume that modularity of a project permits unlimited the number of developers who can be effective and work without stepping on each other toes. Number of developers who are participating in given project is affected by many factors and strongly affects the architecture of the product as each developer try to carve his niche and then enlarge it according to the level of talent and ambitions.

In other words, there is a feedback loop from the structure of the developer group to the structure of the software system under development. This is probably the most overlooked side of  Brooks Law.  Mervin Conway was the first to note this complex relationship. That's why Brooks law and Conway law are interrelated.

One interesting side effect of relationship of Brooks and Conway Laws is common cases of deterioration of architectural integrity of large open source project after the key/initial developer left the project.  Ambitious high productivity programmer who lacks architectural vision can kill the project by trying to improve it, to leave his scratch. 

Introduction

Brooks Law came under scrutiny due to that fact the Eric Raymond claimed that it is not applicable to open source development in his simplistic, but popular at the time article "Cathedral and Bazaar". It contradicts "Bazaar" fairy tale which is an essential part of the ideology of "Raymondism" which along with Stallmanism are two most prominent open source ideologies.  It was informally adopted by an influential part of open source movement which preach merging open source development with the commercialization of open source (using modified "slaves on the plantation" model).  And those pseudo-religious overtones polluted the discussion ever since.

But the essence of Brooks law is not so much about the fact that adding manpower to the late project more often then not makes it later. The essence is that it postulates complex relationship between the structure of the project and structure of the team of developers involved.  In this sense it is related to Conway law which postulate existence of correlation between organizational structure of development team and the architecture of the software project under development. Only the side effect of  this relationship is exposed in the brooks law: the fact that grossly simplifying, adding manpower to the late project is not trivial task that more often then not makes late project even more late. Sometimes consequences can be more severe that just the delay in project delivery. It might also negatively affect the final quality. In extreme cases this "late reorganization of the development team" (and adding developers is essentially a reorganization) may doom the project. 

It is simplistic to assume that modularity on a project determines the number of developers who can be effective and work without stepping on each other toes. The number of developers who are participating in given project affects the architecture of the product including modularity, as each developer (or group of developers in very large projects) try to carve own niche, most comfortable for thier subsystem.   In other words, there is a feedback loop from the structure of the developer group to the structure of the software system under development. This is probably the most overlooked side of  Brooks Law:

Just look at the addition of systemd daemon in RHEL 7.  This is a textbook case when ambitious group of developers tried to expend their "Lebensraum" and capture areas which initially were not supposed to be performed by a given subsystem (init subsystem in linux in this particular case).  In the process they undermined the conceptual integity of Linux and effect of this change "in a long run" is completely unclear.

It is generally it is architecture and modularity that determines the optimal number of developers who can productively work on  a given project in parallel. Of course good communication protocols are the also the key: 

"For example if a project logically consists of three parts and we have two developers, than adding third developer can be highly beneficial -- the structure of the project will now correspond to the structure of the team. If the project is decomposable into three major parts and we add fourth developer, the effect will be much less."

But what will happen if we add the forth developers to this project? He and the manager of the project will try to carve him particular niche and that might distort the structure of the project. Or one of its three modules, which now may well appear as two. The fact that team of developers exert influence on the structure of software system under development is nothing new and was first discovered by Melvin Conway around 1967 (Wikipedia):

"organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations."— M. Conway^[2]

It is known as Conway Law.  For those who don't remember Conway law here is the definition from Wikipedia

Although sometimes construed as humorous, Conway's Law was intended as a valid sociological observation. It is based on the reasoning that in order for two separate software modules to interface correctly, the designers and implementers of each module must communicate with each other.

Therefore, the interface structure of a software system will reflect the social structure of the organization that produced it.

The key point of this quote is that Brooks Law and Conway Law are deeply interconnected and reflect different sides of the same phenomenon. The fact that the excessive number of developers added at late stages of the project can negatively affect the architecture and the integrity of the product was the key topic of Brooks book, which after all is about of his expensive failure as the operating system architect of OS/360. As he admits in the book, in this role he was unable to withstand the pressure of  involving large group of the developers in the kernel development project and as a result got a weak, poorly architectured OS.  This extremely important lesson of OS/360 development is now "lost in translation". 

The relationship between Conway Law and Brooks law runs deeper then stated in Brooks's book. Developers are not passive pawn moved by a "Grossmeister" architect on the development chessboard. Unless chess peaces, they are active and have their own ambitions which drive theirs behavior in ways that often looks illogical to the outside observer. The history of large projects is replete with instances of various skirmishes, some very small and insignificant, some larger and pretty significant,  in which some developers may take role of the  attackers of "status quo". But implicit fight is always about the control.  Some developers may even leave the project as a result of those conflicts, or become resented and much less productive.  Generally the more talented the developer is, the more ambitious he/she is and the more control of the project he/she wants.  Not the other way around. 

That's why management of software developers in large projects is often compared to "herding cats" and in this sense adding a talented developer to the project at late stage is a more dangerous exercise then adding average developer. Not only it involves taking a part of work and responsibilities from the existing developer and bestowing them on a new member of the team, who generally need time to learn the ropes (and at least at he beginning is totally dependent on the good will of existing developers). As soon as he start to understand the rope he also start to his explicit or implicit fight for the level control of the project commensurate with his abilities.  With a weak project manager  who does not possesses an adequate architectural knowledge and can't predict the conflicts that can arise due to interconnections of the parts, such actions often disrupts existing power structure, the pecking order and introduce latent conflict which is detrimental to the project.

I would say more: adding talented developers beyond the number necessary to control key subsystems can have a crippling effect on the structure of the product as implicitly they will fight for their "breathing space".   I observed this effect myself during big but boring reengineering projects, which supposedly should not excite too much ambitions in the participants as the system already exists, proven and just needs to be rewritten in a different language and/or for different platform.  But no, passions flare high and attempts to carve extra space from more ambitious and more abrasive part of the team consumed a lot of my time. At one point, I was forced just to remove the developer who was overly "possessive" about particular subsystem as the whole subsystem he was responsible for could be  better integrated with the another.  You can find similar examples in the history of large open source projects too.

Managers is another wild card and in commercial projects they add to the equation in very unobvious way, often prematurely freezing the architecture as well as by complicating (and sometimes withholding to increase their own importance) vital communication between developers. I felt such a temptation myself several times. And that's not because they are evil, they just want to protect their place in the implicit power structure of the particular project which allow them to exert the influence they feel is necessary for the success of the project.  If they are not technically astute they represent huge obstacle in any desirable change of the architecture.  In a biting satire Addendum to Brooks’ Law - MindBy noted:

I just read Joel Spolsky’s blog entitled “A Little Less Conversation” which discusses something I’ve blogged about in the past here and here, communication overload.

After reading that post I began to consider my own personal experience in meetings over the last dozen or so years and decided to add an addendum to the communication node problem that was so eloquently detailed in the Mythical Man Month by Brooks.

The problem with Brooks’ theory of intercommunication is that it doesn’t take into account the “Number of Managers” in any given meeting.  He assumes in his calculation that all nodes in a communication network are equal.  This is a mistake.  All nodes are not equal, as anyone who has sat through a meeting with more than one manager participating can attest to.

Managers have keen insight into every major (and minor) issue at hand and willingly share that information with the team in a seemingly endless discourse that greatly adds to the meeting’s productivity and value.  In fact I’ve been in meetings with multiple managers that have lasted two, maybe three, times longer than the scheduled meeting length due to the significant wisdom that each of the managers was imparting to their counterparts and the team.

Critique of Wikipedia "Exceptions"

Let me address some of the points in Wikipedia, which defend  Raymond's critique of Brooks Law by providing plausible "exceptions":

1. The first point is to note that Brooks' Law often applies to projects that are already late.[4] Projects can be brought back into (or kept in) control if people are added earlier in the process.[5] It is also important to determine if the project is really late, or if the schedule was originally overly optimistic. Scheduling mistakes account for a large number of late projects. Correcting the schedule is the best way to have a meaningful and reliable time frame for the project's completion.[6]

   First of all overoptimistic schedule is the immanent feature of software projects, do it goes without saying. For all my career I never saw a project where schedule was overly conservative :-). Also being late to the market has distinct consequences for any projects, open source included. Sometimes making them irrelevant. Few, for example,  now care if, for example Perl 6 is magically delivered to the amazed audience in its full glory.
    

2. The quantity, quality and role of the people added to the project also must be taken into consideration. One simple way to circumvent the law on an overrun project is to add more people than needed, in such a way that the extra capacity compensates the training and communication overhead.[7] Good programmers or specialists can be added with less overhead for training.[8] People can be added to do other tasks related with the project, for example, quality assurance or documentation; given that the task is clear, ramp up time is minimized.[9]

   Yes, quality of people should be taken into consideration, but effects are not those that are proposed. The key issue is the availability of a free "modular space" or not (It can also be created artificially by moving some less productive developers to less responsible position; but there dangers here). If there is no free "modular space", the capability of the developer can serve as a disruptive force, dynamite to the building already on fire, so to speak.  Especially if documentation of the project is outdates and is mostly unwritten Folklore. Nobody like to be a pawn in somebody else game, and talented developers are much less included to play this role then the general population.  Some of them will always play their own game and the manager who brought those developers will have not much control after the fact, as his own credibility now lingers on the decisions made.
    

3. Good management and development practices also help to minimize the impact of Brooks' Law. The modern practices of continuous integration, test first design, and iterative development significantly reduce the inter-developer communication overhead, and thus allow for better scalability. New tools for software development and documentation also help to minimize the ramp up time, making it simpler for new programmers to get involved in the work. Design patterns simplify the distribution of work, because the entire team can do its part within the framework provided by that pattern. The design pattern defines the rules that the programmers follow, simplifies communication through the use of a standard language, and provides consistency and scalability. Finally, good segmentation helps by minimizing the communication overhead between team members. Smaller sub-problems are solved by a smaller team, and a top-level team is responsible for systems integration. For this method to work, the segmentation of the problem must be done correctly in the first place; if done incorrectly, this can make the problem worse, not better, by impeding communication between programmers working on parts of the problem which are actually closely coupled, even when the project plan has decreed that they are not.

   What is called  "Good management and development practices " by some, can be called as stagnation and red tape by others. Those waterfall methodologies like "continuous integration, test first design, and iterative development " Often the key problem of the project is that the leading developer lost motivation and left the wheel, allowing even less capable members of the team to draw shots. Resulting loss of architectural integrity can be fatal, no matter who and when you add.  If this happens, only heavens can save the project as much less capable people will now drive key decisions.

   Also at some point it might became clear that the current architectural solution is inadequate and needs to be replaced by a better one. This is a difficult decisions to make and preaching continuity makes it even more difficult. Disruptions are not always harmful. Sometime canning the subsystem is the way to go instead of adding the developers. 
    

4. Some authors – see, for example, Creating a Software Engineering Culture by Karl E. Wiegers – have stressed the importance of the social and political aspects of the work climate as determinants of the effectiveness of individual programmers and the project team as a whole. Rather than depending on heroes to carry the day with extraordinary efforts,

   There is no place for ordinary people for leading roles in large software projects. If such projects can be delivered with "ordinary" leaders you can bet that other similar projects already exist and can be used instead. So the whole point of development became mute. In large scale, complex projects,  the vision of the key developer/architect is the decisive force. It is much like role of field-marshal on the battlefields. The individual units might be OK and fight bravely, but they will not fight with the same ferocity if they do not see the leader as a visionary, and the cause honorable. On the contrary, with the talented leader often average teams can deliver amazing results.  People really want to sacrifice their family time and often their health for a noble cause led by the leader they admire and try to emulate. 

Critique of Scott Berkun Observations on Brooks Law

• It depends who the manpower is. The law assumes that all added manpower is equal, which is not true. Given the choice of adding a good programmer, who knows the code base and is friends with half the team, I’d consider it. Knowledge of the code and good relationships with the team offsets the two key reasons for Brooks law (ramp up and communication overhead). And if that individual has prior experience coming in late to a project, all the better. Some people are capable of playing the SWAT team / Ninja role, and that skill is orthogonal to programming talent: some are simply better are getting complex work done on unfamiliar terrain with a minimum of disruption.

  Yes it depends on the who constitute "manpower" for the project but in a different way that it was assumed above. First of all, if existing developers see newcomers as a treat they can easily mothball them and it is difficult to change this situation. So all the more unrewarding part of the task can be offloaded, especially in late project when the pressure to deliver is high.

  The second point is that role of the management is often contradictory. They want to play both hands.
   

• Some teams can absorb more change than others. Some teams are more resilient to change. They can absorb communication overhead and teaching duties better than others can. It’s well known that there is a wide range among programmers in their speed, but it’s also true there is a wide range for communication and teaching skills. Even if all teams pay a price for adding people, that price will vary widely and is not a fixed cost based on the # of people alone(e.g. n*n).
  
  This is a realistic observation, but again it misses the fact that added people provide an incentive and pressure to change the architecture which can be disruptive in its own way independently on the ability/willingness to teach, good will, etc.
   
• There are worse things than being late. The conclusion most people reach is that, given Brooks law, you should never add people. But it doesn’t say that: it just says you’ll be late. That can be OK if you also get higher quality (not a guarantee of course). Time is not the only success criteria. If the person you’re adding fills an important hole in in the team, being later might be worth it.

  This is very true observation. but often project myopia prevents from seeing and acting that way.  In a way. shortsighted management is a huge problem in late projects.   Also often money are finite and running out of money is a real failure.  This is often true for complex porting projects.
   

• There are different ways to add manpower. The sad but popular approach is to throw people in without much explanation and let everyone figure it out for themselves. But if the manager clarifies why Sally and Rupert are joining, and defines good roles for them, with input from the team, they’ll be set up to make a smooth transition. This can also include assigning them a mentor who is capable and motivated to be their primary point of contact for ramp up issues. The more experience everyone has with mid-stream personnel changes, the better. Some tasks will always be better suited to assigning new people and it’s the managers task to figure out which ones those are.

  That's baloney. When project is late the level of chaos is considerable, morale is typically low,  everybody is hugely overloaded acting  under stress, and because of that the decisions are more often then not are not well thought out.  Leading developers are overloaded and have simply very little time for explanations in this hectic atmosphere. To say nothing about assigning a mentor. Existing developers are too busy making important decisions in the heat of that battle. While the specifications are necessary and are, in general, "a good idea" (as in attributed to Mahatma Gandhi acerbic remark to a self-confident Western journalist: on  the question “What do you think of Western civilization?,” he reportedly have answered, “I think it would be a good idea” :-)

  The final stages of the project are typically very hectic and not a good time to write specification and provide explanations (which BTW is one  of the key roles of the project manager and chief architect of the project).  It should be done  much earlier and if this time is lost, you have what you have and might fight  with the weapons that you have, that with the weapons you want to have.  It is easy to critique any large project sitting on some high hill and observing the battle for a safe distance.  I know a project in which the key developer died from the overload trying to deliver the product and part of the problem was that he was provided with just too much help in order to finish the project on time. That drained his resources into communication and created double load and the level of stress which possibly was fatal.
   

• It depends on why the project was late to begin with. If the project was late because of inexperience or poor team practices, adding a small number of experienced people with those missing skills, and directing others to follow them, can eliminate some of those inefficiencies: not all knowledge or skill transfer requires long lead times. Therefore the added value of certain manpower is not just 1 additional programmer unit, but 1+, as they have a positive effect on the productivity of others. But more importantly, there are many reasons for being late that have nothing to do with the programming team personnel: no amount of programming staff modifications will resolve the psychiatric needs of team leaders or the dysfunctions of executives.

  That's true observation and the amount of psychopaths among senior management is alarmingly high. Dysfunctional, technically incompetent senior management infects everything below and the project became a death march.
   

• Adding people can be combined with other management action . Contrary to popular belief, management is not a turn based strategy game. You can do more than one thing at the same time. For example, you can remove someone at the same time you’re adding manpower. This does increase volatility, but if you’re removing your worst, and most disruptive, programmer and adding one of your best, it can be a reasonable choice. Managers also have the option to cut or reorganize work across the project, improve tools and equipment, throw a social event to accelerate team relationships, etc. There are always ways for managers to provide cover fire. These all have disruption costs, but depending on the length of the project they might be offset.

  That's true. Moreover  for talented managers the fact that the project is late might even serve a positive role, becoming a rallying battle cry to extract additional efforts from the team. Looks at Microsoft history. All their projects were late and many of them were successful.  Some people just feel OK in the overcharged atmosphere of the project rush.

Supplement

Wikipedia text used in the note (accessed March 9, 2011)

Exceptions and possible solutions

Brooks' Law is often cited to justify why projects keep being late, despite management efforts. However, there are some key points in Brooks's Law that allow exceptions and open the door for possible solutions.[2][3]

The first point is to note that Brooks' Law often applies to projects that are already late.[4] Projects can be brought back into (or kept in) control if people are added earlier in the process.[5] It is also important to determine if the project is really late, or if the schedule was originally overly optimistic. Scheduling mistakes account for a large number of late projects. Correcting the schedule is the best way to have a meaningful and reliable time frame for the project's completion.[6]

The quantity, quality and role of the people added to the project also must be taken into consideration. One simple way to circumvent the law on an overrun project is to add more people than needed, in such a way that the extra capacity compensates the training and communication overhead.[7] Good programmers or specialists can be added with less overhead for training.[8] People can be added to do other tasks related with the project, for example, quality assurance or documentation; given that the task is clear, ramp up time is minimized.[9]

Good management and development practices also help to minimize the impact of Brooks' Law. The modern practices of continuous integration, test first design, and iterative development significantly reduce the inter-developer communication overhead, and thus allow for better scalability. New tools for software development and documentation also help to minimize the ramp up time, making it simpler for new programmers to get involved in the work. Design patterns simplify the distribution of work, because the entire team can do its part within the framework provided by that pattern. The design pattern defines the rules that the programmers follow, simplifies communication through the use of a standard language, and provides consistency and scalability. Finally, good segmentation helps by minimizing the communication overhead between team members. Smaller sub-problems are solved by a smaller team, and a top-level team is responsible for systems integration. For this method to work, the segmentation of the problem must be done correctly in the first place; if done incorrectly, this can make the problem worse, not better, by impeding communication between programmers working on parts of the problem which are actually closely coupled, even when the project plan has decreed that they are not.

Some authors – see, for example, Creating a Software Engineering Culture by Karl E. Wiegers – have stressed the importance of the social and political aspects of the work climate as determinants of the effectiveness of individual programmers and the project team as a whole. Rather than depending on heroes to carry the day with extraordinary efforts,

Wiegers argues that a team of ordinarily-skilled individuals can repeatedly deliver timely results in the right work environment. Efforts to improve the effectiveness of teams can ameliorate, if not eliminate, the consequences of Brooks's law.

A recent instance shows the fallacies of relying on Brook's Law in rapidly changing areas like open source software. Destroying the man-month myth

Open source software development

While open source projects rarely have schedules, nonetheless they can reach a state in which they are called "late" by their sponsors, participants, and users. In such a case, Brooks's law ("adding manpower to a late software project makes it later") surely applies, for exactly the reasons that Brooks enumerates:

• time for the new developers to become productive
• increased communication overhead.

In addition, unless there are strict controls, newcomers may reduce the productivity of experienced developers by checking in buggy or inappropriate changes, which then have to be backed out.

Read more: http://www.answers.com/topic/brooks-law#ixzz1G9FtA81Y

•a b Frederick P. Brooks, Jr. "The Mythical Man Month". 1995. Addison-Wesley.
•^ "In spite of Brooks’ Law, adding people to a late project remains commonplace" ... "I have evangelized this well-worn software engineering chestnut many times myself, but I no longer think it’s true". (McConnell, 1999)
•^ "The trouble is that there are important exceptions that many people do not take the time to consider when using Brooks’ law to justify something". (Berkun, 2006)
•^ "Implicit in those projects is that it applies only to the final phases of a project. The question is, How do you know whether you’re in a project’s final phases?" (McConnell, 1999)
•^ "We have found that adding people to a late project will always increase its cost, but the project may not always be late since there may be sufficient schedule to absorb them and the project may not be at maximum staffing. Only under certain degree of sequential constraints among project tasks will the project be delayed." (Hsia, Hsu, Kung, 1999)
•^ Late chaotic projects are likely to be much later than the project manager thinks--project completion isn’t three weeks away, it’s six months away. Go ahead and add staff. You’ll have time for them to become productive. Your project will still be later than your plan, but that’s not a result of Brooks’ Law. It’s a result of underestimating the project in the first place." (McConnell, 1999)
•^ "Gordon and Lamb studied Brookss Law and suggested that the best way to recover from a slipping schedule is to add more people than might be expected to be necessary, and to add them early." (Hsia, Hsu, Kung, 1999)
•^ "The law assumes that all added manpower is equal, which is not true. Given the choice of adding a good programmer, who knows the code base and is friends with half the team, I’d consider it." (Berkun, 2006)
•^ "The sad but popular approach is to throw people in without much explanation and let everyone figure it out for themselves. But if the manager clarifies why Sally and Rupert are joining, and defines good roles for them, with input from the team, they’ll be set up to make a smooth transition." (Berkun, 2006)

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 29, 2020