Project quotes

From Motley Bytes Wiki
Jump to: navigation, search

F_Terry_Baker

Code Library

“The most important of these is a development support library which encourages the visibility and manageability of the product, as well as reduces clerical effort on the part of the programmers. The library is typically maintained and operated by a programming librarian who serves to control the programming assets and to provide the necessary services for both programmers and management. As a result of its use, the entire project is maintained in a centralized, up-to-date, visible form which makes its status immediately apparent to code-competent software managers and makes it possible for programmers to answer their questions directly without relying on others.”
  • Source: Baker, F. T. (1975). Software Management Through Improved Programming Technology. ACM ’75: Proceedings of the 1975 Annual Conference, 286–287. https://doi.org/10.1145/800181.810346
Keywords: Programming_quotes Productivity_quotes Library_quotes Source_Code_quotes Important_quotes Development_quotes Support_quotes Encourage_quotes Visible_quotes Management_quotes Product_quotes Reduce_quotes Clerical_quotes Effort_quotes Part_quotes Programmer_quotes Typical_quotes Maintain_quotes Operate_quotes Librarian_quotes Serve_quotes Control_quotes Asset_quotes Provide_quotes Service_quotes Necessary_quotes Result_quotes Use_quotes Entire_quotes Project_quotes Centralize_quotes Up_to_date_quotes Form_quotes Make_quotes Status_quotes Immediate_quotes Apparent_quotes Code_quotes Competent_quotes Software_quotes Manager_quotes Possible_quotes Answer_quotes Question_quotes Direct_quotes Rely_quotes

Robert_N_Britcher

Important Development Things

“The single, most important thing is that the individual programmer needs to be given total responsibility and control of the programming, including its function... eliminate project design and review as an exhaustive and rigorous process. Most of the design and review should occur as the program is written. ... Monitor progress on the project by talking to the individual programmers as [code] is being written. ... You must trust developers on the project to create a good product. ... Sometimes there are failures. ... The important thing is to fail quickly so you have time to find another approach. ... Developers must also feel free to say what they think to their supervisor. ... Managers should be the best programmers; ...There should be no overtime pay. ... Use profit-sharing and bonuses to get awesome products. ... Developers should each get their own office. ... Eliminate the dress code. Avoid meetings at all costs. ... Writing software is a lot like writing a book. Almost anyone can write garbage; very few can write a best-seller.”
  • Source: Britcher, Robert N. (1999). The Limits of Software: People, Projects, and Perspectives. Reading, MA: Addison Wesley. ISBN 0-201-43323-0. Page 155-156.
Keywords: Importance_quotes Programmer_quotes Responsibility_quotes Control_quotes Programming_quotes Function_quotes Design_quotes Review_quotes Rigorous_quotes Heavy_quotes Methodology_quotes Monitoring_quotes Progress_quotes Project_quotes Communication_quotes Trust_quotes Development_quotes Failure_quotes Quickness_quotes Thinking_quotes Expression_quotes Overtime_quotes Management_quotes Profit_Sharing_quotes Bonus_quotes Product_quotes Excellence_quotes Office_quotes Dress_Code_quotes Meeting_quotes Software_quotes Writing_quotes Garbage_quotes Best_Seller_quotes Compensation_quotes Eliminate_quotes Occur_quotes Coding_quotes Talk_quotes Code_quotes Developer_quotes Create_quotes Good_quotes Say_quotes Think_quotes Supervisor_quotes Manager_quotes Best_quotes Awesome_quotes Book_quotes

Up Front Time and Money

“Put enough time and money into any project, up front, and it will fail.”
  • Source: Britcher, Robert N. (1999). The Limits of Software: People, Projects, and Perspectives. Reading, MA: Addison Wesley. ISBN 0-201-43323-0. Page 187.
Keywords: Time_quotes Money_quotes Project_quotes Up_Front_quotes Failure_quotes Budget_quotes Front_quotes

Fred Brooks

Brooks' Law

“Adding manpower to a late software project makes it later.”
  • Source: Brooks Jr., F. P. (1995). The Mythical Man-Month - Essays on Software Engineering (Anniversary Edition) | 1975/1995 (Anniv.). Boston. MA: Addison-Wesley. ISBN: 0201835959. Chapter 2, page 25. Known as Brooks' Law.
Keywords: Project_quotes Project_Management_quotes Schedule_quotes Software_Engineering_quotes Software_Management_quotes Human_Resources_quotes Law_quotes Management_quotes Software_quotes Engineering_quotes Human_quotes Resource_quotes Make_quotes Late_quotes

Throw One Away

“Plan to throw one away; you will, anyhow.”
  • Source: Brooks Jr., F. P. (1995). The Mythical Man-Month - Essays on Software Engineering (Anniversary Edition) | 1975/1995 (Anniv.). Boston. MA: Addison-Wesley. ISBN: 0201835959. Chapter 11, page 116.
Keywords: Project_quotes Project_Management_quotes Software_Engineering_quotes Software_Management_quotes Failure_quotes Management_quotes Software_quotes Engineering_quotes Plan_quotes Throw_quotes Away_quotes One_quotes

Specification Hard

“Even perfect program verification can only establish that a program meets its specification. The hardest part of the software task is arriving at a complete and consistent specification, and much of the essence of building a program is in fact the debugging of the specification.”
  • Source: Brooks Jr., F. P. (1995). The Mythical Man-Month - Essays on Software Engineering (Anniversary Edition) | 1975/1995 (Anniv.). Boston. MA: Addison-Wesley. ISBN: 0201835959. Chapter 16, page 195.
Keywords: Specification_quotes Requirements_quotes Verification_quotes Debugging_quotes Project_quotes Project_Management_quotes Software_quotes Software_Management_quotes Perfect_quotes Program_quotes Establish_quotes Hard_quotes Difficult_quotes Task_quotes Management_quotes Arrive_quotes Complete_quotes Consistent_quotes Essence_quotes Build_quotes Fact_quotes Debug_quotes

Productivity Magnitude

“Study after study shows that the very best designers produce structures that are faster, smaller, simpler, cleaner, and produced with less effort. The differences between the great and the average approach an order of magnitude.”
  • Source: Brooks Jr., F. P. (1995). The Mythical Man-Month - Essays on Software Engineering (Anniversary Edition) | 1975/1995 (Anniv.). Boston. MA: Addison-Wesley. ISBN: 0201835959. Chapter 16, page 202.
Keywords: Design_quotes People_quotes Software_quotes Productivity_quotes Quality_quotes Software_Quality_quotes Project_Management_quotes Excellence_quotes Study_quotes Designer_quotes Produce_quotes Structure_quotes Fast_quotes Simple_quotes Small_quotes Clean_quotes Effort_quotes Project_quotes Management_quotes Difference_quotes Great_quotes Average_quotes Order_quotes Magnitude_quotes

Promotions out of Design

“Designers get promoted out of design. Consequently, few designers will work in any depth on as many as 100 projects over a working life.”
  • Source: Brooks Jr., F. P. (2010). The Design of Design. Upper Saddle River, NJ: Addison-Wesley. ISBN: 978-0-201-36298-5. Chapter 3, page 24.
Keywords: Design_quotes Promotion_quotes Project_quotes Career_quotes Designer_quotes Consequence_quotes Work_quotes Depth_quotes Life_quotes

Alistair_Cockburn

Striking Project Findings

"What I find striking about these projects is that they show:
Almost any methodology can be made to work on some project.
Any methodology can manage to fail on some project.
Heavy processes can be successful.
Light processes are more often successful, and more importantly, the people on those projects credit the success to the lightness of the methodology."
Keywords: Formality_quotes Methodology_quotes Process_quotes Development_quotes Project_quotes Heavy_quotes Light_quotes Success_quotes Failure_quotes Strike_quotes Show_quotes Work_quotes People_quotes Finding_quotes

People Characteristics

"People, as active devices, have success modes and failure modes. The following are the main ones that I have named and used to date:
1. People are communicating beings, doing best face-to-face, in person, with real-time question and answer.
2. People have trouble acting consistently over time.
3. People are highly variable, varying from day to day and place to place.
4. People generally want to be good citizens, are good at looking around, taking initiative, and doing 'whatever is needed' to get the project to work.
There are other characteristics that I won’t expand here:
- People need both think time and communicating opportunities...
- People work well from examples...
- People prefer to fail conservatively than to risk succeeding differently; prefer to invent than to research, can only keep a small amount in their heads, and do make mistakes, and find it hard to change their habits.
- Individual personalities easily dominate a project.
- A person’s personality profile strongly affects their ability to perform specific assignments."
Keywords: People_quotes Success_quotes Failure_quotes Communication_quotes Proximity_quotes Real_Time_quotes Question_quotes Consistency_quotes Time_quotes Variability_quotes Citizen_quotes Good_quotes Observation_quotes Flexibility_quotes Altruism_quotes Conservative_quotes Initiative_quotes Project_quotes Risk_quotes Differences_quotes Invention_quotes Innovation_quotes Research_quotes Thinking_quotes Habit_quotes Personality_quotes Ability_quotes Limitation_quotes Consciousness_quotes Cognition_quotes Mistake_quotes Hard_quotes Domination_quotes Assignment_quotes Active_quotes Device_quotes Mode_quotes Beings_quotes Face_quotes Person_quotes Answer_quotes Trouble_quotes Day_quotes Place_quotes Look_quotes Need_quotes Work_quotes Characteristic_quotes Opportunity_quotes Example_quotes Fail_quotes Head_quotes Change_quotes Profile_quotes Affect_quotes Perform_quotes

DeMarco and Lister

Project Failures

"We observe that about 15 percent of all projects studied came to naught: They were canceled or aborted or 'postponed' or they delivered products that were never used. For bigger projects, the odds are even worse. Fully 25 percent of projects that lasted 25 work-years or more failed to complete. In the early surveys, we discarded these failed data points and analyzed the others. Since 1979, though, we’ve been contacting whoever is left of the project staff to find out what went wrong. For the overwhelming majority of the bankrupt projects we studied, there was not a single technological issue to explain the failure."
  • Source: Book:: Entitled: Peopleware: Productive Projects and Teams. Edition: 3rd. Written by: Tom DeMarco; Tim Lister. Date published: 1987; 1999; 2013. Publisher: Addison-Wesley. Country: USA; GBR; CAN; DEU; FRA; ESP; ZAF; AUS; JPN; SGP; MEX. Language: en. ISBN: ISBN-13: 978-0-321-93411-6 (alk paper); 0-321-93411-3 (alk paper). Chapter: 1 (Somewhere Today, a Project Is Failing).
Keywords: Observation_quotes Project_quotes Failure_quotes Abort_quotes Postponement_quotes Unused_quotes Big_quotes Probability_quotes Work_quotes Effort_quotes Bankruptcy_quotes Technology_quotes Cancel_quotes Deliver_quotes Odds_quotes Complete_quotes Survey_quotes Discard_quotes Analyze_quotes Contact_quotes Majority_quotes Bankrupt_quotes Explain_quotes

Project Politics

"The cause of failure most frequently cited by our survey participants was 'politics.' But now observe that people tend to use this word rather sloppily. Included under 'politics' are such unrelated or loosely related things as communication problems, staffing problems, disenchantment with the boss or with the client, lack of motivation, and high turnover. People often use the word politics to describe any aspect of the work that is people-related, but the English language provides a much more precise term for these effects: They constitute the project’s sociology. The truly political problems are a tiny and pathological subset."
  • Source: Book:: Entitled: Peopleware: Productive Projects and Teams. Edition: 3rd. Written by: Tom DeMarco; Tim Lister. Date published: 1987; 1999; 2013. Publisher: Addison-Wesley. Country: USA; GBR; CAN; DEU; FRA; ESP; ZAF; AUS; JPN; SGP; MEX. Language: en. ISBN: ISBN-13: 978-0-321-93411-6 (alk paper); 0-321-93411-3 (alk paper). Chapter: 1 (Somewhere Today, a Project Is Failing).
Keywords: Failure_quotes Survey_quotes Political_quotes Observation_quotes People_quotes Sloppy_quotes Imprecise_quotes Communication_quotes Staffing_quotes Human_Resources_quotes Management_quotes Boss_quotes Disenchantment_quotes Client_quotes Motivation_quotes Turnover_quotes Sociology_quotes Project_quotes Pathological_quotes Resource_quotes Cause_quotes Frequent_quotes Participant_quotes Aspect_quotes Work_quotes Language_quotes Precise_quotes Term_quotes Effect_quotes

People Related Problems

"Whatever you name these people-related problems, they’re more likely to cause you trouble on your next assignment than all the design, implementation, and methodology issues you’ll have to deal with. In fact, that idea is the underlying thesis of this whole book: The major problems of our work are not so much technological as sociological in nature."
  • Source: Book:: Entitled: Peopleware: Productive Projects and Teams. Edition: 3rd. Written by: Tom DeMarco; Tim Lister. Date published: 1987; 1999; 2013. Publisher: Addison-Wesley. Country: USA; GBR; CAN; DEU; FRA; ESP; ZAF; AUS; JPN; SGP; MEX. Language: en. ISBN: ISBN-13: 978-0-321-93411-6 (alk paper); 0-321-93411-3 (alk paper). Chapter: 1 (Somewhere Today, a Project Is Failing).
Keywords: People_quotes Trouble_quotes Problem_quotes Assignment_quotes Design_quotes Implementation_quotes Methodology_quotes Thesis_quotes Work_quotes Technology_quotes Sociology_quotes Development_quotes Management_quotes Project_quotes Name_quotes Cause_quotes Nature_quotes

Seldom Manage That Way

"Most managers are willing to concede the idea that they’ve got more people worries than technical worries. But they seldom manage that way. They manage as though technology were their principal concern. They spend their time puzzling over the most convoluted and most interesting puzzles that their people will have to solve, almost as though they themselves were going to do the work rather than manage it. They are forever on the lookout for a technical whizbang that promises to automate away part of the work. The most strongly people-oriented aspects of their responsibility are often given the lowest priority."
  • Source: Book:: Entitled: Peopleware: Productive Projects and Teams. Edition: 3rd. Written by: Tom DeMarco; Tim Lister. Date published: 1987; 1999; 2013. Publisher: Addison-Wesley. Country: USA; GBR; CAN; DEU; FRA; ESP; ZAF; AUS; JPN; SGP; MEX. Language: en. ISBN: ISBN-13: 978-0-321-93411-6 (alk paper); 0-321-93411-3 (alk paper). Chapter: 1 (Somewhere Today, a Project Is Failing).
Keywords: Manager_quotes People_quotes Worry_quotes Technology_quotes Seldom_quotes Principal_quotes Concern_quotes Time_quotes Puzzle_quotes Convoluted_quotes Solution_quotes Delegation_quotes Trust_quotes Work_quotes Management_quotes Whizbang_quotes Automation_quotes Development_quotes Project_quotes Responsibility_quotes Priority_quotes Concede_quotes Idea_quotes Interesting_quotes Lookout_quotes Promise_quotes Aspect_quotes

Edsger_Wybe_Dijkstra

Two Kinds of System Designers

“There are two classes of system designers. The first, if given five problems will solve them one at a time. The second will come back and announce that these aren’t the real problems, and will eventually propose a solution to the single problem which underlies the original five. This is the ‘system type’ who is great during the initial stages of a design project. However, you had better get rid of him after the first six months if you want to get a working system.”
Keywords: Class_quotes System_quotes Design_quotes Problem_quotes Project_quotes Requirements_quotes Solve_quotes Real_quotes Underlie_quotes Initial_quotes Rid_quotes Work_quotes

David_Epstein

Giant Undertakings

“Since the 1990s, researcher Bent Flyvbjerg has kept a database that tracks giant undertakings... Only 8.5 percent of projects finished on time and on budget; 0.5 percent did that and delivered the prophesied benefits. Almost every major infrastructure project goes over budget, but at least not by as much as IT projects, which have a greater tendency to go hundreds of percent over budget. The pattern of disaster that Flyvbjerg has documented is relatively simple: With few constraints, exciting projects get too large too fast, going from big idea to giant endeavor extremely quickly.”
  • Source: David Epstein in the book “Inside the Box: How Constraints Make Us Better”. Published 2026 by Riverhead Books. Page 14. ISBN 978-0593715734 (Ebook).
Keywords: Since_quotes Research_quotes Database_quotes Track_quotes Giant_quotes Undertaking_quotes Percent_quotes Project_quotes Finish_quotes Time_quotes Budget_quotes Deliver_quotes Prophecy_quotes Benefit_quotes Major_quotes Infrastructure_quotes Go_quotes Information_Technology_quotes Great_quotes Tendency_quotes Hundred_quotes Over_quotes Pattern_quotes Disaster_quotes Documentation_quotes Relative_quotes Simple_quotes Few_quotes Constraint_quotes Excited_quotes Large_quotes Fast_quotes Big_quotes Idea_quotes Endeavor_quotes Quick_quotes

Replication Crisis

“The so-called replication crisis over the last decade has been painful for many scientists, but researchers in every discipline have been learning from it and working to improve their fields. It was, after all, scientists themselves who raised the alarm about their colleagues’ work (and in some cases their own work) in the first place. Increasingly, researchers now share or formally preregister their hypotheses at the start of a project. They can still deviate from the plan to explore unexpected findings, but the deviations are transparent. The point of restricting freedom in this way... is not to stifle inquiry but to make it more valuable.”
  • Source: David Epstein in the book “Inside the Box: How Constraints Make Us Better”. Published 2026 by Riverhead Books. Page 39. ISBN 978-0593715734 (Ebook).
Keywords: Replication_quotes Crisis_quotes Decade_quotes Pain_quotes Science_quotes Research_quotes Discipline_quotes Learn_quotes Work_quotes Improve_quotes Field_quotes Raise_quotes Alarm_quotes Colleague_quotes Case_quotes First_quotes Place_quotes Increase_quotes Share_quotes Formal_quotes Preregister_quotes Hypothesis_quotes Start_quotes Project_quotes Deviation_quotes Plan_quotes Explore_quotes Unexpected_quotes Finding_quotes Transparency_quotes Point_quotes Restrict_quotes Freedom_quotes Way_quotes Stifle_quotes Inquiry_quotes Make_quotes Valuable_quotes

Forbes_Tech_Council

Business Requirements

“One of the reasons software projects fail is the lack of understanding of the business’ needs... Assigning a seasoned business leader to the project team is essential for success.”
Keywords: Reason_quotes Software_quotes Project_quotes Fail_quotes Lack_quotes Understand_quotes Need_quotes Requirements_quotes Assign_quotes Business_quotes Leader_quotes Team_quotes Essential_quotes Success_quotes

Customer Needs

“Sometimes software projects begin with a great idea... only for developers to discover that the problem they solved wasn’t actually the problem their customer needed to be solved.”
Keywords: Sometime_quotes Software_quotes Project_quotes Great_quotes Idea_quotes Developer_quotes Discover_quotes Problem_quotes Solve_quotes Customer_quotes Need_quotes Requirements_quotes

Yuval_Noah_Harari

Discovery of Ignorance

“The scientific revolution was launched by the discovery of ignorance... The scientific project starts by rejecting the fantasy of infallibility and proceeding to construct an information network that takes error to be inescapable.”
  • Source: Yuval Noah Harari writing in his book ‘Nexus: A Brief History of Information Networks from the Stone Age to AI’. Published in 2024 by Random House. Kindle edition. Chapter 4 page 103. ISBN 978-0593734247.
Keywords: Scientific_quotes Revolution_quotes Launch_quotes Discovery_quotes Ignorance_quotes Project_quotes Start_quotes Reject_quotes Fantasy_quotes Infallibility_quotes Proceed_quotes Construct_quotes Information_quotes Network_quotes Error_quotes Inescapable_quotes

Patterson_Hume

University Software Experience

“What really worries me about software engineering is, do universities have to engage in large software projects in order to remain experts in the field of software engineering? Do they have to hire people who have had such experience with large projects, or do they have to have their professors go out and as consultants experience large software engineering projects? Then, when they come to exercise the students, do they have to have laboratories of some considerable consequence in software engineering exercises? Otherwise, who is to formulate principles of software engineering that can be used to train software engineers?”
Keywords: Worry_quotes Software_Engineering_quotes University_quotes Large_quotes Project_quotes Expert_quotes Experience_quotes Hire_quotes Consultant_quotes Professor_quotes Exercise_quotes Student_quotes Laboratory_quotes Formulation_quotes Training_quotes Engineering_quotes People_quotes

Hollis_A_Kinslow

System Problems

“There are two classes of system designers. The first, if given five problems will solve them one at a time. The second will come back and announce that these aren’t the real problems, and will eventually propose a solution to the single problem which underlies the original five. This is the ‘system type’ who is great during the initial stages of a design project. However, you had better get rid of him after the first six months if you want to get a working system.”
Keywords: Design_quotes System_quotes Problem_quotes Compliance_quotes Creativity_quotes Optimal_quotes Analysis_Paralysis_quotes Project_quotes Class_quotes Solve_quotes Time_quotes Announce_quotes Real_quotes Propose_quotes Solution_quotes Underlie_quotes Initial_quotes Stage_quotes Rid_quotes Work_quotes

Deadlines and Iteration

“Iteration is cut short by an arbitrary deadline. This is a fact that must be changed.”
Keywords: Iterative_quotes Deadline_quotes Project_quotes Schedule_quotes Arbitrariness_quotes Fact_quotes Change_quotes Cut_quotes Short_quotes

Donald_Knuth

Software is Hard

“My main conclusion after spending ten years of my life working on the TEX project is that software is hard. It’s harder than anything else I’ve ever had to do.”
  • Source: Donald E. Knuth in the paper entitled All Questions Answered. Published in Notices of the AMS, volume 49, number 3 (March 2002).
Keywords: Conclusion_quotes Work_quotes Project_quotes Software_quotes Programming_quotes Hard_quotes

Michael_Sean_Mahoney

Software Crisis and Software Engineering

“Let me say a bit more about the ‘software crisis’. It emerged in the late 1960s as an increasing number of large projects experienced large cost overruns, missed deadlines and failures to meet specifications. Some had to be canceled altogether. One response was calls for a discipline of ‘software engineering’”
  • Source: Michael S. Mahoney in a paper entitled The Histories of Computing(s). Published 2005 in Interdisciplinary Science Reviews, volume 30, number 2, pages 119–135. DOI: 10.1179/030801805X25927.
Keywords: Software_quotes Crisis_quotes Project_quotes Experience_quotes Cost_quotes Overrun_quotes Deadline_quotes Failure_quotes Specification_quotes Requirements_quotes Cancel_quotes Software_Engineering_quotes Engineering_quotes

Ascher_Opler

Spot the Lemon Early

“In managing software projects the real problem is ‘spot the lemon and spot the lemon early’.”
Keywords: Management_quotes Software_quotes Project_quotes Problem_quotes Spot_quotes Notice_quotes Find_quotes Mindfulness_quotes Lemon_quotes Bug_quotes Defect_quotes Early_quotes

Alan_Perlis

Human Communication Limits

“A man can communicate with about five colleagues on a software project without too much difficulty. Likewise he can supervise about five people and know pretty well what they are doing. One would structure 120 people in three levels, in which no man is talking to more than about eight people, both across his level and up and down”
Keywords: Humanity_quotes Communication_quotes Colleague_quotes Software_quotes Project_quotes Difficulty_quotes Supervision_quotes People_quotes Knowledge_quotes Do_quotes Structure_quotes Level_quotes Talking_quotes Up_quotes Down_quotes Across_quotes

Specifications

“It is easier to change the specification to fit the program than vice versa.”
Keywords: Specification_quotes Requirements_quotes Easy_quotes Change_quotes Fit_quotes Program_quotes Project_quotes Vice_quotes Versa_quotes

Douglas_T_Ross

Requirements Prespecification

“The most deadly thing in software is the concept, which almost universally seems to be followed, that you are going to specify what you are going to do, and then do it. And that is where most of our troubles come from. The projects that are called successful, have met their specifications. But those specifications were based upon the designers’ ignorance before they started the job.”
Keywords: Deadly_quotes Software_quotes Conceptual_quotes Universal_quotes Seem_quotes Follow_quotes Specification_quotes PreSpecification_quotes Do_quotes Trouble_quotes Project_quotes Success_quotes Requirements_quotes Design_quotes Ignorance_quotes Start_quotes Job_quotes

Franz_Selig

Specification Feedback

“External specifications at any level describe the software product in terms of the items controlled by and available to the user. The internal design describes the software product in terms of the program structures which realize the external specifications. It has to be understood that feedback between the design of the external and internal specifications is an essential part of a realistic and effective implementation process. Furthermore, this interaction must begin at the earliest stage of establishing the objectives, and continue until completion of the product.”
Keywords: Software_Engineering_quotes Specification_quotes Design_quotes Feedback_quotes Implementation_quotes Project_quotes Goal_quotes Objectives_quotes Software_quotes Engineering_quotes Level_quotes Product_quotes Term_quotes Item_quotes Control_quotes Available_quotes Internal_quotes Realize_quotes External_quotes Understand_quotes Essential_quotes Part_quotes Realistic_quotes Effective_quotes Process_quotes Interaction_quotes Stage_quotes Establish_quotes Completion_quotes

Gerald_Weinberg

Small Teams More Efficient

“In any case, the basic rule for size and composition of programming teams would seem to be this — for the best programming at the least cost, give the best possible programmers you can find sufficient time so you need the smallest number of them. When you have to work faster, or with less experienced people, costs and uncertainties will rise. In any case, the worst way to do a programming project is to hire a horde of trainees and put them to work under pressure and without supervision — although this is the most common practice today.”
  • Source: Chapter 5. Weinberg, G. M. (2011). The Psychology of Computer Programming (Silver anniversary edition) | 1971. Weinberg & Weinberg.
Keywords: Rule_quotes Size_quotes Programming_quotes Programmer_quotes Team_quotes Cost_quotes Slack_quotes Time_quotes Fast_quotes Experience_quotes People_quotes Hiring_quotes Training_quotes Pressure_quotes Supervision_quotes Management_quotes Practice_quotes Common_quotes Basic_quotes Composition_quotes Quality_quotes Small_quotes Rise_quotes Uncertainty_quotes Worse_quotes Way_quotes Project_quotes Horde_quotes Trainee_quotes Work_quotes

Measuring Performance

“One consequence of the size of a large project is that performance becomes more difficult to measure. Part of this difficulty stems from the scale of things, which makes it impossible for a single mind to be making the judgment of all the parts.”
  • Source: Chapter 6. Weinberg, G. M. (2011). The Psychology of Computer Programming (Silver anniversary edition) | 1971. Weinberg & Weinberg.
Keywords: Consequence_quotes Size_quotes Large_quotes Project_quotes Performance_quotes Measurement_quotes Difficulty_quotes Scale_quotes Impossibility_quotes Mind_quotes Judgment_quotes Part_quotes Complexity_quotes Single_quotes Stem_quotes

Edward_Yourdon

Enterprise Productivity

“Enterprise productivity is much more important than project productivity or programmer productivity.”
  • Source: Edward Yourdon in the book “Decline and Fall of the American Programmer”. Published in 1992 by Prentice Hall. ISBN: 0-13-203670-3. Chapter 1, section 1.6, page 18.
Keywords: Enterprise_quotes Productivity_quotes Project_quotes Programmer_quotes

Prototyping Analysis Design

“Everyone knows the benefits of building a prototype for an end user who is unsure of his or her requirements, but prototyping cannot eliminate the need for formal analysis and design work on large, complex projects.”
  • Source: Edward Yourdon in the book “Decline and Fall of the American Programmer”. Published in 1992 by Prentice Hall. ISBN: 0-13-203670-3. Chapter 2, section 2.4, page 30.
Keywords: Everyone_quotes Know_quotes Benefit_quotes Build_quotes Prototyping_quotes End_quotes User_quotes Requirements_quotes Eliminate_quotes Need_quotes Formal_quotes Analysis_quotes Design_quotes Work_quotes Complex_quotes Project_quotes

What to Do

“Solution: What to Do:
→ Hire the best people you can.
→ Pay special attention to proper training of your people.
→ Provide an exemplary environment in which your people can feel motivated and have fun and do good work.
→ Pay attention to effective project teams.”
  • Source: Edward Yourdon in the book “Decline and Fall of the American Programmer”. Published in 1992 by Prentice Hall. ISBN: 0-13-203670-3. Chapter 3, section 3.5, page 54.
Keywords: Do_quotes Hire_quotes Best_quotes People_quotes Provide_quotes Exemplary_quotes Environment_quotes Feel_quotes Motivation_quotes Fun_quotes Good_quotes Work_quotes Effective_quotes Project_quotes Team_quotes Solution_quotes
Retrieved from "https://motleybytes.com/wiki/index.php?title=Project_quotes&oldid=49286"