|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.
May 17, 2017 | theregister.co.ukComment "It doesn't matter whether a cat is white or black, as long as it catches mice," according to Chinese revolutionary Deng Xiaoping.
While Deng wasn't referring to anything nearly as banal as IT projects (he was of course talking about the fact it doesn't matter whether a person is a revolutionary or not, as long as he or she is efficient and capable), the same principle could apply.
A fixation on the suppliers, technology or processes ultimately doesn't matter. It's the outcomes, stupid. That might seem like a blindingly obvious point, but it's one worth repeating.
Or as someone else put it to me recently in reference to the huge overspend on a key UK programme behind courts digitisation which we recently revealed: "Who gives a toss if it's agile or not? It just needs to work."If you're going to do it do it right
I'm not dismissing the benefits of this particular methodology, but in the case of the Common Platform Programme , it feels like the misapplication of agile was worse than not doing it at all.
Just to recap: the CPP was signed off around 2013, with the intention of creating a unified platform across the criminal justice system to allow the Crown Prosecution Service and courts to more effectively manage cases.
By cutting out duplication of systems, it was hoped to save buckets of cash and make the process of case management across the criminal justice system far more efficient.
Unlike the old projects of the past, this was a great example of the government taking control and doing it themselves. Everything was going to be delivered ahead of time and under budget. Trebles all round!
But as Lucy Liu's O-Ren Ishii told Uma Thurman's character in in Kill Bill : "You didn't think it was gonna be that easy, did you?... Silly rabbit."
According to sources, alarm bells were soon raised over the project's self-styled "innovative use of agile development principles". It emerged that the programme was spending an awful lot of money for very little return. Attempts to shut it down were themselves shut down.
The programme carried on at full steam and by 2014 it was ramping up at scale. According to sources, hundreds of developers were employed on the programme at huge day rates, with large groups of so-called agile experts overseeing the various aspects of the programme.CPP cops a plea
Four years since it was first signed off and what are the things we can point to from the CPP? An online make-a-plea programme which allows people to plead guilty or not guilty to traffic offences; a digital markup tool for legal advisors to record case results in court, which is being tested by magistrates courts in Essex; and the Magistrates Rota.
Multiple insiders have said the rest that we have to show for hundreds of millions of taxpayers' cash is essentially vapourware. When programme director Loveday Ryder described the project as a "once-in-a-lifetime opportunity" to modernise the criminal justice system, it wasn't clear then that she meant the programme would itself take an actual lifetime.
Of course the definition of agile is that you are able to move quickly and easily. So some might point to the outcomes of this programme as proof that it was never really about that.
One source remarked that it really doesn't matter if you call something agile or not, "If you can replace agile with constantly talking and communicating then fine, call it agile." He also added: "This was one of the most waterfall programmes in government I've seen."
What is most worrying about this programme is it may not be an isolated example. Other organisations and departments may well be doing similar things under the guise of "agile". I'm no expert in project management, but I'm pretty sure it isn't supposed to be making it up as you go along, and constantly changing the specs and architecture.
Ultimately who cares if a programme is run via a system integrator, multiple SMEs, uses a DevOps methodology, is built in-house or deployed using off-the-shelf, as long as it delivers good value. No doubt there are good reasons for using any of those approaches in a number of different circumstances.
Government still spends an outrageous amount of money on IT, upwards of £16bn a year. So as taxpayers it's a simple case of wanting them to "show me the money". Or to misquote Deng, at least show us some more dead mice. ®
Prst. V.JeltzRe: 'What's Real and What's for Sale'...Dogbowl
So agile means "constantly adapating " ? read constantly bouncing from one fuckup to the next , paddling like hell to keep up , constantly firefighting whilst going down slowly like the titanic?
thats how i read itRe: 'What's Real and What's for Sale'...PatientOne
Ha! About 21 years back, working at Racal in Bracknell on a military radio project, we had a 'round-trip-OMT' CASE tool that did just that. It even generated documentation from the code so as you added classes and methods the CASE tool generated the design document. Also, a nightly build if it failed, would email the code author.
I have also worked on agile for UK gov projects a few years back when it was mandated for all new projects and I was at first dead keen. However, it quickly become obvious that the lack of requirements, specifications etc made testing a living nightmare. Changes asked for by the customer were grafted onto what become baroque mass of code. I can't see how Agile is a good idea except for the smallest trivial projects.Re: 'What's Real and What's for Sale'...Doctor Syntax
"Technically 'agile' just means you produce working versions frequently and iterate on that."
It's more to do with priorities: On time, on budget, to specification: Put these in the order of which you will surrender if the project hits problems.
Agile focuses on On time. What is delivered is hopefully to specification, and within budget, but one or both of those could be surrendered in order to get something out On time. It's just project management 101 with a catchy name, and in poorly managed 'agile' developments you find padding to fit the usual 60/30/10 rule. Then the management disgard the padding and insist the project can be completed in a reduced time as a result, thereby breaking the rules of 'agile' development (insisting it's on spec, under time and under budget, but it's still 'agile'...).Re: 'What's Real and What's for Sale'...Doctor Syntax
"Usually I check something(s) in every day, for the most major things it may take a week, but the goal is always to get it in and working so it can be tested."
The question is - is that for software that's still in development or software that's deployed in production? If it's the latter and your "something" just changes its data format you're going to be very unpopular with your users. And that's just for ordinary files. If it requires frequent re-orgs of an RDBMS then you'd be advised to not go near any dark alley where your DBA might be lurking.
Software works on data. If you can't get the design of that right early you're going to be carrying a lot of technical debt in terms of backward compatibility or you're going to impose serious costs on your users for repeatedly bringing existing data up to date.Re: 'What's Real and What's for Sale'...FozzyBear
"On time, on budget, to specification: Put these in the order of which you will surrender if the project hits problems."
In the real world it's more likely to be a trade-off of how much of each to surrender.Re: 'What's Real and What's for Sale'...Dagg
I was told in my earlier years by a Developer.
For any project you can have it
- Cheap, (On Budget)
- Good, (On spec)
- Quick.( On time)
Pick two of the three and only two. It doesn't which way you pick, you're fucked on the third. Doesn't matter about methodology, doesn't matter about requirements or project manglement. You are screwed on the third and the great news is, is that the level of the reaming you get scales with the size of the project.
After almost 20 years in the industry this has held true.Re: 'What's Real and What's for Sale'...Archtech
Technically 'agile' just means you produce working versions frequently and iterate on that.
No, technically agile means having no clue as to what is required and to evolve the requirements as you build. All well and good if you have a dicky little web site but if you are on a very / extremely large project with fixed time frame and fixed budget you are royally screwed trying to use agile as there is no way you can control scope.
Hell under agile no one has any idea what the scope is!Re: Government still spends an outrageous amount of money on IToldtaku
I hope you were joking. If not, try reading the classic book "The Mythical Man-Month".'Agile' means nothing at this point. Unless it means terrible software.Adrian 4
At this point, courtesy of Exxxxtr3333me Programming and its spawn, 'agile' just means 'we don't want to do any design, we don't want to do any documentation, and we don't want to do any acceptance testing because all that stuff is annoying.' Everything is 'agile', because that's the best case for terrible lazy programmers, even if they're using a completely different methodology.
I firmly believe in the basics of 'iterate working versions as often as possible'. But why sell ourselves short by calling it agile when we actually design it, document it, and use testing beyond unit tests?
Yes, yes, you can tell me what 'agile' technically means, and I know that design and documentation and QA are not excluded, but in practice even the most waterfall of waterfall call themselves agile (like Kat says), and from hard experience people who really push 'agile agile agile' as their thing are the worst of the worst terrible coders who just slam crap together with all the finesse and thoughtfulness of a Bangalore outsourcer.It's like any exciting new methodology : same shit, different name. In this case, one that allows you to pretend the tiny attention-span of a panicking project manager is a good thing.jamie m
When someone shows me they've learned the lessons of Brooke's tarpit,. I'll be interested to see how they did it. Until then, it's all talk.25% Agile:kmac499
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Working software is the primary measure of progress.Re: 25% Agile:Doctor Syntax
From Jamie M
Working software is the primary measure of progress.
Brilliant few word summary which should be scrawled on the wall of every IT project managers office in Foot High Letters.
I've lived through SSADM, RAD, DSDM, Waterfall, Bohm Spirals, Extreme Programming and probably a few others.
They are ALL variations on a theme. The only thing they have in common is the successful ones left a bunch of 0's and 1's humming away in a lump of silicon doing something useful.Re: 25% Agile:Charlie Clark
"Working software is the primary measure of progress."
What about training the existing users, having it properly documented for the users of the future, briefing support staff, having proper software documentation, or at least self documenting code, for those who will have to maintain it and ensuring it doesn't disrupt the data from the previous release? Or do we just throw code over the fence and wave goodbye to it?Re: Limits of pragmatismAnonymous Coward
In France "naviguer à vue" is pejorative.
Software development in France* which also gave us ah yes, it may work in practice but does it work in theory .
The story is about the highly unusual cost overrun of a government project. Never happened dans l'héxagone ? Because it seems to happy pretty much everywhere else with relentless monotony because politicians are fucking awful project managers.
* FWIW I have a French qualification.Anonymous Coward
Agile only works if all stakeholders agree on an outcome
For a project that is a huge change of operating your organisation it is unlikely that you will be able to deliver, at least the initial parts of your project, in an agile way. Once outcomes are known at a high level stakeholders have something to cling onto when they are asked what they need, if indeed they exist yet. (trying to ask for requirements for a stakeholder that doesn't exist yet is tough).
Different methods have their own issues, but in this case I would have expected failure to be reasonably predictable.
You wont have much to show for it, as they shouldn't at least, have started coding to a business model that itself needs defining. This is predictable, and overall means that no one agrees what the business should look like, let alone how a vendor delivered software solution should support it.
I have a limited amount of sympathy for the provider for this as it will be beyond their control (limited as they are an expensive government provider after all)
This is a disaster caused by the poor management in UKGOV and the vendor should have dropped and ran well before this.Doctor Syntax
I'm a one man, self employed business - I do some very complex sites - but if they don't work I don't get paid. If they spew ugly bugs I get paniced emails from unhappy clients.
So I test after each update and comment code and add features to make my life easy when it comes to debugging. Woo, it even send me emails for some bugs.
I'm in agreement with the guy above - a dozen devs, a page layout designer or two, some databases. One manager to co-ordinate and no bloody jargon.
There's a MASSIVE efficiency to small teams but all the members need to be on top of their game."I'm in agreement with the guy above - a dozen devs, a page layout designer or two, some databases. One manager to co-ordinate and no bloody jargon."Munchausen's proxy
Don't forget a well-defined, soluble problem. That's in your case, where you're paid by results. If you're paid by billable hours it's a positive disadvantage.Agile Expertise?Zippy's Sausage Factory
" I'm no expert in project management, but I'm pretty sure it isn't supposed to be making it up as you go along, and constantly changing the specs and architecture."
I'm no expert either, but I honestly thought that was quite literally the definition of agile. (maybe disguised with bafflegab, but semantically equivalent)Sounds like what I have said for a while...a_yank_lurker
The "strategy boutiques" saw "agile" becoming popular and they now use it as a buzzword.
These days, I put it in my "considered harmful" bucket, along with GOTO, teaching people to program using BASIC, and "upgrading" to Office 2016*.
* Excel, in particular.Buzzword BingoDoctor Syntax
All too often a sound development ideas are perverted. The concepts are sound but the mistake is to view each as the perfect panacea to produce bug free, working code. Each has its purpose and scope of effectiveness. What should be understood and applied is not a precise cookbook method but principles - Agile focuses communication between groups and ensuring all on the same page. Others focus more on low level development (test driven development, e.g.) but one can lose sight the goal is use an appropriate tool set to make sure quality code is produced. Again, is the code being tested, are the tests correct, are junior developers being mentored, are developers working together appropriately for the nature of the projects are issues to be addressed not the precise formalism of the insultants.
Uncle Bob Martin has noted that one of the problems the formalisms try to address is the large number of junior developers who need proper mentoring, training, etc. in real world situations. He noted that in the old days many IT pros were mid level professionals who wandered over to IT and many of the formalisms so beloved by the insultants were concepts they did naturally. Cross functional team meetings - check, mentor - check, use appropriate tests - check, etc. These are professional procedures common to other fields and were ingrained mindset and habits.It's worth remembering that it's the disasters that make the news. I've worked on a number of public sector projects which were successful. After a few years of operation, however, the contract period was up and the whole service put out to re-tender.* At that point someone else gets the contract so the original work on which the successful delivery was based got scrapped.goldcd
* With some very odd results, it has to be said, but that's a different story.Notas Badoff
...My personal niggle is that a team has "velocity" rather than "speed" - and that seems to be a somewhat deliberate and disingenuous selection. The team should have speed, the project ultimately a measurable velocity calculated by working out how much of the speed was wasted in the wrong/right direction.
Anyway, off to get my beauty sleep, so I can feed the backlog tomorrow with anything within my reach.Re: I like agilebfwebster
Wanted to give you an up-vote as "velocity" vs. "speed" is exactly the sleight of hand that infuriates me. We do want eventual progress achieved, as in "distance towards goal in mind", right?
Unfortunately my reading the definitions and checking around leads me to think that you've got the words 'speed' and 'velocity' reversed above. Where's that nit-picker's icon....I literally less than an hour ago gave my CS 428 ("Software Engineering") class here at Brigham Young University (Provo, Utah, USA) my final lecture for the semester, which included this slide:Pete 2
Process is not a panacea or a crutch or a silver bullet. Methodologies only work as well as the people using it. Any methodology can be distorted to give the answer that upper management wants (instead of reality)
When adopting a new methodology:
- Do one or two pilot projects
- Do one non-critical real-world project
- Then, and only then, consider using it for a critical project
Understand the strengths and weaknesses of a given methodology before starting a project with it. Also, make sure a majority of team members have successfully completed a real-world project using that methodology.Save some fun for us!
> under the guise of " agile ?". I'm no expert in project management, but I'm pretty sure it isn't supposed to be making it up as you go along, and constantly changing the specs and architecture.
So why should the developers have all the fun? Why can't the designers and architects be "agile", too? Isn't constantly changing stuff all part of the "agile" way?
Apr 20, 2017 | www.youtube.comChad 2 years agoAgent76 1 year ago (edited)
"People who believe in these rights very much are forced into compromising their integrity"
I suspect that it's hopelessly unlikely for honest people to complete the Police Academy; somewhere early on the good cops are weeded out and cannot complete training unless they compromise their integrity.January 9, 2014
500 Years of History Shows that Mass Spying Is Always Aimed at Crushing Dissent It's Never to Protect Us From Bad Guys No matter which government conducts mass surveillance, they also do it to crush dissent, and then give a false rationale for why they're doing it.
Homa Monfared 7 months ago
I am wondering how much damage your spying did to the Foreign Countries, I am wondering how you changed regimes around the world, how many refugees you helped to create around the world.
Don Kantner, 2 weeks ago
People are so worried about NSA don't be fooled that private companies are doing the same thing. Plus, the truth is if the NSA wasn't watching any fool with a computer could potentially cause an worldwide economic crisis.
Bettor in Vegas 1 year ago
In communism the people learned quick they were being watched. The reaction was not to go to protest.
Just not be productive and work the system and not listen to their crap. this is all that was required to bring them down. watching people, arresting does not do shit for their cause......
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: May, 07, 2017