|Contents||Bulletin||Scripting in shell and Perl||Network troubleshooting||History||Humor|
|News||The Mythical Man-Month||Recommended Links||Real Insights into Architecture Come Only From Actual Programming||Conceptual Integrity|
Brooks's law is a principle in software development which says that "grossly simplifying, adding manpower to a late software project makes it later". It was coined by Fred Brooks in his 1975 classic The Mythical Man-Month.\
The corollary of Brooks's Law is that there is a stage of the project when incremental addition of manpower makes the situation worse intread of making it better. And it is not limited to the total time to complet the project only. Architecture is badly affected too.
Anothe variant of Brooks law is often formulated as "Nine women can't make a baby in one month".
IThe existance of Brooks Law is related to three important structural properties of large software projects:
Brooks law is not about man-month it is about complex relationship between structure of the project and structure of the team of developers involved. That's why, grossly simplifying, adding manpower to the late project is not trivial task that more often then not makes late project even more late.
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. Number of developers who are participating in given project is affected by many factors and in turn affects the architecture of the product as each developer try to carve his niche. 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.
My point here is that in no way Brooks Law is not negated by a fairy-tail about a dog and pony show project (Fetchmail) by a true believer who cannot even understand that this project should use a scripting language such as Python instead of C .
The book itself still did not lost its value due to the fact that it contains unique observations about large scale software development, the observations that can't be found anywhere else (for example, Steve McConnell is just a consultant who never headed large projects). Brooks touches things that are typical. but not highly visible in any complex engineering project. He is my compilation of key points from the book:
When you stop to think about it, this phenomenon is easy to understand. There is an inescapable overhead to yoking up programmers in parallel. The members of the team must "waste time" attending meetings, drafting project plans, exchanging EMAIL, negotiating interfaces, enduring performance reviews, and so on. In any team of more than a few people, at least one member will be dedicated to "supervising" the others, while another member will be dedicated to housekeeping functions such as managing builds, updating Gantt charts, and coordinating everyone's calendar. At Microsoft, there will be at least one team member that just designs T-shirts for the rest of the team to wear. And as the team grows, there is a combinatorial explosion such that the percentage of effort devoted to communication and administration becomes larger and larger.
Dec 26, 2016 | it.slashdot.org(threatpost.com) 148 Posted by EditorDavid on Saturday December 17, 2016 @07:34PM from the does-code-reuse-endanger-secure-software-development dept. msm1267 quotes ThreatPost: The amount of insecure software tied to reused third-party libraries and lingering in applications long after patches have been deployed is staggering. It's a habitual problem perpetuated by developers failing to vet third-party code for vulnerabilities, and some repositories taking a hands-off approach with the code they host. This scenario allows attackers to target one overlooked component flaw used in millions of applications instead of focusing on a single application security vulnerability.
The real-world consequences have been demonstrated in the past few years with the Heartbleed vulnerability in OpenSSL , Shellshock in GNU Bash , and a deserialization vulnerability exploited in a recent high-profile attack against the San Francisco Municipal Transportation Agency . These are three instances where developers reuse libraries and frameworks that contain unpatched flaws in production applications... According to security experts, the problem is two-fold. On one hand, developers use reliable code that at a later date is found to have a vulnerability. Second, insecure code is used by a developer who doesn't exercise due diligence on the software libraries used in their project.
That seems like a one-sided take, so I'm curious what Slashdot readers think. Does code reuse endanger secure software development?
Dec 26, 2016 | ask.slashdot.org(daftcode.pl) 332 Posted by EditorDavid on Sunday November 27, 2016 @11:30PM from the TDD-vs-HDD dept. marekkirejczyk , the VP of Engineering at development shop Daftcode, shares a warning about hype-driven development: Someone reads a blog post, it's trending on Twitter, and we just came back from a conference where there was a great talk about it. Soon after, the team starts using this new shiny technology (or software architecture design paradigm), but instead of going faster (as promised) and building a better product, they get into trouble . They slow down, get demotivated, have problems delivering the next working version to production.
Describing behind-schedule teams that "just need a few more days to sort it all out," he blames all the hype surrounding React.js, microservices, NoSQL, and that " Test-Driven Development Is Dead " blog post by Ruby on Rails creator David Heinemeier Hansson. ("The list goes on and on... The root of all evil seems to be social media.")
Does all this sound familiar to any Slashdot readers? Has your team ever succumbed to hype-driven development?
In Fred Brooks’ Mythical Man Month, he states:
Brooks’s Law: adding manpower to a late software project makes it later.
In the book he notes that it is an “outrageous oversimplification”, but most laws of this kind are. The trouble is that there are important exceptions that many people don’t take the time to consider when using Brooks’s law to justify something. I hinted at them in chapter 2 of The art of project management, but here’s a full explanation of the notable caveats I’ve seen.
- 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 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.
- Some teams can absorb more change than others. Some teams are more resiliant to change. They can 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).
- 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.
- 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.
- 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.
- 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.
Disclaimer: I’m sure there are specific cases where these exceptions do not apply. I am not suggesting the abandonment of Brook’s law or that religious adherence to the above. All additional examinations or applications of Brook’s law, or these exceptions, are welcome.
See also: the social contexts of open source software, from the Cathedral and the Bazaar.
Brooks looked specifically at software development projects, but I believe his conclusion holds true across all projects. With the proliferation of matrix style organizations and the lack of strategically focused planning, we’ve created a corporate culture that reacts to every crisis by sending lots of email and having lots of meetings in the hope that something positive must happen due to all this communication. The secret is, it won’t.
Lots of communication only exacerbates the problem. What we need to do is remember that communication does not solve business problems; strategic planning and productive action solves problems.
The Myth of Multitasking by Dave Crenshaw.
In his book he uses a simple example that is very convincing. Simply take a sheet of paper and draw a line across the page. Above of the line you will write the alphabet, below it the numbers 1 to 26. The kicker is that you write one letter and then one number, so you’d write ‘A’ above the line and ‘1′ below the line, then you’d write ‘B’ above the line and ‘2′ below the line, oscillating back and forth until done. Time this exercise. Next, time yourself writing just the alphabet and then just the numbers 1 to 26 in serial without switching back and forth. If you’re like most people you’ll find that it takes about twice as long to do the first exercise as it does the second. So think about that. You did the same amount of work in both cases but it took you twice as long. The only difference was context switching. Unfortunately, context switching has become the “norm” in today’s offices.
People forget that multitasking isn’t about processing information in parallel, which we just proved was impossible. Multitasking originally meant juggling or managing multiple tasks during a given period of time, not at the same time. Somehow the definition was hijacked to mean something more akin to parallel processing. Now people brag about how many conversations they can carry on at once, but based on what we now know, what they’re really saying is “Look at me, I’m getting less work done”. Probably something you don’t want your boss to know .
The other thing to remember is that every communication channel has it’s own place and purpose in the world and changing conventions can be unproductive. Email was born to replace memos and letters. No one expected you to reply to a memo or letter within minutes of it being issued. Your memos would gather in your mailbox and you’d pick them up once a day and work through the replies, just like you still pick up your mail once a day from the Post Office. What’s changed is the use paradigm and expectations. Now in this world of cell phones and computers that has people linked in everywhere, all the time, we expect immediate responses to our emails. It’s just not realistic.
In 1950 Alex Bavelas at MIT (1) was interested in the evolution of strategies and the perceptions of people with different skills that participated in group tasks. An experiment was designed where groups of participants were selectively isolated and a participative card game had to be solved:
As the figures suggest, two structures were tested, the circles represent the participants and the links represent the communication channels. The first structure, where all the participants are organized in a circular fashion was named the "democratic" structure to make emphasis on the similar status of all participants. The second structure, in form of a star, was called the "authoritarian" structure as one of it's members had communication, and therefore influence, with all the others.
In the first part of the experiment, where all the symbols in the cards were identifiable and had names, members of the authoritarian structure finished first, however they did not feel like winners, they felt they had failed and should have done much better; 94% of the team members recognized the vertex as the leader of the group. The democratic structure finished afterwards, however they were cheerful, they felt like winners,and they also stated they could have done it better; the leadership seemed to be equally distributed among them.
In the second part of the experiment a "noise" level was added by making the symbols in the cards more complex, some symbols didn't even have names to identify them. The "democrats" didn't vary much their performance, however this time the "authoritarians" didn't finish at all. Most interesting than the result is the fact that the "democratic" group extended their comunication language, inventing new names to some symbols, while the "authoritarian" group incremented the noise level by insulting each other.
This experiment is actually very interesting when we observe a similarity both in structure and results between the "democratic" structure and the BSD core teams, and the "authoritarian" structure and that of some other free software efforts.
From the above explanation, one could think that the best way to provide a stable development environment would be forming a democratic core group. This is not always true; the above results were obtained using only a small team. In bigger groups democracy almost always fails in providing the best solution to a problem. This effect was explained in 1785 by Condorcet in his famous paradox(2).
The election process is not transitive. Condorcet proposed a simple election where every voter had to elect first and second place among three options: In his example option A was the winner from the absolute majority, however by the vote distribution it was clear that if option B (the second place in absolute majority) hadn't been available, option C would have won the election over A.
In my Karate days I also experienced this non-transitiveness in a completely different situation: I won my kumite over two different contenders, they both won over a third contendor and I lost with this last guy.
Other than structure, the way resources are obtained and distributed is essential for the survival of any free software organization. The most appealing way to obtain resources is the creation of a non-profit organization, a model followed by the NetBSD Foundation and the Apache Foundation, this makes easier for companies and individuals to contribute due to the tax deduction advantages available in some countries.
Many countries, though, have little or no legal provision for this type of organizations; in those cases some companies might feel motivated to register their contribution as an operational expense in their financial state of results and while this expense will not be deducted from the taxes, no tax will be paid for it (consult your accountant if in doubt). FreeBSD Inc. is a company created to take advantage of these donations in order to provide support to the FreeBSD Project, (And of course, FreeBSD is not really a Project since it does not have a defined deadline for it's objectives...confusing heh?).
The real owners of a free software company should be their developers, this means that in order to be consistent companies that make money out of free software should pay at least part of their salaries in shares of the company.
May 2000 | DeveloperWorks
Contents: Brooks' Law Defying gravity Surgical teams Head chef Resources About the author
An aphorism from some twenty years ago, Brooks' Law, holds that adding more programmers to a project only delays it. But if this is so, what accounts for Linux? Paul Jones gathers perspectives on the open source development method and whether it defies conventional wisdom.
What a difference open source makes: it appears to break all the old rules. Or does it? With open source, so we are told, all the rules of programming, sales, marketing, and customer relations have to be rewritten. But there is evidence that beneath the rhetoric of open source, the hard school of experience casts a shadow on the most optimistic claims for open source software and open source practices. Do thousands of programmers really stand ready to write quality code to solve common problems or are there restraints inherent in development that prohibit scaling up into world-wide software projects?
Consider this story: It is the summer of 1996 and Bob Young's start up should have been further along on the development of their core product, Red Hat Linux 4.0. It was beginning to look as if the company's cash reserves would be out before the product was ready to ship.
"I started putting pressure on Marc [Ewing] and Erik [Troan] to hire some additional developers to ensure that we shipped 4.0 before the cash ran out. Marc and Erik (who were doing most of the Red Hat Linux development themselves at that time) simply refused, saying that to add developers at that stage would in fact slow down the project -- an argument that made no sense to me," recalls Young.
But Troan insisted that Young go out and buy a copy of an over twenty-year-old book about software engineering: The Mythical Man Month by Fredrick Brooks. Not so much a technical book full of charts and formulae, it is instead illustrated with reproductions of woodcuts of giant sloths stuck and sinking in deadly tar pits and photographs of ancient cathedrals.
This little book by Fredrick Brooks, The Mythical Man Month (or M3 among its most ardent followers), has become a kind of bible for software developers. Brooks received the Turing Prize, often called "the Nobel Prize of Computing," from the Association for Computing Machinery this year.
Fredrick Brooks headed the team at IBM that created the first large-scale computer operating system in the early 1960s. During his work at IBM, he realized that programmers were not like ditch diggers or house painters. Instead, he wrote, "The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures..."
Further, he defends software architects against ignorant management with Brooks' Law. "Oversimplifying outrageously, Brooks' Law [can be stated] as 'Adding manpower to a late software project makes it later.'" In other words and with mixed metaphors, art and artists cannot be rushed, and too many cooks will surely spoil the broth.
Importantly and uniquely, The Mythical Man Month and Brooks' Law are now over 25 years old. In a world in which "old" is defined in days or weeks, such longevity is nothing short of a miracle.
But proponents of open source and free software development, including Linux developers, are not completely satisfied with the Law. Most famously (among geeks at any rate), Eric Raymond in his "The Cathedral and the Bazaar," declared Brooks' Law obsolete, if not simply limited, saying "if Brooks' Law were the whole picture, Linux would be impossible."
Although Raymond now says that he has somewhat modified his views or was misunderstood, some still would say he is given to oversimplifying and outrageousness himself. "I don't consider Brooks' Law 'obsolete' any more than Newtonian physics is obsolete; it's just incomplete. Just as you get non-Newtonian effects at high energies and velocities, you get non-Brooksian effects when transaction costs go low enough. Under sufficiently extreme conditions, these secondary effects dominate the system -- you get nuclear explosions, or Linux."
But how do open source and free software efforts defy the crux of Brooks' Law, the need for small, smart groups and time flexibility for the artist/architect programmers? Perhaps by not having a schedule in the first place?
"I have yet to see an open source project commit to a schedule, and most of them don't ship anywhere near when folks think they will (some ship early, and some ship late -- it's hard to predict). I don't know how you take a rule about 'making a late project later' and apply it to development which has little formal scheduling," says Erik Troan, author of the popular Red Hat Package Manager.
The Free Software Foundation's McArthur Fellow Richard Stallman echoes Troan's sentiments. "GNU projects rarely have a schedule. When people ask me when something will be finished, I respond, 'It will be ready sooner if you help.'"
Ken Coar, member of the Apache Web Server group, will admit to having goals, but not deadlines. "Goal dates, yes -- but our release process more closely resembles the exchange between Pope Julius II and Michelangelo than a conventional software house's product development."
Yet, Coar gives himself (and us) a warning with his newly coined "Coar's Contention." "Most open-source fixes will not be proposed until a release date [for the project] is announced." In other words, deadlines do influence work and workers even in the artistically liberated world of open source.
"While the 'no deadlines' idea is not true in a general sense, we still can talk about speed of development -- just as critical a factor as deadlines. Just imagine what would happen if Linux kernel were frozen and no new version will appear until 2005!" stresses Nikolai Bezroukov of Fairleigh Dickinson University, a critic of both Stallman and Raymond.
Yet, Stallman sees projects without deadlines as a way to avoid the temptation to place untrained hands on the job at the wrong time and place. "If you don't have a deadline, you won't be likely to try to put more people on the job in that way. You will make use of more helpers only when they can actually help. Thus, I think that Brooks' Law does apply to [free software], but we have no inclination to try to violate it."
For Stallman, free software is ultimately about freedom of all sorts. "In free software projects there is usually a scarcity of resources, and no boss who can order people to do things this way instead of that way. We tend not to have too many people trying to help one project." In fact, free software -- as opposed to open source -- is not about products, per se. "In the free software movement, freedom and community are the focus. We talk about the deeper issues, such as what way of life we want."
While Raymond tells us that "the more the merrier is the rule in an open source project" and Stallman bemoans the scarcity of programmers, Jamie Zawinski, formerly of Netscape and of the Mozilla project disagrees.
"The dynamic of development inside a company is definitely different from development in an open source way. However, I don't think that saying 'adding programmers makes it later' isn't true for open source projects because of their (alleged) lack of deadlines: I think that it's true (in any sense that it is true) only because the definition of 'programmer' is slippery in that case. If you have a project that has five people who write 80% of the code, and a hundred people who have contributed bug fixes or a few hundred lines of code here and there, is that a '105-programmer project?'"
What Zawinski and others have seen is that in such undertakings as the Apache project, Linux Kernel, and other large software projects, the bulk of the work is done by a few dedicated members or a core team -- what Brooks calls a "surgical team."
"In most open source projects," says Zawinski, "there is a small group who do the majority of the work, and the other contributors are definitely at a secondary level, meaning that they don't behave as bottlenecks."
Zawinski goes on:
"Most of the larger open source projects are also fairly modular, meaning that they are really dozens of different, smaller projects. So when you claim that there are ten zillion people working on the Gnome project, you're lumping together a lot of people who never need to talk to each other, and thus, aren't getting in each others' way."
Brian Behlendorf of Apache and of Collab.net agrees.
"We don't consciously think about it, but I think that the philosophy of keeping things simple and pushing out almost anything extraneous or nonessential to external modules has been followed fairly carefully in Apache. We've also been fairly successful (I think) in 'federalizing' the Apache process to sister projects."
Bezroukov agrees that modularity is essential, but there are limits:
"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."
NNB --See more Conway's Law - Wikipedia, the free encyclopedia
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(s) that produced it.
The human wave attack -- the thousand geeks hacking through the night -- too has limits. Limits are made less painful by modularity, but that goes only so far. At some point, management, whether they are software core team leaders or CEOs, will be tempted to make the wrong decision and send in more busy little hands.
Let us now return to Bob Young and Red Hat 4.0 in 1996 as they face a cash short run, mounting deadline pressure, and an anxious Board of Directors. Should Young add more programmers in an effort to get the product out the door or should he heed what may well have been seen as a bit of techie egotism on the part of Erik Troan and just stand back and watch his software team flourish or flounder?
To try to reduce his own stress level, Bob Young went out and bought Brooks' book. "While I didn't completely buy the arguments, (I had no frame of reference)," he says , "it at least did give me a more authoritative source making the same argument that Marc and Erik were making.
"Our small development team did ship 4.0 on the schedule to which they had committed. It was a big success, and Brooks' book about Brooks' Law contributed to reducing the (already small) chance that we were going to make the mistake of adding developers at a late stage of a software project."
And even Eric Raymond has lavish praise for Brooks.
"The Mythical Man Month is still, despite time and tide, one of the most penetrating and humane books on programming ever written; every programmer and everyone who manages programmers should read it."
Fredrick Brooks himself may have the final say about how software development should be understood:
"Programming is fun because it gratifies creative longings built deep within us and delights sensibilities we have in common with all men." --NNB see Ershov
That is a happy thought that is sure to please many in the open source community.
But if this strikes too optimistic a note for some of our more skeptical readers, bear in mind that Brooks has other sweeping statements that may not soon be hailed as law by most members of the community. He concludes: "No major improvement in the software engineering area will ever appear."
Softpanorama hot topic of the month
Death march (software development) - Wikipedia, the free encyclopedia
Optimism bias - Wikipedia, the free encyclopedia
The Social Context of Open-Source Software
"“Brooks' versus Linus' Law- An Empirical" by Charles M. Schweik ...
Open Sources > The Revenge of the Hackers > Beyond Brooks's Law ...
Addendum to Brooks' Law - MindBy
Brooks' versus Linus' law
Library - Papers
Brooks's law Summary | BookRags.com
The cathedral and the bazaar- musings on Linux and Open Source by ... - Google Books Result
Exceptions to Brooks' Law « Scott Berkun
Time to Vanquish the Mythical Man Month
Open Kosmaczewski - Adding Manpower
Opening minds- Cultural change with the introduction of open ...
Linux Today - IBM developerWorks- Brooks' Law and open source- The ...
19 Eponymous Laws Of Software Development
Programming - Wikiquote
Open source and the mythical man month | ZDNet
Brooks' Law. It still applies.
Ray Kurzweil - Wikipedia, the free encyclopedia
In 1999, Kurzweil created a hedge fund called "FatKat" (Financial Accelerating Transactions from Kurzweil Adaptive Technologies), which began trading in 2006. He has stated that the ultimate aim is to improve the performance of FatKat's A.I. investment software program, enhancing its ability to recognize patterns in "currency fluctuations and stock-ownership trends." He predicted in his 1999 book, The Age of Spiritual Machines, that computers will one day prove superior to the best human financial minds at making profitable investment decisions. In 2001, Canadian rock band Our Lady Peace released an album, titled Spiritual Machines, based on Kurzweil's book. Kurzweil's voice was featured in the album, reading excerpts from his book.
In June 2005, Kurzweil introduced the "Kurzweil-National Federation of the Blind Reader" (K-NFB Reader)—a pocket-sized device consisting of a digital camera and computer unit. Like the Kurzweil Reading Machine of almost 30 years before, the K-NFB Reader is designed to aid blind people by reading written text aloud. The newer machine is portable and scans text through digital camera images, while the older machine is large and scans text through flatbed scanning.
Addendum to Brooks’ Law - MindBy
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.
This imbalance in communication node weighting should be reflected in a revised formula for group intercommunication (especially meetings). Brooks’ original formula can be stated as n(n-1)/2=communication pathways. The revised formula adds the significance of management communication to the pathways problem by accurately describing the impact of management on the original formula. This new formula can be expressed as (n(n-1/2)) ^x (^x indicates raised to the power of x) where x is the number of managers.
As an example I will restate the original example given by Brooks and then show the difference when true communication weighting has been added…
Example: 50 developers give 50 · (50 – 1) / 2 = 1225 channels of communication.
However, given our new formula and assuming the presence of 3 managers (or significant stakeholders) into our team we now see the impact of the additional management on our communication overhead.
Example: 50 developers + 3 Managers give (50 · (50 – 1) / 2)^3 = 1838265625 channels of communication.
There, that’s better. This new formula clearly shows the benefit of adding additional management resources to any project.
You can thank me later Fred
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available in our efforts to advance understanding of environmental, political, human rights, economic, democracy, scientific, and social justice issues, etc. We believe this constitutes a 'fair use' of any such copyrighted material as provided for in section 107 of the US Copyright Law. In accordance with Title 17 U.S.C. Section 107, the material on this site is distributed without profit exclusivly for research and educational purposes. If you wish to use copyrighted material from this site for purposes of your own that go beyond 'fair use', you must obtain permission from the copyright owner.
ABUSE: IPs or network segments from which we detect a stream of probes might be blocked for no less then 90 days. Multiple types of probes increase this period.
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
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
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
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
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
Copyright © 1996-2016 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License.
Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|You can use PayPal to make a contribution, supporting development of this site and speed up access. In case softpanorama.org is down you can use the at softpanorama.info|
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 author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.
Last modified: February, 21, 2017