The Mythical Man-Month – Extracts VI

Source: The Mythical Man-Month

Communication in the Large Programming Project

Schedule disaster, functional misfits, and system bugs all arise because the left hand doesn't know what the right hand is doing. As work proceeds, the several teams slowly change the functions, sizes, and speeds of their own programs, and they explicitly or implicitly change their assumptions about the inputs available and the uses to be made of the outputs. How, then, shall teams communicate with one another? In as many ways as possible:
• Informally. Good telephone service and a clear definition of intergroup dependencies will encourage the hundreds of calls upon which common interpretation of written documents depends.
• Meetings. Regular project meetings, with one team after another giving technical briefings, are invaluable. Hundreds of minor misunderstandings get smoked out this way.
• Workbook. A formal project workbook must be started at the beginning. This deserves a section by itself.

The Project Workbook

What. The project workbook is not so much a separate document as it is a structure imposed on the documents that the project will be producing anyway.All the documents of the project need to be part of this structure.This includes objectives, external specifications, interface specifications, technical standards, internal specifications, and administrative memoranda.

Why. Technical prose is almost immortal. The early design of the project workbook ensures that the documentation structure itself is crafted, not haphazard. Moreover, the establishment of a structure molds later writing into segments that fit into that structure.The second reason for the project workbook is control of the distribution of information. The problem is not to restrict information, but to ensure that relevant information gets to all the people who need it.

Organization in the Large Programming Project

If there are n workers on a project, there are (n2-n)/2 interfaces across which there may be communication, and there are potentially almost 2" teams within which coordination must occur. The purpose of organization is to reduce the amount of communication and coordination necessary; hence organization is a radical attack on the communication problems treated above.

The means by which communication is obviated are division of labor and specialization of function. The tree-like structure of organizations reflects the diminishing need for detailed communication when division and specialization of labor are applied.

In fact, a tree organization really arises as a structure of authority and responsibility. The principle that no man can serve two masters dictates that the authority structure be tree-like. But the communication structure is not so restricted, and the tree is a barely passable approximation to the communication structure, which is a network. The inadequacies of the tree approximation give rise to staff groups, task forces, committees, and even the matrix-type organization used in many engineering laboratories.

Let us consider a tree-like programming organization, and examine the essentials which any subtree must have in order to be effective. They are:
1. a mission
2. a producer
3. a technical director or architect
4. a schedule
5. a division of labor
6. interface definitions among the parts

All of this is obvious and conventional except the distinction between the producer and the technical director. Let us first consider the two roles, then their relationship.

What is the role of the producer?

He assembles the team, divides the work, and establishes the schedule. He acquires and keeps on acquiring the necessary resources. This means that a major part of his role is communication outside the team, upwards and sideways. He establishes the pattern of communication and reporting within the team. Finally, he ensures that the schedule is met, shifting resources and organization to respond to changing circumstances.

How about the technical director?

He conceives of the design to be built, identifies its subparts, specifies how it will look from outside, and sketches its internal structure. He provides unity and conceptual integrity to the whole design; thus he serves as a limit on system complexity. As individual technical problems arise, he invents solutions for them or shifts the system design as required. His communications are chiefly within the team. His work is almost completely technical.

Now it is clear that the talents required for these two roles are quite different. Talents come in many different combinations; and the particular combination embodied in the producer and the director must govern the relationship between them. Organizations must be designed around the people available; not people fitted into pure-theory organizations.

Three relationships are possible, and all three are found in successful practice, and they are:

• The producer and the technical director may be the same man.
• The producer may be boss, the director his right-hand man.
• The director may be boss, and the producer his right-hand man.

JavaScript II - Expressions and Operators

About Arrays, Objects and Functions

Object Creation Expressions

new Object()
new Point(2,3)

If no arguments are passed to the constructor function in an object creation expression, the empty pair of parentheses can be omitted:

new Object
new Date

Object and Array Initializers

Object and array initializers are expressions whose value is a newly created object or array.

var arrayOfArrays = [[1,2], [3]];
var obj = { x:1, y:’otv’}; // Object with 2 properties

Property Access Expressions

Two syntaxes for property access:

var obj = {x:5,y:2};
obj.x;    // 5 expression.identifier
obj['y']; // 2 expression [ expression ]

Function Definition Expressions

var duplicate = function(x){return x*2;}; // Function definition
duplicate(2);

Operators

Operator	Description	Input	Output
void	Return undefined value	any	undef
*, /, %	Multiply, divide, remainder	num,num	num
delete	Unary operator that attempts to delete the object property or array element specified as its operand // Deleting object properties var obj = {x:1,y:2}; obj.x; //Before deleting property value=1 delete obj.x; obj.x; //After deleting property value:undefined // Deleting array elements var array = [10,20]; array.length; // 2 array[0]; // 10 delete array[0];// true array.length; // 2 array[0]; // undefined Not all properties can be deleted, however: some built-in core and client-side properties are immune from deletion, and user-defined variables declared with the var statement cannot be deleted. Functions defined with the function statement and declared function parameters cannot be deleted either.	property or array element	bool
typeof	Determine type of operand. var trueTypeOf = typeof true; // “boolean” The following table specifies the value of the typeof operator for any JavaScript value: Parameter Return undefined "undefined" null "object" true or false "boolean" any number or NaN "number" any string "string" any function "function" any nonfunction native object "object" any host object An implementation-defined string, but not “undefined”, “boolean”, “number”, or “string”.	any	str
in	Test whether property exists.It evaluates to true if the left-side value is the name of a property of the right-side object. For example: var person = { name:’Bob’, address:’Marylan’}; // Define an object "name" in person // true: object has property named "name" "toString" in person// true: object inherits toString method var data = [10,20]; // An array with elements 0 and 1 "0" in data // true: array has an element "0" 5 in data // false: no element 5	str,obj	bool
instanceof	Test object class. It expects a left-side operand that is an object and a right-side operand that identifies a class of objects. The operator evaluates to true if the left-side object is an instance of the right-side class and evaluates to false otherwise. Take into account that in JavaScript, classes of objects are defined by the constructor function that initializes them. Thus, the right-side operand of instanceof should be a function.Examples: var currentDate = new Date(); // Create a new object with the Date() constructor currentDate instanceof Date; // true currentDate was created with Date() currentDate instanceof Object; // true all objects are instances of Object currentDate instanceof Number; // false currentDate is not a Number object	obj,func	bool
==	Test for equality using a more relaxed definition of sameness that allows type conversions.	any,any	bool
!=	Test for inequality	any,any	bool
===	Test for strict equality. Known as the strict equality operator (or sometimes the identity operator), and it checks whether its two operands are “identical” using a strict definition of sameness (does not perform type conversion)	any,any	bool
!==	Test for strict inequality	any,any	bool
?	Ternary operator. Example: var name = 10>5?'Ten':'Five'; // ‘Ten’
eval	It expects one argument. If you pass any value other than a string, it simply returns that value. If you pass a string, it attempts to parse the string as JavaScript code, throwing a SyntaxError if it fails. If it successfully parses the string, then it evaluates the code and returns the value of the last expression or statement in the string or undefined if the last expression or statement had no value. If the string throws an exception, the eval() propagates that expression. eval("x=100") //change local variable eval("function localFunction() { return x*2; }"); //define local function

The Mythical Man-Month – Extracts V

Source: The Mythical Man-Month

Ensuring that everyone hears, understands, and implements the architects' decisions

A whole technology for doing this was worked out for the System/360 hardware design effort, and it is equally applicable to software projects.

Written Specifications—the Manual

The manual, or written specification, is a necessary tool, though not a sufficient one. The manual is the external specification of the product.

It describes and prescribes every detail of what the user sees. As such, it is the chief product of the architect. It must also refrain from describing what the user does not see. That is the implementer's business, and there his design freedom must be unconstrained.

The style must be precise, full, and accurately detailed. A user will often refer to a single definition, so each one must repeat all the essentials and yet all must agree. This tends to make manuals dull reading, but precision is more important than liveliness.

Formal Definitions

English, or any other human language, is not naturally a precision instrument for such definitions. Therefore the manual writer must strain himself and his language to achieve the precision needed. An attractive alternative is to use a formal notation for such definitions, but it also has its weaknesses so I think we will see future specifications to consist of both a formal definition and a prose definition.

If one has both, one must be the standard, and the other must be a derivative description, clearly labeled as such. Either can be the primary standard.

Direct Incorporation

A lovely technique for disseminating and enforcing definitions is available for the software system architect. It is especially useful for establishing the syntax, if not the semantics, of inter-module
interfaces. This technique is to design the declaration of the passed parameters or shared storage, and to require the implementations to include that declaration via a compile-time operation (a macro
or a % INCLUDE in PL/I). If, in addition, the whole interface is referenced only by symbolic names, the declaration can be changed by adding or inserting new variables with only recompilation, not alteration, of the using program.

Conferences and Courts

Needless to say, meetings are necessary. The hundreds of man-to-man consultations must be supplemented by larger and more formal gatherings. We found two levels of these to be useful.

The first is a weekly half-day conference of all the architects, plus official representatives of the hardware and software implementers, and the market planners. The chief system architect presides. Anyone can propose problems or changes, but proposals are usually distributed in writing before the meeting. A new problem is usually discussed a while. The emphasis is on creativity, rather than merely decision. The group attempts to invent many solutions to problems, then a few solutions are passed to one or more of the architects for detailing into precisely worded manual change proposals.

Detailed change proposals then come up for decisions. These have been circulated and carefully considered by implementers and users, and the pros and cons are well delineated. If a consensus emerges, well and good. If not, the chief architect decides. Minutes are kept and decisions are formally, promptly, and widely disseminated.

Decisions from the weekly conferences give quick results and allow work to proceed. If anyone is too unhappy, instant appeals to the project manager are possible, but this happens very rarely.The fruitfulness of these meetings springs from several sources:

• The same group—architects, users, and implementers—meets weekly for months. No time is needed for bringing people up to date.
• The group is bright, resourceful, well versed in the issues, and deeply involved in the outcome. No one has an "advisory" role. Everyone is authorized to make binding commitments.
• When problems are raised, solutions are sought both within and outside the obvious boundaries.
• The formality of written proposals focuses attention, forces decision, and avoids committee-drafted inconsistencies.
• The clear vesting of decision-making power in the chief architect avoids compromise and delay.

As time goes by, some decisions don't wear well. Some minor matters have never been wholeheartedly accepted by one or another of the participants. Other decisions have developed unforeseen problems, and sometimes the weekly meeting didn't agree to reconsider these. So there builds up a backlog of minor appeals, open issues, or disgruntlements. To settle these we held annual supreme court sessions, lasting typically two weeks. (I would hold them every six months if I were doing it again.)

These sessions were held just before major freeze dates for the manual. Those present included not only the architecture group and the programmers' and implementers' architectural representatives, but also the managers of programming, marketing, and implementation efforts. The project manager presided. The agenda typically consisted of about 200 items, mostly minor, which were enumerated in charts placarded around the room. All sides were heard and decisions made. By the miracle of computerized text editing (and lots of fine staff work), each participant found an updated manual, embodying yesterday's decisions, at his seat every morning.
These "fall festivals" were useful not only for resolving decisions, but also for getting them accepted. Everyone was heard, everyone participated, everyone understood better the intricate constraints and interrelationships among decisions.

The Telephone Log

As implementation proceeds, countless questions of architectural interpretation arise, no matter how precise the specification. Obviously many such questions require amplifications and clarifications in the text. Others merely reflect misunderstandings. It is essential, however, to encourage the puzzled implementer to telephone the responsible architect and ask his question, rather than to guess and proceed. It is just as vital to recognize that the answers to such questions are ex cathedra architectural pronouncements that must be told to everyone.
One useful mechanism is a telephone log kept by the architect. In it he records every question and every answer. Each week the logs of the several architects are concatenated, reproduced, and distributed to the users and implementers. While this mechanism is quite informal, it is both quick and comprehensive.

Product Test

The project manager's best friend is his daily adversary, the independent product-testing organization. This group checks machines and programs against specifications and serves as a devil's advocate, pinpointing every conceivable defect and discrepancy. Every development organization needs such an independent technical auditing group to keep it honest. In the last analysis the customer is the independent auditor.

The Mythical Man-Month – Extracts IV

Source: The Mythical Man-Month

Architect - Needed Disciplines

Having in mind that we have separated responsibility for functional specification (Architect) from responsibility for building a fast, cheap product (Builder), now we have to answer the question of: how we will achieve the best outcome of our project? The fundamental answer is thoroughgoing, careful, and sympathetic communication between architect and builder.

Nevertheless there are little details that must to be observed for the Architect in order to get the ideal result, and these are:

Interactive Discipline

The architect has two possible answers when confronted with an estimate that is too high: cut the design or challenge the estimate by suggesting cheaper implementations. This latter is inherently an emotion-generating activity. The architect is now challenging the builder's way of doing the builder's job. For it to be successful, the architect must:

• Remember that the builder has the inventive and creative responsibility for the implementation; so the architect suggests, not dictates;
• Always be prepared to suggest a way of implementing anything he specifies, and be prepared to accept any other way that meets the objectives as well;
• Deal quietly and privately in such suggestions;
• Be ready to forego credit for suggested improvements.

Normally the builder will counter by suggesting changes to the architecture. Often he is right—some minor feature may have unexpectedly large costs when the implementation is worked out.

Self-Discipline—The Second-System Effect

An architect's first work is apt to be spare and clean. He knows he doesn't know what he's doing, so he does it carefully and with great restraint.

As he designs the first work, frill after frill and embellishment after embellishment occur to him. These get stored away to he used "next time." Sooner or later the first system is finished, and the architect, with firm, confidence and a demonstrated mastery of that class of systems, is ready to build a second system.

This second is the most dangerous system a man ever designs. The general tendency is:

• To over-design the second system, using all the ideas and frills that were cautiously sidetracked on the first one.
• Tendency to refine techniques whose very existence has been made obsolete by changes in basic system assumptions.

How does the architect avoid the second-system effect? Well, obviously he can't skip his second system. But he can be conscious of the peculiar hazards of that system, and exert extra self-discipline to avoid functional ornamentation and to avoid extrapolation of functions that are obviated by changes in assumptions and purposes.

JavaScript I - Initial Concepts

Basic Information

• JavaScript is a case-sensitive language. Many client-side JavaScript objects and properties have the same names as the HTML tags and attributes they represent. While these tags and attribute names can be typed in any case in HTML, in JavaScript they typically must be all lowercase.
• JavaScript’s strings (and its arrays) use zero-based indexing.
• When the JavaScript interpreter starts, it creates a new global object that has: Properties like undefined, Infinity, and NaN , Functions like isNaN(), parseInt(), and eval(), Constructor functions like Date(), RegExp(), String(), Object(), and Array() and Global objects like Math and JSON.

In client-side JavaScript, the Window object serves as the global object for all JavaScript code contained in the browser window it represents. This global Window object has a self-referential window property that can be used instead of this to refer to the global object.

Primitive values

Primitives are immutable: there is no way to change (or “mutate”) a primitive value. Primitives are also compared by value: two values are the same only if they have the same value. The primitive values are:

• Numbers, strings, or booleans.
• null and undefined.

Numbers

Arithmetic in JavaScript does not raise errors in cases of overflow, underflow, or division by zero. Check the following table:

Case	Result
Overflow	It could be either:Infinity or -Infinity
Infinity as one operand	It could be either:Infinity or -Infinity
Division by Zero	It could be either:Infinity or -Infinity
0/0	NaN

For more complex mathematical operations check the Math object.

Boolean values

The Boolean values are: true and false, aside of that when a value different from boolean has to be converted to one JavaScript  converts it to true or false base on the following table:

Values	Convert to
undefined, null, 0, –0, NaN, ""	false
All other values, including all objects (and arrays)	true

null and undefined

Both does not neither properties nor methods and indicate an absence of value. Comparing both using “==” we will get “true”

	null	undefined
Description	It is a language keyword	It is the value of variables that have not been initialized. The value you get when you query the value of an object property or array element that does not exist. It is also returned by functions that have no return value, and the value of function parameters for which no argument is supplied.
Represent	Program-level, normal, or expected absence of value	system-level, unexpected, or error-like absence of value
typeof	"object"	"undefined"

Object

It is a collection of properties where each property has a name and a value. an unordered collection of named values. It is mutable.

Objects are not compared by value, are compared by reference: two object values are the same if and only if they refer to the same underlying object. Core JavaScript defines the following useful classes.

Name	Definition
Array	Represents an ordered collection of numbered values.
Function	A function is an object that has executable code associated with it.
Date	Defines objects that represent dates.
RegExp	Defines objects that represent regular expressions.
Error	Defines objects that represent syntax and runtime errors that can occur in a JavaScript program.

The Mythical Man-Month – Extracts III

Source: The Mythical Man-Month

Conceptual Integrity

I will contend that conceptual integrity is the most important consideration in system design. It is better to have a system omit certain anomalous features and improvements, but to reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas. Unfortunately most programming systems reflect big conceptual disunity. Usually this arises not from a serial succession of master designers, but from the separation of design into many tasks done by many men.

Taking into account that the purpose of a programming system is to make a computer easy to use, the ratio of function to conceptual complexity is the ultimate test of system design. Neither function alone nor simplicity alone defines a good design.

Simplicity and straightforwardness proceed from conceptual integrity. Every part must reflect the same philosophies and the same balancing of desiderata. Every part must even use the same techniques in syntax and analogous notions in semantics. Ease of use, then, dictates unity of design, conceptual integrity.

How to get conceptual integrity ?

Conceptual integrity dictates that the design must proceed from one mind, or from a very small number of agreeing resonant minds. Schedule pressures, however, dictate that system building needs many hands. Two techniques are available for resolving this dilemma:

• The first is a careful division of labor between architecture and implementation.
• The second is the new way of structuring programming implementation teams such as surgical team.

Separation of labor between architecture and implementation.

It is a very powerful way of getting conceptual integrity on very large projects.
By the architecture of a system, I mean the complete and detailed specification of the user interface. For a computer this is the programming manual. For a compiler it is the language manual. For a control program it is the manuals for the language or languages used to invoke its functions. For the entire system it is the union of the manuals the user must consult to do his entire job.

The architect of a system, like the architect of a building, is the user's agent. It is his job to bring professional and technical knowledge to bear in the unalloyed interest of the user, as opposed to the interests of the salesman, the fabricator, etc.

Architecture must be carefully distinguished from implementation. As Blaauw has said, "Where architecture tells what happens, implementation tells how it is made to happen."

Objections to this technique

This is criticized with the following questions:

Are not the architects a new aristocracy, an intellectual elite, set up to tell the poor dumb implementers what to do?

The answer to this must be yes and no.
Yes, in the sense that there must be few architects, their product must endure longer than that of an implementer, and the architect sits at the focus of forces which he must ultimately resolve in the user's interest. If a system is to have conceptual integrity, someone must control the concepts. That is an aristocracy that needs no apology.

No, because the setting of external specifications is not more creative work than the designing of implementations. It is just different creative work. The design of an implementation, given an architecture, requires and allows as much design creativity, as many new ideas, and as much technical brilliance as the design of the external specifications. Indeed, the cost-performance ratio of the product will depend most heavily on the implementer, just as ease of use depends most heavily on the architect.

Has not all the creative work been sequestered for this elite, leaving the implementers as cogs in the machine?

Similarly, I observe that the external provision of an architecture enhances, not cramps, the creative style of an implementing group. They focus at once on the part of the problem no one has addressed, and inventions begin to flow. In an unconstrained implementing group, most thought and debate goes into architectural decisions, and implementation proper gets short shrift.

Won't one get a better product by getting the good ideas from all the team, following a democratic philosophy, rather than by restricting the development of specifications to a few?

I will certainly not contend that only the architects will have good architectural ideas. Often the fresh concept does come from an implementer or from a user. However, all my own experience convinces me, and I have tried to show, that the conceptual integrity of a system determines its ease of use. Good features and ideas that do not integrate with a system's basic concepts are best left out. If there appear many such important but incompatible ideas, one scraps the whole system and starts again on an integrated system with different basic concepts.

The Mythical Man-Month – Extracts II

Source: The Mythical Man-Month

How to take forward really big projects

Small sharp team concept is not a viable solution because it is too slow. So we have to find other options.

The dilemma

For efficiency and conceptual integrity, one prefers a few good minds doing design and construction.
For large systems one wants a way to bring considerable manpower to bear, so that the product can make a timely appearance.
So how can these two needs be reconciled?

Harlan Mills's Proposal

Mills proposes that each segment of a large job be tackled by a team, but that the team be organized like a surgical team and not a hog-butchering team.

Surgical team

One does the cutting and the others give him every support that will enhance his effectiveness and productivity.

Hog-butchering team

Each member cutting away on the problem.

Surgical Team - Roles and work division

The following are the roles of 10 people that contribute in well differentiated and specialized roles on a programming team built on the surgical model:

The surgeon

Mills calls him a chief programmer. He needs great talent, ten years experience, and considerable systems and application knowledge, whether in applied mathematics, business data handling, or whatever.

His main responsibilities are:

• Defines the functional and performance specifications .
• Designs, codes  and tests the program.
• Writes its documentation.

He needs to have effective access to a computing system which not only runs his tests but also stores the various versions of his programs, allows easy file updating, and provides text editing for his documentation.

The copilot

He is the alter ego of the surgeon, able to do any part of the job, but is less experienced.
His main responsibilities are:

• Shares in the design as a thinker, discussant, and evaluator. The surgeon tries ideas on him, but is not bound by his advice.
• Knows all the code intimately.
• Researches alternative design strategies.

He may even write code, but he is not responsible for any part of the code.

The administrator.

The surgeon is boss, and he must have the last word on personnel, raises, space, and so on, but he must spend almost none of his time on these matters. Thus he needs a professional administrator who handles money, people, space, and machines, and who interfaces with the administrative machinery of the rest of the organization. He can serve two teams.

The editor.

The surgeon is responsible for generating the documentation; for maximum clarity he must write it. This is true of both external and internal descriptions.

The editor, however, takes the draft or dictated manuscript produced by the surgeon and criticizes it, reworks it, provides it with references and bibliography, nurses it through several versions, and oversees the mechanics of production.

Two secretaries.

The administrator and the editor will each need a secretary; the administrator's secretary will handle project correspondence and non-product files.

The program clerk.

He is responsible for maintaining all the technical records of the team in a programming-product library.
The clerk is trained as a secretary and has responsibility for both machine-readable and human-readable files.

All computer input goes to the clerk, who logs and keys it if required. The output listings go back to him to be filed and indexed. The most recent runs of any model are kept in a status notebook; all previous ones are filed in a chronological archive.

The specialized function of the program clerk relieves programmers of clerical chores, systematizes and ensures proper performance of those oft-neglected chores, and enhances the team's most valuable asset—its work-product.

The toolsmith.

File-editing, text-editing, and interactive debugging services are now readily available, so that a team will rarely need its own machine and machine-operating crew.

But these services must be available with unquestionably satisfactory response and reliability; and the surgeon must be sole judge of the adequacy of the service available to him. He needs a toolsmith, responsible for ensuring this adequacy of the basic service and for constructing, maintaining, and upgrading special tools—mostly interactive computer services—needed by his team.

His job is to see to the tools needed or wanted by his surgeon, without regard to any other team's needs. The tool-builder will often construct specialized utilities, catalogued procedures, macro libraries.

The tester.

The surgeon will need a bank of suitable test cases for testing pieces of his work as he writes it, and then for testing the whole thing.  The tester is therefore both an adversary who devises system test cases from the functional specs, and an assistant who devises test data for the day-by-day debugging. He would also plan testing sequences and set up the scaffolding required for component tests.

The language lawyer.

By the time Algol came along, people began to recognize that most computer installations have one or two people who delight in mastery of the intricacies of a programming language. And these experts turn out to be very useful and very widely consulted. The talent here is rather different from that of the surgeon, who is primarily a system designer and who thinks representations. The language lawyer can a neat and efficient way to use the language to do difficult, obscure, or tricky things.

Often he will need to do small studies (two or three days) on good technique. One language lawyer can service two or three surgeons.

How It Works

The team just defined meets the desiderata in several ways.
Ten people, seven of them professionals, are at work on the problem, but the system is the product of one mind—or at most two, acting uno animo.

Notice in particular the differences between a team of two programmers conventionally organized and the surgeon-copilot team.

• First, in the conventional team the partners divide the work, and each is responsible for design and implementation of part of the work.
  In the surgical team, the surgeon and copilot are each cognizant of all of the design and all of the code. This saves the labor of allocating space, disk accesses, etc. It also ensures the conceptual integrity of the work.
• Second, in the conventional team the partners are equal, and the inevitable differences of judgment must be talked out or compromised.Since the work and resources are divided, the differences in judgment are confined to overall strategy and interfacing, but they are compounded by differences of interest—e.g., whose space will be used for a buffer. In the surgical team, there are no differences of interest, and differences of judgment are settled by the surgeon unilaterally.

These two differences—lack of division of the problem and the superior-subordinate relationship—make it possible for the surgical team to act uno animo. Yet the specialization of function of the remainder of the team is the key to its efficiency, for it permits a radically simpler communication pattern among the members.

The Mythical Man-Month – Extracts I

Source: The Mythical Man-Month

Identifying the joys and woes inherent to the system programming.

The Joys of the Craft

Following we can find some answers to the questions:  Why is programming fun? What delights may its practitioner expect as his reward?

• The sheer joy of making things.
• The pleasure of making things that are useful to other people.
• The fascination of fashioning complex puzzle-like objects of interlocking moving parts and watching them work in subtle cycles, playing out the consequences of principles built in from the beginning.
• The joy of always learning, which springs from the nonrepeating nature of the task.
• The delight of working in such a tractable medium. The programmer, like the poet, works only slightly removed from pure thought-stuff.

The Woes of the Craft

• One must perform perfectly.
• Other people set one's objectives, provide one's resources, and furnish one's information. One rarely controls the circumstances of his work, or even its goal.
• Designing grand concepts is fun; finding nitty little bugs is just work. With any creative activity come dreary hours of tedious, painstaking labor, and programming is no exception.
• One finds that debugging has a linear convergence, or worse, where one somehow expects a quadratic sort of approach to the end. So testing drags on and on, the last difficult bugs taking more time to find than the first.
• The product over which one has labored so long appears to be obsolete upon (or before) completion.
  

Why more software projects have gone awry for lack of calendar time?

• Our techniques of estimating are poorly developed.
• Our estimating techniques fallaciously confuse effort with progress.
• Because we are uncertain of our estimates.
• Schedule progress is poorly monitored. Techniques proven and routine in other engineering disciplines are considered radical innovations in software engineering.
• When schedule slippage is recognized, the natural (and traditional) response is to add manpower. Like dousing a fire with gasoline, this makes matters worse, much worse.

About creative activity

Dorothy Sayers, in her excellent book, The Mind of the Maker, divides creative activity into three stages:

The idea,

A book, then, or a computer, or a program comes into existence first as an ideal construct, built outside time and space, but complete in the mind of the author.

The implementation,

It is realized in time and space, by pen, ink, and paper, or by wire, silicon, and ferrite.

The interaction.

The creation is complete when someone reads the book, uses the computer, or runs the program, thereby interacting with the mind of the maker.

Demythologizing of the man-month.

The number of months of a project depends upon its sequential constraints. The maximum number of men depends upon the number of independent subtasks. From these two quantities one can derive schedules using fewer men and more months. (The only risk is product obsolescence.)

Ideas into Words – Extracts III

Source: Ideas into Words

Refining Your Draft

Before you start refining, do whatever will freshen your view of the manuscript. At a minimum, take a break and print out the manuscript.  After your break, proceed as if you had never seen the manuscript before. The idea is to approximate an outsider’s clear view of the piece as it stands. Next do the following things:

Read at cruising speed  and jot down your reactions

Read at cruising speed, like any other reader, but jot down your reactions in the border. Note that word—your reactions, not fixes. Keep moving, reserving your attention for the text and your own reactions. You want to notice every slightest flicker of boredom, impatience, confusion, put-off-ness, or pleasure. Do you have an impulse to skim? To jump ahead? To laugh? Are you working hard? Is your mind wandering? Make a quick note and keep moving. Write barely enough that you’ll know what you meant, along these lines:

• Waiting for story to start. What’s this about? . . .
• Bored . . .
• Woke up here, comp. lab busy at midnight a good touch
• LOL [laughed out loud] . . .
• Skimming, impatient . . .

Read the text out loud, or at least murmur it to yourself, lips moving, in order to spotlight any awkward patches.
Noting positive reactions is a must, and not only to preserve morale. Most of us tend to think of editing as “fixing” what is off. We forget the other half of the job, and maybe the more important half—retaining and strengthening what is good. The better to retain it, mark it.

Check the structure

In editing, your initial concern should be structural.  Aim to strengthen and balance the whole. Sweep through from beginning to end, again and again, solving the problems that your reactions pinpoint—first the big ones, then small ones.

About the opener

• Do you actually have an opener? Or were you merely clearing your throat? Initial reactions like “Bored” and “What’s this about?” are ominous.
• Does the opener still match the story as it turned out to be? Does the piece deliver on its promise?

About the closer

• Do you actually have a closer? Between fatigue and a desire to be done, you may have simply stopped without telling the reader good-bye.

Check your marks and examples

• Take a look at the passages you marked as any variant of “boring.” Do you want or need the material?
• Is the passage boring only because it is unclear? Most things seem boring when we don’t understand them.
• Do your examples demonstrate what you say they do? Bad examples sometimes survive from before you had total command of the subject, or because you found them charming.

Check the shape

• How’s the shape? As a whole, does the piece flow? Is it beginning to seem inevitable, as if the segments could never have been in any other order?
• Only with all big pieces in place should you go ahead to polish your writing, a process not unlike that of a plastic surgeon treating an aging movie star: you work all over.
• Take into account that :
  - Leading edge of a paragraph must be used to direct or redirect the reader’s attention.
  - Last part of a paragraph must be used to  emphasize something, the place that gives the reader her final impression (and perhaps a millisecond longer of brain time). Last place gives you a way to spotlight particular words and ideas that are critical to later understanding or that have important resonance.
  - Middle of the sentence must be used to de-emphasize something.

Follow the basic rules

• Replace passive verbs with active ones,
• Take out the garbage words—at least, most of them. By “garbage words,” I mean puny all-purpose modifiers such as very, really, rather, sort of, kind of, somewhat, quite, absolutely, extremely, and on and on.
• Take out redundant qualifiers
• When in doubt, throw it out.
• Your subconscious is your friend. If your subconscious made you do something, ask yourself why

Ideas into Words – Extracts II

Source : Ideas into Words

Creating your first draft

Following you can find some advices to create your first draft

As you write, keep your eye on the ball

I borrowed the sporty image in this mixaphor, hackneyed though it is, because in sports we all know it’s true (which is how it got hackneyed). It is hard enough to hit a tennis ball streaking toward you at 118 miles an hour. It cannot be done by a person who is preoccupied with losing, or his appearance, or anything else.

Your initial effort needs to be more or less continuous

Meaning day after day, as in all the arts. An artist friend often quotes her painting teacher on that subject: “You must. . . go . . . to the studio,” her teacher would say, slowly and with emphasis. “Once you are there, you might spend all morning sweeping the floor. That doesn’t matter. What matters is that you must . . . go . . . to the studio.”Yes, master, I hear you. “What am I really trying to say?” is a near-magic question.

Write out loud, mumbling or whispering to yourself as you write

Because reading is processed in the speech centers of the brain, any sentence or paragraph that is hard to speak will be hard to read, period. Not a lot harder, of course—but 1 percent improvements have a way of adding up, and this particular habit may be a 2 to 5 percenter.

Polish your prose late in the process rather than early

The more you work on a piece, the deeper it burrows into your neural pathways, and the harder you will struggle to see it freshly. The more effort you invest, the more every word will seem precious near  impossible to change.

Consider starting a bone heap

A place at the end of the manuscript for discarded sentences and paragraphs that you might yet want—dead examples, for example, or an aside that grew so big it disrupted the train of thought. The trouble with these items is that one gets attached to them, having invested the labor to create them. Hence the value of the bone heap: Knowing you can always retrieve that little gem, you’ll find it easy to be ruthless. An example is not quite working? Out!

Write with your notes and references open.

As a creative person, no matter how well you understand the subject, you need the constraints of genuine facts and quotes. Otherwise, you are likely to improve the stories and ideas past recognition. Use your notes. As a boss of mine used to say, “I don’t have time to take shortcuts.”

Make sure you put in all your raisins (i.e., fun facts, great quotes, and interesting comparisons).

Have you ever eaten a bread pudding that had too many raisins? I can’t imagine such a thing, and so it is with writing. You may not be able to turn a brilliant phrase yourself, but if you can recognize brilliant material when you see it, you can come close to a brilliant effect.

Take chances.

A draft is only a draft—by definition, the right place to experiment. Try writing lushly, or speaking more directly to the readers, or whatever you want to try. You will find the edge of the cliff, the place where you’ve gone too far, only by going over. Then once you’ve found the lip, you can stay two paces back.

Write using active verbs

Just as you were taught in high school English. Sentence by sentence, focus on action (which does what to what) rather than “procedures are” or “the data show that.”

Explain as needed

Not sooner and not later, not more and not less. If the article’s structure is right, the subject will unfurl like a morning glory, example/case and explanations inextricably mingled. Avoid any long patches of bald theory.

Keep the reader with you

Joined at the hip, by putting up a little slalom flag every time your train of thought takes a swerve or detour. A word or phrase will do it, of which our language has hundreds

Ideas into Words – Extracts I

Source: Ideas into Words

Main Advice

Whenever you get stuck while writing, stop struggling. Close your eyes, visualize a specific, living, breathing reader, and say to yourself, “What am I really trying to say?” Whatever the answer, write it down. Polish later if it’s needed, but you may be surprised at how trivial the polishing can be.

Getting Started

The first things that you have to do are:

Think about the readers.

Readers come in clusters. There is never only one, though one will be central. When you write, you will address that key reader directly, thereby rousing your social skills. The other readers will listen in and benefit from the occasional aside (or joke, or whatever) that you tuck in for their benefit.
From that viewpoint, your goal in writing is to capture and serve as many different readers as possible, yet stay focused on the core concern shared by the subgroups. You directly address the key reader, offering 100 percent of what that person needs. Then you throw the others a bone whenever one comes to hand.
As you start to think through a piece, imagine yourself as each reader in turn:

• Who are these people?
• What does each one need and expect from you?
• What will each group want to know?

If you meet one particular reader completely, will that do most of the job for the others? Yes, that’s the primary one, the reader. Knowing the reader early on will help you decide how to approach your article, and later it will help you choose vocabulary, examples, and analogies.

Think about the subject matter and mark your material for use in writing.

With your reader(s) held in mind, review all your notes and printed matter so that all is fresh in your mind, seen as a whole. If you are writing a brief news item, such a review may take fifteen minutes. For a major feature, it may take several days.

Write a head and subhead

Good ones, not perfunctory. The process will force you to get precise about both topic and approach.
As a unit, the heads have two jobs:

• To lure the readers in and
• To constitute a fair billing.

Consider pheromones, the chemical signals with which animals (including us) attract mates—moth pheromone does nothing for rutting bucks and vice versa. In the same way, the allure of your headline should speak specifically to the right readers, the cluster of people you are talking to.

Make a plan

Following the advice once given by Alexandre Dumas père for three-act plays:

• The beginning (first act) should be clear, clear, clear;
• The middle (second act) should be interesting, interesting, interesting;
• And the end should be short, short, short.

Your written plan may be very simple, especially for something short:

• Head and subhead,
• Idea for the opener,
• Idea for the closer,
• Plus a list of three to five major points you want to make in between.

Structure your piece in such a way that, when your train of thought comes to an end, its caboose just happens—of course not, but it should feel that way, natural and inevitable— to be a good place to leave the reader. That place might be a scene, a new insight, a question, or simply a final image that encapsulates the major idea. Often, the conclusion enlarges the picture, and it may well bear on the reader’s eternal question, why anyone should care. 

If the grand finale of your article is clear to you but the structure is not, try a more “logical” approach:  Start your plan from the end. Whatever your grand finale, back up. Ask yourself, what does the reader need to know to really get this final part? Good. That material belongs in the penultimate section. And so on. Just keep backing up toward your opener till you get there (or perhaps to a better one yet).A shape should then be apparent—or at any rate present, even if you don’t yet see it.

The Clean Coder–Extracts

Source: The Clean Coder: A Code of Conduct for Professional Programmers

About software projects

The fundamental assumption underlying all software projects is that software is easy to change.If you violate this assumption by creating inflexible structures, then you undercut the economic model that the entire industry is based on.

Professionals spend time caring for their profession.

You should plan on working 60 hours per week. The first 40 are for your employer. The remaining 20 are for you. During this remaining 20 hours you should be reading, practicing, learning, and otherwise enhancing your career.

Presumably you became a software developer because you are passionate about software and your desire to be a professional is motivated by that passion. During that 20 hours you should be doing those things that reinforce that passion. Those 20 hours should be fun!

Professionals practice.

True professionals work hard to keep their skills sharp and ready. It is not enough to simply do your daily job and call that practice. Doing your daily job is performance, not practice. Practice is when you specifically exercise your skills outside of the performance of your job for the sole purpose of refining and enhancing those skills.

Team Player

We’ve all heard how important it is to be a “team player.” Being a team player means playing your position as well as you possibly can, and helping out your teammates when they get into a jam. A team-player communicates frequently, keeps an eye out for his or her teammates, and executes his or her own responsibilities as well as possible.

Test Automation Pyramid

The kinds of tests that a professional development organization needs are:

Unit Tests

At the bottom of the pyramid are the unit tests. These tests are written by programmers, for programmers, in the programming language of the system.
The intent of these tests is to specify the system at the lowest level. Developers write these tests before writing production code as a way to specify what they are about to write. They are executed as part of Continuous Integration to ensure that the intent of the programmers’ is upheld.

Component Tests

Generally they are written against individual components of the system. The components of the system encapsulate the business rules, so the tests for those components are the acceptance tests for those business rules. It passes input data into the component and gathers output data from it. It tests that the output matches the input. Any other system components are decoupled from the test using appropriate mocking and test-doubling techniques.

Component tests cover roughly half the system. They are directed more towards happy-path situations and very obvious corner, boundary, and alternate-path cases. The vast majority of unhappy-path cases are covered by unit tests and are meaningless at the level of component tests

Integration Tests

These tests only have meaning for larger systems that have many components. These tests assemble groups of components and test how well they communicate with each other. The other components of the
system are decoupled as usual with appropriate mocks and test-doubles.

Integration tests are choreography tests. They do not test business rules. Rather, they test how well the assembly of components dances together. They are plumbing tests that make sure that the components are properly connected and can clearly communicate with each other.

System Tests

These are automated tests that execute against the entire integrated system. They are the ultimate integration tests. They do not test business rules directly. Rather, they test that the system has been wired together correctly and its parts interoperate according to plan. We would expect to see throughput and performance tests in this suite.

Manual Exploratory Tests

This is where humans put their hands on the keyboards and their eyes on the screens. These tests are not automated, nor are they scripted. The intent of these tests is to explore the system for unexpected behaviors while confirming expected behaviors. Toward that end we need human brains, with human creativity, working to investigate and explore the system. Creating a written test plan for this kind of testing defeats the purpose.

Quotes

“Only connect!... Only connect the prose and the passion, and both will be exalted, and human love will be seen at its height.” - E. M. Forster

"Man can be destroyed, but not defeated" – Hemingway

"Living a life of defeat is death and a death with dignity is life."

"All happy families resemble each other, but each unhappy family is unhappy in its own way." – Tolstoy

“Curiosity, happens when we feel a gap in our knowledge.”

Points to take into account to prepare a presentation

Source: Confessions of a Public Speaker

1.- Take a strong position in the title.

All talks and presentations have a point of view, and you need to know what yours is. If you don’t know enough about the topic to have an opinion, solve that problem before you make your presentation. Even saying, “Here are five things I like” is a strong position, in that there are an infinite number of things you did not choose. With a weak position, your talk may become, “Here is everything I know I could cram into the time I have, but since I have no idea if you care, or what I would say if I had less time to talk, you get a half-baked, hard to follow, hard to present, pile of trash.”

2.- Think carefully about your specific audience.

Know why they are there, what their needs are, what background knowledge they have, the pet theories they believe in, and how they hope their world will be different after your lecture is over. If you don’t have time to study your subject, at least study your audience. It may turn out that as little as you know about a subject, you know more about it than your audience.

3.- Make your specific points as concise as possible.

If it takes 10 minutes to explain what your point is, something is very wrong. Points are claims. Arguments are what you do to support your points. Every point should be compressed into a single, tight, interesting sentence. The arguments might be long, but no one should ever be confused as to what your point is while you are arguing it. A mediocre presentation makes the points clear but muddles or bores people with the arguments. A truly bad presentation never clarifies what the points are.

4. Know the likely counterarguments from an intelligent, expert audience.

If you do not know the intelligent counterarguments to each of your points, your points cannot be good. For example, if your presentation is about why people should eat more cheese, you should at a minimum know why the Anti-Cheese Foundation of America says people should eat less cheese.

Quotes

"I tell you that whether you fear it or not, disappointment will come.  The beauty is that through disappointment you can gain clarity, and with clarity comes conviction and true Originality" - Conan O'Brien

About thinks of our own nature

A zen student came to Bankei and said: 'Master, I have an ungovernable temper -- how can i cure it?' Show me this temper, said Bankei, 'it sounds fascinating.' 'I haven't got it right now,' said the student, 'so I can't show it to you.' 'well then,' said Bankei, 'Bring it to me when you have it.' 'but I can't bring it just when I happen to have it,' protested the student. 'it arises unexpectedly, and I would surely lose it before I got it to you.'

In that case, said Bankei, 'it cannot be part of your true nature. if it were, you could show it to me at any time. when you were born you did not have it, and your parents did not give it to you -- so it must come into you from the outside. I suggest that whenever it gets into you, you beat yourself with a stick until the temper can't stand it, and runs away.

Emptiness

When Yamaoka was a brash student he visited the master Dokuon. Wanting to impress the master he said: 'There is no mind, there is no body, there is no Buddha. there is no better, there is no worse. there is no master, there is no student. there is no giving, there is no receiving. what we think we see and feel is not real. none of these seeming things really exists.'

Dokuon had been sitting quietly smoking his pipe, and saying nothing. suddenly he picked up his staff and gave Yamaoka a terrible whack. Yamaoka jumped up in anger. Dokuon said: 'since none of these things really exists, and all is emptiness, where does your anger come from? think about it.'

Quotes

"The path of learning: The apprentice figths to dominate the sword, the expert dominates it and the master merges with it" - Nibor

Nothing exists except in its relationship of subjectivity and objectivity.

Indian Story

In the Hindu heaven, there is a tree called 'Kalptaru.' It means the wish-fulfilling tree. By accident a traveler arrived there and he was so tired that he sat under the tree. And he was hungry so he thought, 'If
somebody was here, I would ask for food. But there seems to be nobody.' The moment the idea of food appeared in his mind, food suddenly appeared and he was so hungry that he didn't bother to think about it. He ate it.

Then he started feeling sleepy, and he thought, 'If there was a bed here....' And the bed appeared. But lying on the bed the thought arose in him, 'What is happening? I don't see anybody here. Food has come, a bed has come -- maybe there are ghosts doing Things to me!' Suddenly ghosts appeared.. Then he became afraid and he thought, 'Now they will kill me!' And they killed him!

In life the law is the same: if you think of ghosts, they are bound to appear. Think and you will see. If you think of enemies, you will create them; if you think of friends, they will appear. If you love, love appears all around you; if you hate, hate appears. Whatsoever you go on thinking is being fulfilled by a certain law.

If you don't think anything, then nothing happens to you

Jokes from Osho books

It was after the last war and a journalist was interviewing the Reverend Mother of a convent in Europe.
'Tell me,' said the journalist, 'what happened to you and your nuns during those terrible years? How did you survive?'

'Well, first of all,' said the Reverend Mother, 'the Germans invaded our country, seized the convent, raped all the nuns -- except sister Anastasia -- took our food and left. Then came the Russians. Again they seized the convent, raped all the nuns -- except Sister Anastasia -- took our food and left. Then again the Russians were driven out and the Germans came back again, seized the convent, raped all the nuns --except Sister Anastasia -- took our food and left.'
The journalist made the required sympathetic noises, but was curious about Sister Anastasia. 'Who is this Sister Anastasia?' he asked. 'Why did she escape these terrible happenings?'
'Ah, well,' replied the Reverend Mother, 'Sister Anastasia does not like that kind of thing.'

Software Quotes

“There are two ways of constructing a software design:
One way is to make it so simple that there are obviously no deficiencies
and the other is to make it so complicated that there are no obvious deficiencies.” - Tony Hoare, 1991 Turing Award Lecture.

"A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away." – Antoine de Saint-Exupery

“Ingenuity is often misunderstood. It is not a matter of superior intelligence but of character. It demands more than anything a willingness to recognize failure, to not paper over the cracks, and to change. It arises from deliberate, even obsessive, reflection on failure and a constant searching for new solutions.” - Atul Gawande, Better

“Software is not a product, it’s a medium for storing knowledge. Therefore, software development is not a product producing activity, it is a knowledge acquiring activity. Knowledge is just the other side of the coin of ignorance, therefore software development is an ignorance-reduction activity.” - Phillip Armour

Quotes

“There is nothing either good or bad, but thinking makes it so.” – Hamlet

“Fortiter in re, suaviter in modo“ - (Be tough in your aims, but smooth in the way you put them into practice).

"Living a life of defeat is death and a death with dignity is life."

“For every step you take toward mastery, your destination moves two steps further away. Embrace mastery as a lifelong endeavor. Learn to love the journey.”  - George Leonard, Mastery

"Seduced by the siren song of a consumerist, quick-fix society, we sometimes choose a course of action that brings only the illusion of accomplishment, the shadow of satisfaction" - George Leonard, Mastery

Jokes from Osho books

Once it happened, a friend of Mulla Nasruddin was talking to Mulla Nasruddin. They had met after many -- years. Both were bitter rivals; both were poets. Both started to boast about the progress they had made in their careers. 'You have no idea, Nasruddin, how many people read my poetry now,' bragged the friend. 'My readers have doubled.' 'My God, my God!' cried Nasruddin. 'I had no idea you got married!'

Enlightenment vs Ego

Whenever there is a conflict, the tension arises and the ego exists;' when there is no conflict the tension disappears and the ego disappears. Ego is not a thing -- it is just a tension.

The ego needs some problems. If you understand this, in the very understanding the mountains become molehills again, and then the molehills also disappear. Suddenly there is emptiness, pure emptiness all around. This is what enlightenment is all about -- a deep understanding that there is no problem.

Start living this moment and you will see that the more you live, the less problems there are. Because now that your emptiness is flowering and living there is no need. When you don't live, the same energy goes sour. The same energy which would have become a flower, is stuck; not being allowed to bloom it becomes a thorn in the heart. It is the same energy.

If you live, ego disappears. Life knows no ego, it knows only living and living and living. Life knows no self, no center; life knows no separation.

Awareness

You learn all kinds of things in life except the one thing which can transform you, and that is the art of awareness.

If you want to see, see right at once. When you begin to think, you miss the point.

The East knows how to just sit in silence, without agreeing or disagreeing, because we have discovered one fundamental thing: that truth is already inside you. If you hear the truth from the outside your truth will be awakened, it will be provoked. Suddenly you will say "Yes!" -- as if you had known it already. It is a recognition, it is a remembrance.

The Master speaks not to give you the truth, but to help you to recognize the truth that is already within you. The Master is only a mirror. You see your own original face in deep silence, sitting by his side.

About Zen

ZEN IS NOT INTERESTED IN ANSWERS -- or in questions. It is not interested in teaching at all. It is not a philosophy; it is a totally different way of looking at things, at life, at existence, at oneself, at others. Yes, it is a discipline.

Discipline simply means a methodology of becoming more centered, of becoming more alert, of becoming more aware, of bringing more meditativeness to your being; not functioning through the head, not even through the heart, but functioning from the very core of your being, from the very innermost core, from the center of your being, from your totality. It is not a reaction -- reaction comes from the past -- it is a response. Response is always IN the present, TO the present.

Zen gives you a discipline to become a mirror so that you can reflect that which is. All that is needed is a thoughtless awareness.

Zen is absolutely a treatment. It is the greatest treatment that has come to humanity, out of the work of thousands of enlightened people – very refined. It can help to open up your eyes. It can help you to feel again, to be sensitive to the reality. It can give you eyes and ears. It can give you a soul. But it is not interested in answers.

Zen is not a teaching, because it knows you are asleep. The primary thing is not to teach you; the primary thing is to wake you up. Zen is an alarm.

Jokes from Osho books

"Daddy, what is diplomacy?" asked little Bill, just home from school. "Well, son, it is like this," replied his dad. "If I were to say to your mother, 'Your face would stop a clock,' that would be stupidity. But if I were to say, 'When I look at you, time stands still,' that is diplomacy!"

A man went to a psychiatrist and said, "Doctor, you will have to help me. I can't help thinking that I am a dog. I even chew bones, bark, and lie on the mat in the evenings." Said the psychiatrist, "Just lie on that couch...." "I am not allowed to!" he cried.

To be master of your minds

Meditation makes you a master and the mind becomes a slave. And remember: the mind as a master is dangerous because, after all, it is a machine; but the mind as a slave is tremendously significant, useful. A machine should function as a machine, not as a master. Our priorities are all upside-down – your CONSCIOUSNESS should be the master.

Remember that you are part of the whole so that you can relax, merge; once in a while you can be utterly drowned in the whole. And that will give you a new lease of life. The inexhaustible sources of the whole will become available to you. You will come out of it refreshed; you will come out of it reborn, again as a child, full of joy, inquiry, adventure, ecstasy.

Right now my consciousness is flowing through the mind, using the mechanism of the mind to approach you. I can reach for you with my hand, but I am not the hand. And when I touch you with my hand, the hand is only a means; something else is touching you through the hand. The body has to be used, the mind has to be used, the ego, the language, and all kinds of things have to be used. And you are allowed to use them with only one condition: remain the master.

Never take anything for granted! Each moment you have to conquer it again and again. Life is a continuous conquest. It is not that once and for all it is settled and then you can fall asleep and stay unconscious and there is no worry left. Again you will be back in the same rut.

An intelligent person does not function out of his past experience; he functions in the present. He does not react, he responds. Hence he is always unpredictable; one can never be certain what he is going to do.

About Zen

Zen lives in the present. The whole teaching is: how to be in the present, how to get out of the past which is no more and how not to get involved in the future which is not yet, and just to be rooted, centered, in that which is.

Truth cannot be given; it is already in you. It can be called forth, it can be provoked. A context can be created, a certain space can be created in which it rises in you and is no more asleep, becomes awakened.

The function of the Master is far more complex than you think. It would have been far easier, simpler, if truth could be conveyed. It cannot be conveyed, hence indirect ways and means have to be devised.

Masters don't teach the truth; there is no way to teach it. It is a transmission beyond scriptures, beyond words. It is a transmission. It is energy provoking energy in you. It is a kind of synchronicity.

The Master liberates you from words, he liberates you from all kinds of imaginative philosophies. He brings you to a state of wordless silence. The failure of religion and philosophy is that they all become substitutes for real experience. Beware of it!

Zen cures you of your abnormality. It makes you again normal, it makes you again ordinary. It does not make you a saint, remember. It does not make you a holy person, remember. It simply makes you an ordinary person -- takes you back to your nature, back to your source.

Jokes From Osho books

"Whisky and whisky alone is responsible for your deplorable condition!" the judge admonished the drunken prisoner, who was a professor -- maybe a professor of psychology. "Glad to hear you say that, judge," beamed the drunk. "My wife says it's all my fault!"

A backwoods preacher was exhorting his followers about sin and morality. Finally he demanded, "I want every virgin in this congregation to stand up!" Nobody moved. Again he shouted, "Every virgin in this congregation, rise!" Finally a woman with an infant in her arms got up. "Didn't you hear me, woman?" yelled the preacher. "I said the virgins!" Replied the woman, "How do you expect a three-month old baby to get up by herself?"

A habitual drunk staggered up to the front door of a home late one night, and kept rapping loudly until a lady in pyjamas came to answer.
"Par'n me, ma'am," he lushes, "this is an emergency. Can you tell me where Mulla Nasrudin lives?"
"Why," she exclaimed, "you are Mulla Nasrudin yourself!"
"I know, I know," he replied, "but that still doesn't answer the question -- where does he live?"

Mulla Nasrudin was talking to a woman and saying great things, was getting very romantic. He was saying, "Your eyes -- never, never have they happened before. And your face -- it is just like the moon. And
the glow that surrounds you, and the vibe that you create -- it is the most beautiful thing that has ever happened." And he went on and on. And, of course, as women are very practical, the woman asked, "Are you going to marry me, Nasrudin?" Nasrudin said, "Please, don't change the subject!"

Being oneself

When you are not trying to become anybody else, then you simply relax -- then a grace arises. Then you are full of grandeur, splendor, harmony -- because then there is no conflict! nowhere to go, nothing to fight for; nothing to force, enforce upon yourself violently. You become innocent.

Just be yourself and remember you cannot be anything else, whatsoever you do. All effort is futile. You have to be just yourself.

A perfect man is a meeting of heaven and earth. That's what a perfect man is: meeting of the physical and the spiritual, meeting of the body and the soul, meeting of the world and renunciation, meeting of prose and poetry.

It is easy to become part of the society and get into the rut; it is difficult to get of it. And once you are in the rut, you start becoming afraid: What will happen if you get out of it.J You will lose money, you will lose this, you will lose that. But you are losing your life all the time!

Your live only belongs to you

Nobody else can decide for you. All their commandments, all their orders, all their moralities, are just to kill you. You have to decide for yourself. You have to take your life in your own hands. Otherwise, life goes on knocking at your door and you are never there -- you are always somewhere else.

You have to drop all those patterns that have been forced on you, and you have to find your own inner
flame.

One of the basic truths of life -- that which you have learnt can be unlearnt. That which you have learnt from others is nothing natural to you: you can erase it. Just a conscious awareness is needed; it can be erased and the slate can become clean again.

IT IS very easy to follow your parents, it is very easy to follow your teachers, it is very easy to follow the society, it is very easy to be obedient -- to be rebellious, to be on your own, is very difficult. But growth comes the hard way.

Life is possible only through challenges. Life is possible only when you have both good weather and
bad weather, when you have both pleasure and pain, when you have both winter and summer, day and night. When you have both sadness and happiness, discomfort and comfort. Life moves between these two polarities. Moving between these two polarities you learn how to balance. Between these two wings you learn how to fly to the farthest star.

Be an individual and pay for it. In fact, if you get something without paying for it, don't accept it – that is insulting to you. DON'T accept it; that is below you.

When you have felt and sensed your destiny, you see only your destiny.

Responsibility means freedom.

It is you in the final analysis, always you, the decisive factor, who decide whatsoever happens to you. Remember it. This is the very key. If you are unhappy, it is you. If you are not living rightly, it is you. If you are missing, it is you. The responsibility is totally yours. Don't be afraid of this responsibility.

It is good to help people; it is good to help them grow. Just one thing remember always: Don't help them just to be normal -- help them to grow; help them to become unique. Don't help them to become normal! Normal, they will be just part of a collectivity. Help them to become individuals. Help them to become rare, unique. Enjoy it!

About Consciousness

When you remember your self, you forget God; when you forget your self, you remember God.

First step is receptivity, because in receptivity ego cannot exist -- it can exist only in conflict. And when you are receptive, suddenly your faculty of imagination becomes tremendously powerful.

Once you have dropped the ego you have dropped all defeat, all failure, all frustration. Carry the ego and you are doomed to failure. Carry the ego and you will remain weak. Drop the ego and infinite strength starts flowing through you. By dropping the ego you become a river, you start flowing, you start melting, you start streaming -- you become alive.

By listening, by becoming receptive, one became imaginative.

Doing all without Ego

• You can succeed only with God, never against Him. You can succeed only with the Whole, never against It. So if you are frustrated, in deep misery, remember: you are creating that misery. And you are creating it by a subtle trick: you are fighting against the Whole.
• Try to make something perfect and it will remain imperfect. Do it naturally and it is always perfect. Nature is perfect; effort is imperfect. So whenever you are doing something too much, you are destroying.
• I am just myself. And I have no interpretation about myself, and there is no need. I am simply
  delighted in being myself! -- whatsoever that means. I am happy in being myself

Quotes

• Love is very accepting and very understanding
• Die for something is better than live for nothing
• The eternal is true. The temporal is untrue. Both are real. The accidental is also real and the essential is
  also real, but with the accidental you will remain in misery. And with the essential the doors of bliss open,
  the doors of satchitanand -- of truth, of consciousness, of bliss.
• Each man comes into this world with a specific destiny -- he has something to fulfill, some message has to be delivered, some work has to be completed. You are not here accidentally, you are here meaningfully.
  There is a purpose behind you. The Whole intends to do something through you.
• When you are aware, you are not in need of love. When you are not in need of love, you become capable of love. This is the paradox. When you are in need you are not capable.
• If you know exactly what you want, you only see that. Concentration comes easy.
  If you know exactly what you want, then the whole life and the whole world goes on its own way – you don't see it even. You go like an arrow You are not distracted.
• Once you accept the reality, you are relieved, released; the prison exists no more.

Whole philosophy of the religious man

I have nothing to do -- just to celebrate, let
things happen to me; just to dance and sing.' It does not mean that a religious man becomes inactive. No. He becomes more active, but in his action there is no effort, there is no strain, there is no violence. It is not that he becomes inactive, dull, lethargic. No. He radiates with energy, he overflows with energy, because all that energy that was being wasted in effort is no longer wasted. He has too much of it -- he can share. But now he functions as a vehicle. Now he has given his whole energy to the Whole. Now, wherever the Whole takes him, he goes. Now he is with the Whole and not against it.