Key Papers in Computer Science

Key Papers in Computer Science
Software Engineering Yuriy Arbitman

the mythical man-month
Essays on Software Engineering Frederick P. Brooks, Jr.

About the Author Frederick Phillips Brooks, Jr. Born in 1931
Ph.D. in CS from Harvard, 1956 Between 1956 and 1965 worked in IBM, was project manager of IBM’s System/360 computers and OS/360 development. In 1964 founded CS Department at the University of North Carolina, chaired it for 20 years. In 1999 received the Turing Award “for landmark contributions to computer architecture, operating systems, and software engineering”.

The Book (1) The Tar Pit The Mythical Man-Month The Surgical Team
Aristocracy, Democracy, and System Design The Second-System Effect Passing the Word Why Did the Tower of Babel Fail? Calling the Shot Ten Pounds in a Five-Pound Sack The Documentary Hypothesis Plan to Throw One Away Sharp Tools

The Book (2) The Whole and the Parts Hatching a Catastrophe
The Other Face No Silver Bullet – Essence and Accident in Software Engineering “No Silver Bullet” Refired Propositions of The Mythical Man-Month: True or False? The Mythical Man-Month after 20 years Fifty Years of Wonder, Excitement and Joy (Epilogue)

A Programming System Product
The Tar Pit (1) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Large-system programming is a tar pit in the last decade. The programming systems product: A Program A Programming Product A Programming System A Programming System Product

The Tar Pit (2) A Programming System:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 A Program A Programming Product: can be run, tested, repaired and extended by anybody general enough well documented A Programming System: collection of interacting programs precisely defined interfaces between individual programs comply with resource limitations all combinations tested A Programming System Product: both Programming System and Programming Product x3

The Tar Pit (3) The joys of the craft: The woes of the craft:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 The joys of the craft: Making things Making things that are useful to others The fascination of fashioning complex puzzle-like objects Always learning Such a tractable medium The woes of the craft: Adjusting to the requirement of perfection Other people tell you what to do Worse: must use others’ programs!

The Tar Pit (4) The woes of the craft (cont.): Bugs!!!
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 The woes of the craft (cont.): Bugs!!! Bugs get harder as testing progresses The product gets obsolete upon or even before completion

The Mythical Man-Month (1)
2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Most software projects are late. Why? Assumption that all will go well led the schedule plan Confuse effort with progress: men and months are NOT interchangeable! Software managers tend to please their managers and because of uncertainty of programmers’ time estimates, plan the schedule poorly [as a discipline we lack estimating data]. Poor monitoring of project progress Natural response to schedule slippage is adding manpower, which makes matters worse.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Optimism: All programmers are optimists, believing in happy endings and fairy god-mothers. Because programming tasks are usually chained end-to-end, the probability that each will go well is very small. Man-month: Cost vary as a product: men · months. Progress does not: communication overhead! Overhead: intercommunication and training.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Different projects types: Men Months Perfectly partitionable task Unpartitionable task Partitionable task requiring communication Task with complex interrelationships

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Proposes a successfull rule of thumb: 1/3 planning 1/6 coding 1/4 component test and early system test 1/4 system test, all components in hand Gutless estimating, or: an omelette example Regenerative schedule disaster: An example Brook’s Law: Adding manpower to a late software project makes it later.

The Surgical Team (1) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 The problem: productivity varies hugely between good programmers and poor ones. Mill’s proposal: divide large job into segments, each tackled by a surgical team: The surgeon. The chief programmer. Defines spec, designs, codes, tests, documents. The boss. The copilot. Less experienced, no responsibility for code. The administrator. Handles money, people, space, machines. May be part-time (serve two teams). The editor. Improves and perfects the Factor of 10 (!), at same training and two-year experience level. Sackman, Grant, and Erickson's data showed no correlation whatsoever between experience and performance. Brooks doubts the universality of that result.

The Surgical Team (2) documentation produced by the surgeon.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 documentation produced by the surgeon. Two secretaries. One for the administrator and one for the editor. The program clerk. Responsible for maintaining all the technical records of the team in a programming-product indexed library. The toolsmith . The system manager of the team. The tester. Responsible for producing or gathering the test-cases. “The adversary”. The language lawyer. Master of the used programming language. Can serve two or three teams [surgeons].

The Surgical Team (3) Surgeon Co-pilot Administrator Programming clerk
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Surgeon Co-pilot Programming clerk Toolsmith Tester Language lawyer Administrator Secretary Editor

Aristocracy, Democracy and System Design
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Conceptual integrity is the most important consideration in system design. The ratio of function to conceptual complexity [user-side] is the ultimate test of system design. Measures ease of use, valid over both simple and difficult users. Simplicity is not enough. Straightforwardness is required. To achieve it, a design must proceed from one mind (or small group of agreeing minds). Aristocracy vs. Democracy [Architecture vs. Implementation]: Blaauw: “Where architecture tells what happens, implementation tells how it is made to happen”. This separation is very important

The Second-System Effect (1)
2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 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 be 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.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 This second is the most dangerous system a man ever designs. When he does his third and later ones, his prior experiences will confirm each other as to the general characteristics of such systems, and their differences will identify those parts of his experience that are particular and not generalizable. The general tendency is to over-design the second system, using all the ideas and frills that were cautiously sidetracked on the first one.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Solutions: Obviously, an architect cannot skip his second system  He must be conscious of the dangers, avoiding functional ornamenation and extrapolation of functionality. Brooks advises to assign each little function a value, like: capability x is worth not more than m bytes of memory and n microseconds per invocation. Project manager can avoid the danger by insisting on a senior architect who designed at least two systems.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 An architect can successfully influence implementation: creative responsibility is builder’s, the architect only suggests don’t look for credit while suggesting improvements listen to builder’s suggestions Windows NT as a 1990’s example

Passing the Word (1) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 The problem: How do we [the manager] ensure that everyone understand and implement the architects’ decisions? How a group of 10 architects achieve conceptual integrity in a system being built by 1000 men? Solutions: Written specification – the manual: necessary tool; includes dated versions. Simulator or previous version may serve as a formal definition. [Advantages, disadvantages] In other words, how to achieve that conceptual integrity that was stated to be so important in the previous chapters, and how to ensure the proper distinction between design and implementation?

Passing the Word (2) Meetings - two levels:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Meetings - two levels: Weekly half-day conference: architects, official representative(s) of implementers, market planners, chief architect presides. The emphasis is on creativity, rather than merely decision. Annual / half-year session of two weeks (held just before major freeze dates for the manual). Include also managers of programming. System project manager presides. All decisions are distibuted immediately after the meetings. Telephone log of questions from implementers to the architects, distributed each week to everybody. Tests!!!

Passing the Word (3) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Even in large teams writing must be done by no more than two people Formal vs. prose definition: standard and derivative.

Why Did the Tower of Babel Fail? (1)
2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 The moral: clear mission, enough manpower, good materials, enough time and adequate technology DO NOT suffice for a project to succeed. In this case: lack of communication and its consequent, organization. Bad communication in software projects are the root of all evil. How shall teams communicate with each other? In as many ways as possible: Informally,

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Meetings, and by maintaining a formal project workbook. The project workbook: Not a separate document, but rather a structure of such. Includes objectives, external specs, interfaces specs, technical standards, internal specs and administrative memoranda. Brooks describes a detailed fashion of managing and defining the workbook. Today it is much easier to develop a satisfiable mechanism for managing such workbook. Totally public / structured publicity (argument with Parnas)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 The essentials of tree-like programming organization: a mission a producer a technical director (architect) a schedule a division of labor interface definitions among the parts Brooks stresses the distinction between the producer and the technical director:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 The producer: assembles the team divides the work establishes the schedule takes care of the necessary resources establishes the pattern of communication and reporting within the team ensures the schedule is met The technical director: Resposible for the design Provides conceptual integrity Invent solutions for problems that arise

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Possible relations between the two: The producer and the technical director may be the same man: Works with very small teams, 3-6 programmers. In larger projects will not work: a man with the needed talents is rarely found, each role is a full-time job. The producer is the boss, the director his right-hand man: Difficulty: establishing the director’s authority This solution is rarely tried

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 The director is the boss, the producer his right-hand man: Best for small teams (as discussed in “The Surgical Team” chapter)

Calling the Shot 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 How to estimate the expected time and effort it will take to build a system? To estimate only the coding portion and apply the ratios may lead to ridiculous results. Nanus and Farr’s study: effort = constant X (number of instructions)1.5 Portman’s data: only 50% of working week was realized as actual programming and debugging time (meetings, unrelated jobs, paperwork, etc.). There are big differences in productivity related to the compexity of the task: Operating systems, compilers, normal batch application programs – factor of 3 between each, respectively.

Ten Pounds in a Five-Pound Sack
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Program space as cost – much less relevant today Resident size Disk accesses More function means more space, speed being held constant. Time-space trade-off

The Documentary Hypothesis (1)
2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 The hypothesis: Amid a wash of paper, a small number of documents become the critical pivots around which every project's management revolves. These are the manager's chief personal tools. Brooks suggests the critical documents are: Objectives Specifications (the last finished document!) Schedule Budget Organization chart

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Space allocations Estimate, forecast, prices: Forecast Estimate Prices The similarity to university department: as to any management task. Conway’s Law: “Organizations which design systems are constrained to produce systems which are copies of the communication structures of these organizations”.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Why have formal documents? writing down decisions is essential (focuses thought and crystallizes discussion) the documents will communicate the decisions to others database and checklist for the manager only a small part of a technical project manager's time (20%) is spent on tasks where he needs information from outside his head

Plan to Throw One Away (1)
2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 In most projects, the first system built is barely usable. It may be: too slow too big awkward to use or all three  The management question is not whether to build a pilot system and throw it away, but whether to deliver the throwaway to customers.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Delivering that throwaway buys time, but…: agony for the user distraction for the builders while they do the redesign bad reputation for the product that the best redesign will find hard to live down So: be prepared for a change as a way of life. Plan the system for change: careful modularization extensive subroutining

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 precise and complete definition of intermodule interfaces complete documentation of these quantization of change: numbered versions and clear policy regarding versions’ releases. Plan the organization for change: Keep managers and technical people as interchangeable as their talents allow: job titles, dual ladder of advancement, corresponding salary scales, corresponding prestige, “reassignment” vs. “promotion” Corresponding salaries: easy. Corresponding prestige: hard, requires proactive measures to fight sociological barriers. Constructing a surgical team is a radical attack and long-run answer to the problem of flexible organization.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Maintenance: Total cost is 40% or more of the development, but strongly affected by the number of users. Bug occurance as a function of release age Months since installation Bugs found per month The fundamental problem: fixing a defect has a 20%-50% chance of introducing another. So the whole process is “two steps forward and one step back”.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 “One step forward and one step back”: Number of modules increase linearly, but number of modules affected increase exponentially. Less and less effort is spent to fix initial design flaws, more and more to fix previous fixes. Today: beta version (vs. alpha version) Beta: a pilot system for field tests. Alpha: a prototype with limited function. Brooks advocates the use of alpha also.

Sharp Tools - Skipped 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

The Whole and the Parts 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Many failures origin in poor definition of requirements Long before implementation, specification must be tested for completeness and clarity. Top-down design – the advantages Structured programming (today: OOP?) Debugging: Debug each component separately at first Don’t follow the “documented bug” approach White-box testing by using dummy components Add one component at a time Plan the debugging part carefully Niklaus Wirth "Program development by stepwise refinement“ 1971 – introduced top-down design. Swiss computer scientist, chief designer of Algol W, Pascal, Modula and Modula2.

Hatching a Catastrophe (1)
2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 “How does a project get to be a year late? Day-by-day slippage is harder to recognize, harder to prevent, harder to make up. Milestones must be concrete, specific, measurable events, defined with knife-edge sharpness. Counterexamples: Coding is “90% finished” for half of the total coding time Debugging is “99% complete” most of the time …One day at a time.”

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Concreteness in milestones is more important than easy verifiability by the boss How to cope with one-day slippages? Prepare critical-path schedule “Under the rug”-problem. Solutions: Reducing the role conflict: 1. listen till the end. 2. distinguish between status-review and problem-action meetings. Yanking the rug off: periodical review of milestones document (incl. actual dates). Keeping actual vs. estimated dates is handy

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 PERT chart = critical path chart, including milestones. Plans and Controls team (1-3 men in large project) – reported by Brooks to be very successfull.

The Other Face (1) One face: a message from a man to a machine.
2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 One face: a message from a man to a machine. The other face: a message from human to human! To use a program: Purpose Environment Inputs domain and range Functions realized and algorithms used I/O formats Operating instructions

The Other Face (2) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Options Running time Accuracy and checking 3-4 pages, most need to be drafted before writing the program To modify a program, clear and sharp overview of the internal structure is needed: flow chart complete algorithms descriptions / reference all files layout

The Other Face (3) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 design overview and major changes history and motivations Flow charts: obsolete! (at most one page per program) Self documenting programs: The problem: synchronization between code and documentation. The solution: to incorporate the documentation in the source program: Labels, names, spaces,… (good programming ) Pointers to books [documentation] Purpose: tell why rather than how things are.

No Silver Bullet – Essence and Accident in Software Engineering (1)
2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 “There is no single development, in either technology or management technique, which by itself promises even one order-of-magnitude improvement within a decade in productivity, in reliability, in simplicity” (1986). Silver bullet: a way to defeat werewolves. Generally [in folklore]: any straightforward solution perceived to have extreme effectiveness. Compares software to hardware: The anomality is not that software progress is so

NSB (2) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 slow, but that computer hardware progress is so fast. Essence—the difficulties inherent in the nature of the software Accidents—those difficulties that today attend its production but that are not inherent [but incidental]. Essence: Complexity Conformity Changeability Invisibility

NSB (3) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Complexity enormous number of states (orders of magnitude more than in hardware), so conceiving, describing and testing is hard increases non-linearly with its size introduces a lot of difficulties: communication among team members enumerating (much less understanding) of all possible states of the program management problems: conceptual integrity is hard to achieve learning curve: personnel turnover becomes disaster others

NSB (4) Conformity Changeability
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Conformity Physics example: looking for simplicity in complex structures Software: the complexity is arbitrary, forced by existing systems to which the interfaces must conform. cannot be simplyfied by any redesign! Changeability Software is constantly under pressure for change, partly because it can be changed more easily than a building. Two processes are at work:

NSB (5) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Demand for extended function (a result of success) Suitability for a new hardware is needed Invisibility Unlike other disciplines, where geometric abstractions serve as a powerful tool, software is not inherently embedded in space Several general directed graphs, superimposed one upon another appear while trying to create a representation the graphs are nor planar neither hierarchical What helped to overcome some of accidental difficulties in the past?

NSB (6) Hopes for the silver: High-level languages
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 High-level languages Unified programming environments Hopes for the silver: OOP: Hierarchical Data hiding Helps in design, but do not solve design complexity problem AI (expert systems) May be very useful

NSB (7) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 “Automatic” programming: generation of a program from problem specification Used successfully for very specific tasks (differential equations,…) Hard to imagine having a general solution Graphical programming: No hope, for software is difficult to visualize Program verification Might reduce the program-testing load, not eliminate it A lot of work Can establish that a program meet its specification. But the hardest part is to get such complete and consistent specification!

NSB (8) Better workstations, environments and tools Buy vs. Build 
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Better workstations, environments and tools are welcomed, but magical enhacements cannot be expected Buy vs. Build  Discusses the process of wide-spread use of software “today” compared to 60-s, adopting procedures to existing software Requirements refinement and rapid prototyping “The hardest single part of building a software system is deciding precisely what to build” Thus, rapid prototyping tools are one of the most promising efforts that attack the essence of software development problem.

NSB (9) Incremental development Great designers Write vs. Build
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Incremental development Write vs. Build Build vs. Grow (top-down design, stubs…) Great designers “The difference between the great and the average approach an order of magnitude” Gives hints as to how to grow great designers

“NSB” Refired - Skipped
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

Propositions of The M-MM – True or False?
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Considered in the previous slides

The M-MM after 20 years (1) Answers questions like: What do you now
3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Answers questions like: What do you now think was wrong when written? What is now obsolete? What is really new in the software engineering world? What was right and still is: Conceptual integrity is the more important factor in ease of use [There are other factors. Consider Macintosh vs. MS-DOS]. It is the central question addresses by M-MM and is central to product quality.

The M-MM after 20 years (2) The triumph of the WIMP interface
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 The architect’s central role The parallel between the Second-System Effect and mass-market software products It is important to define the user set (Who they are? What they need? What they think they need? What they want?). Write down explicit guesses for the attributes of the user set and their frequencies. The triumph of the WIMP interface Windows, Icons, Menus, Pointing interface Predicts it to become obsolete within a generation

The M-MM after 20 years (3) “Plan to throw one away” is wrong:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 “Plan to throw one away” is wrong: Not too radical, but too simplistic Implicitly assumes the waterfall model: It is wrong because: Assumes “one-shot”, assumes realization mistakes only There must be upstream movement. Better approach is Incremental-Build Model (already mentioned in NSB) Nightly Build approach May be too radical for huge systems Plan Code Component Test System Test Field Support

The M-MM after 20 years (4) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Incremental build and rapid prototyping are very close Information hiding vs. full publicity Both can lead to disasters Barry Boehm model and data: Cost-optimum schedule time to first shipment is Refined Brooks Law By Abdel-Hamid and Madnick Adding more people to a late project always makes it more costly, but it does not always cause it to be completed later

The M-MM after 20 years (5) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Why speak about management rather than technical issues? People are everything Factor of four compared to the next largest one Importance of delegating power downwards in the organizational structure Autonomous teams [sub-units], having its own resources and schedules

Fifty Years of Wonder, Excitement and Joy
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Skipped

The Cathedral and the Bazaar (1)
Written by Eric Steven Raymond (ESR) Central “lessons”: Every good work of software starts by scratching a developer’s personal itch. Good programmers know what to write. Great ones know what to rewrite (and reuse). “Plan to throw one away; you will, anyhow” (Brooks). If you have the right attitude, interesting problems will find you.

When you lose interest in a program, your last duty is to hand it off to a competent successor. Treating your users as co-developers is your least-hassle route to rapid code improvement and effective debugging. Release early. Release often. And listen to your customers. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone [Given enough eyeballs, all bugs are shallow – Linus’s Law].

Smart data structures and dumb code works a lot better than the other way around. If you treat your beta-testers as if they’re your most valuable resource, they will respond by becoming your most valuable resource. The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better. Often, the most striking and innovative solutions come from realizing that your concept of the problem was wrong.

“Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away” – Antoine de Saint-Exupéry. Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected. When writing gateway software of any kind, take pains to disturb the data stream as little as possible – and never throw away information unless the recipient forces you to!

When your language is nowhere near Turing-complete, syntactic sugar can be your friend. A security system is only as secure as its secret. Beware of pseudo-secrets. To solve an interesting problem, start by finding a problem that is interesting to you. Provided the development coordinator has a communications medium at least as good as the Internet, and knows how to lead without coercion, many heads are inevitably better than one.

Key Papers in Computer Science

Similar presentations

Presentation on theme: "Key Papers in Computer Science"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Key Papers in Computer Science

Similar presentations

Presentation on theme: "Key Papers in Computer Science"— Presentation transcript:

Similar presentations

About project

Feedback