Up to Code

American building codes set a minimum, not an ideal. The Massachusetts building code states its purpose: “to establish the minimum requirements to safeguard the public health, safety and general welfare.”

In everyday American speech, the question asked about a building, a deck or a wiring job is whether it is “up to code.”

Boil the Ocean

American business English has several phrases for doing more than a problem needs.

boil the ocean — to take on an overwhelmingly large task. In 2010 Meg Whitman, then a candidate for governor of California, said she would not try to “boil the ocean.”

bells and whistles — extra features beyond what is needed.

over-engineered — built to a higher standard than the job requires. The word is used as criticism.

it gets the job done — praise for something that works, however plain.

good to go — ready, with nothing more to add.

A Good Plan Now

General George S. Patton’s best-known rule is usually quoted as “A good plan violently executed now is better than a perfect plan executed next week.” In his book War As I Knew It (1947), under the heading “Don’t Delay,” it reads: “a good plan violently executed now is better than a perfect plan next week.”

The idea was older. In 1929 the British writer Sir Frederick Maurice praised “a reasonably good plan carried through with promptness and determination.” By 1979 an American book had turned it into everyday advice: “A good plan today is better than a perfect plan tomorrow.”

The 70% Solution

At The Basic School, where the Marine Corps trains its new officers, a handout on decision making teaches “The 70% Solution.” It says: “We must learn to accept uncertainty and execute quickly with an imperfect plan.”

It warns: “We must guard against waiting for a perfect sight picture, which may never come, leading to inaction.” The reason it gives: “We are competing in time with the enemy.”

Overshooting the Customer

In 2001 Clayton Christensen of Harvard Business School told an alumni conference that companies give customers more than they can use: “overshooting is always inconceivable, and overshooting always happens.” His example: “Microsoft has way overshot what the customer needs.”

In Christensen’s theory of disruptive innovation, overshooting opens the way for rivals that are cheaper and simpler. Such an innovation becomes disruptive only in a market where customers are being given more than they need.

Patch Tuesday

On October 1, 2003, Microsoft announced that it would release its security fixes on a fixed monthly schedule. The day became known as Patch Tuesday, the second Tuesday of each month. Microsoft said “patch timing was the number one customer request.”

Today more than 100 security fixes in one month is common. Fixes that cannot wait are released “out-of-band.”

The customers did not ask for software without flaws. They asked to know when the fixes would come.

Technical Debt

In 1992 the American programmer Ward Cunningham introduced a metaphor at a software conference: “Shipping first-time code is like going into debt.” A little debt speeds development, he wrote, as long as it is paid back promptly. “The danger occurs when the debt is not repaid.”

Technical debt is now a standard term in software teams. Often the shortcut is taken on purpose, and the cost of fixing it later is counted as interest. In Cunningham’s words: “Every minute spent on not-quite-right code counts as interest on that debt.”

If It Ain’t Broke, Don’t Fix It

The saying is credited to Bert Lance, budget director under President Jimmy Carter. In May 1977 the magazine Nation’s Business quoted him: “That’s the trouble with government: Fixing things that aren’t broken and not fixing things that are broken.”

Lance did not invent the phrase. An aviation journal used “If it Ain’t Broke, Don’t Fix It” as an article title in September 1962. In 1976 a bank president quoted in the Atlanta Constitution called it “an old Cajun saying.”

In August 2025 the U.S. Office of Personnel Management still credited Lance. It explained the meaning: “effect change where required, but not to re-invent the wheel.”

You Aren’t Gonna Need It

Extreme Programming, an American software method, has a rule with a blunt name: YAGNI, “You aren’t gonna need it.” Ron Jeffries, one of its founders, wrote in 1998: “Always implement things when you actually need them, never when you just foresee that you need them.”

The rule supports another practice of the method: “do the simplest thing that could possibly work.” Kent Beck’s book Extreme Programming Explained uses the acronym.

Fixed Time, Variable Scope

The software company 37signals, maker of Basecamp, publishes its working method as a book, Shape Up, by Ryan Singer, free to read online. Its rule is “fixed time, variable scope.” Teams work in six-week cycles, and a project gets at most six weeks. “Six weeks is long enough to finish something meaningful and short enough to feel the deadline from the beginning.”

When the work does not fit, the team cuts scope, not time. “Shipping on time means shipping something imperfect.” A project that does not ship in the time set for it “doesn’t get an extension” by default.

understand-culture
Privacy Overview

This website uses cookies so that we can provide you with the best user experience possible. Cookie information is stored in your browser and performs functions such as recognising you when you return to our website and helping our team to understand which sections of the website you find most interesting and useful.