Phrases that a programmer should know

On Project Management

“Adding manpower to a late software project makes it later” —𝔹𝕣𝕠𝕠𝕜𝕤’𝕤 𝕃𝕒𝕨

“For many phenomena, 80% of consequences stem from 20% of the causes” —ℙ𝕒𝕣𝕖𝕥𝕠 ℙ𝕣𝕚𝕟𝕔𝕚𝕡𝕝𝕖

“Nothing ever gets built on schedule or within budget” — ℂ𝕙𝕖𝕠𝕡𝕤 𝕃𝕒𝕨

“Anything that can go wrong will go wrong” — 𝕄𝕦𝕣𝕡𝕙𝕪’𝕤 𝕃𝕒𝕨

“I have always found that plans are useless, but planning is indispensable” — 𝔻𝕨𝕚𝕘𝕙𝕥 𝔼𝕚𝕤𝕖𝕟𝕙𝕠𝕨𝕖𝕣

On Estimation & Time Management

“The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time” — 𝕋𝕠𝕞 ℂ𝕒𝕣𝕘𝕚𝕝𝕝

“The time from now until the completion of the project tends to become constant” — ℍ𝕒𝕣𝕥𝕣𝕖𝕖’𝕤 𝕃𝕒𝕨

“Work expands to fill the time available for its completion” — ℙ𝕒𝕣𝕜𝕚𝕟𝕤𝕠𝕟’𝕤 𝕃𝕒𝕨

“It always takes longer than you expect, even when you take into account Hofstadter’s Law” — ℍ𝕠𝕗𝕤𝕥𝕒𝕕𝕥𝕖𝕣’𝕤 𝕃𝕒𝕨

“There’s never enough time to do it right, but there’s always enough time to do it over” — 𝕁𝕒𝕔𝕜 𝔹𝕖𝕣𝕘𝕞𝕒𝕟

On Requirements

“Walking on water and developing software from a specification are easy if both are frozen” — 𝔼𝕕𝕨𝕒𝕣𝕕 𝔹𝕖𝕣𝕒𝕣𝕕

“The user will never know what they want until after the system is in production (and maybe not even then)” — ℍ𝕦𝕞𝕡𝕙𝕣𝕖𝕪’𝕤 𝕃𝕒𝕨

“It is easier to change the specification to fit the program than vice versa” — 𝔸𝕝𝕒𝕟 ℙ𝕖𝕣𝕝𝕚𝕤

“The more stable a requirement is considered, the greater the probability it is changed” — ℍ𝕖𝕚𝕤𝕖𝕟𝕓𝕖𝕣𝕘’𝕤 ℙ𝕣𝕚𝕟𝕔𝕚𝕡𝕝𝕖

“Increasing the number of choices will increase the decision time logarithmically” — ℍ𝕚𝕔𝕜’𝕤 𝕃𝕒𝕨

“A man with a watch knows what time it is. A man with two watches is never sure” — 𝕊𝕖𝕘𝕒𝕝’𝕤 𝕃𝕒𝕨

On Architecture & Design

“Hiring people to write code to sell is not the same as hiring people to design and build durable, usable, dependable software” —𝕃𝕒𝕣𝕣𝕪 ℂ𝕠𝕟𝕤𝕥𝕒𝕟𝕥𝕚𝕟𝕖

“The hardest part of the design is … keeping features out” — 𝔻𝕠𝕟𝕒𝕝𝕕 ℕ𝕠𝕣𝕞𝕒𝕟

“A software system built on top of a weak architecture will sink due to the weight of its success” — 𝕋𝕙𝕖 𝔸𝕣𝕔𝕙𝕚𝕞𝕖𝕕𝕖𝕒𝕟 ℙ𝕣𝕚𝕟𝕔𝕚𝕡𝕝𝕖

“Before software can be reusable it first has to be usable” — ℝ𝕒𝕝𝕡𝕙 𝕁𝕠𝕙𝕟𝕤𝕠𝕟

“A complex system that works is invariably found to have evolved from a simple system that worked” — 𝔾𝕒𝕝𝕝’𝕤 𝕃𝕒𝕨

On Writing Bug-Free Code

“The cheapest, fastest, and most reliable components are those that aren’t there” — 𝔾𝕠𝕣𝕕𝕠𝕟 𝔹𝕖𝕝𝕝

“If debugging is the process of removing software bugs, then programming must be the process of putting them in” — 𝔼𝕕𝕤𝕘𝕖𝕣 𝔻𝕚𝕛𝕜𝕤𝕥𝕣𝕒

“Deleted code is debugged code” — 𝕁𝕖𝕗𝕗 𝕊𝕚𝕔𝕜𝕖𝕝

“Bugs lurk in corners and congregate at boundaries” — 𝔹𝕠𝕣𝕚𝕤 𝔹𝕖𝕚𝕫𝕖𝕣

“There are two ways to write error-free programs; only the third one works” — 𝔸𝕝𝕒𝕟 ℙ𝕖𝕣𝕝𝕚𝕤

On Programming

“Increasing the efficiency with which a resource is used increases the usage of that resource” — 𝕁𝕖𝕧𝕠𝕟’𝕤 ℙ𝕒𝕣𝕒𝕕𝕠𝕩

“If you automate a mess, you get an automated mess” — ℝ𝕠𝕕 𝕄𝕚𝕔𝕙𝕒𝕖𝕝

“A good programmer is someone who always looks both ways before crossing a one-way street” — 𝔻𝕠𝕦𝕘 𝕃𝕚𝕟𝕕𝕖𝕣

“Any code of your own that you haven’t looked at for six or more months might as well have been written by someone else” — 𝔼𝕒𝕘𝕝𝕖𝕤𝕠𝕟’𝕤 𝕃𝕒𝕨

“One man’s crappy software is another man’s full-time job” — 𝕁𝕖𝕤𝕤𝕚𝕔𝕒 𝔾𝕒𝕤𝕥𝕠𝕟

On Technology

“We tend to overestimate the effect of a technology in the short run and underestimate the effect in the long run” — ℝ𝕠𝕪 𝔸𝕞𝕒𝕣𝕒

“Any sufficiently advanced technology is indistinguishable from magic” — ℂ𝕝𝕒𝕣𝕜𝕖’𝕤 𝕋𝕙𝕚𝕣𝕕 𝕃𝕒𝕨

“Institutions will try to preserve the problem to which they are the solution” — ℂ𝕝𝕒𝕪 𝕊𝕙𝕚𝕣𝕜𝕪

“It’s a curious thing about our industry: not only do we not learn from our mistakes, but we also don’t learn from our successes” — 𝕂𝕖𝕚𝕥𝕙 𝔹𝕣𝕒𝕚𝕥𝕙𝕨𝕒𝕚𝕥𝕖