The Mythical Man-Month – Extracts VII

Source: The Mythical Man-Month

Importance of Milestones  in Big Projects

How does one control a big project on a tight schedule? The first step is to have a schedule. Each of a list of events, called milestones, has a date. Picking the dates is an estimating problem, discussed already and crucially dependent on experience.

For picking the milestones there is only one relevant rule. Milestones must be concrete, specific, measurable events, defined with knife-edge sharpness. Coding, for a counterexample, is "90 percent finished" for half of the total coding time. Debugging is "99 percent complete" most of the time. "Planning complete" is an event one can proclaim almost at will.

Concrete milestones, on the other hand, are 100-percent events. "Specifications signed by architects and implementers," "source coding 100 percent complete, keypunched, entered into disk library," "debugged version passes all test cases." These concrete milestones demark the vague phases of planning, coding, debugging.

Two interesting studies of estimating behavior by government contractors on large-scale development projects show that:

1. Estimates of the length of an activity, made and revised carefully every two weeks before the activity starts, do not significantly change as the start time draws near, no matter how wrong they ultimately turn out to be.
2. During the activity, overestimates of duration come steadily down as the activity proceeds.
3. Underestimates do not change significantly during the activity until about three weeks before the scheduled completion.

Sharp milestones are in fact a service to the team, and one they can properly expect from a manager. The fuzzy milestone is the harder burden to live with. It is in fact a millstone that grinds down morale, for it deceives one about lost time until it is irremediable. And chronic schedule slippage is a morale-killer.

Under the rug

When a first-line manager sees his small team slipping behind, he is rarely inclined to run to the boss with this woe. The team might be able to make it up, or he should be able to invent or reorganize to solve the problem. Then why worry the boss with it? So far, so good. Solving such problems is exactly what the first-line manager is there for. And the boss does have enough real worries demanding his action that he doesn't seek others. So all the dirt gets swept under the rug.

But every boss needs two kinds of information:

• Exceptions to plan that require action and
• Status picture for education. For that purpose he needs to know the status of all his teams. Getting a true picture of that status is hard.

The first-line manager's interests and those of the boss have an inherent conflict here. The first-line manager fears that if he reports his problem, the boss will act on it. Then his action will preempt the manager's function, diminish his authority, foul up his other plans. So as long as the manager thinks he can solve it alone, he doesn't tell the boss.
Two rug-lifting techniques are open to the boss. Both must be used.

• The first is to reduce the role conflict and inspire sharing of status.
• The other is to yank the rug back.

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.