Softpanorama
May the source be with you, but remember the KISS principle ;-)

Contents Bulletin Scripting in shell and Perl Network troubleshooting History Humor

Brooks Law

News The Mythical Man-Month Recommended Links Real Insights into Architecture Come Only From Actual Programming Conceptual Integrity
Reviews

Excepts

Quotes Humor Etc

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:

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:


Top updates

Softpanorama Switchboard
Softpanorama Search


NEWS CONTENTS

Old News ;-)

[Dec 26, 2016] Does Code Reuse Endanger Secure Software Development?

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: Has Your Team Ever Succumbed To Hype Driven 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?

Exceptions to Brooks’ Law by Scott Berkun

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.

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.

The Mythical 40 Hour Workweek - MindBy

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.

Productivity and Mulittasking

The human mind has limited ability to process information in parallel.
MindBy

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.

[Jun 6, 2000] Structuring and Funding Free Software Organizations

Daemon News

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.

Brooks' Law and open source: The more the merrier? Does the open source development method defy the adage about cooks in the kitchen? by Paul Jones

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.

Brooks' Law

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."

Defying gravity

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."

Surgical teams

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."

Recommended Links

Softpanorama hot topic of the month

Softpanorama Recommended

Brooks's law - Wikipedia, the free encyclopedia

Death march (software development) - Wikipedia, the free encyclopedia

Wishful thinking

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."[8] 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.

Humor

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



Etc

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.  

Society

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

Quotes

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

Bulletin:

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

History:

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

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-MonthHow 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.

The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

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

Disclaimer:

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