Peopleware

1The real problem is human, not technical

Somewhere today a project with zero technical novelty (yet another accounts-receivable system) is failing anyway. Run the autopsy and you find "not a single technological issue to explain the failure." Across 500+ projects tracked since 1977, about 15% died (cancelled or never used). For large projects, those over 25 work-years (the equivalent of 25 people busy for a full year), that rate climbs to 25%.

The cause most often named is "politics", but that word really covers everything about how people relate: who talks to whom, who trusts whom, who feels heard. That is the project's sociology. Hence the thesis of the whole book: "The major problems of our work are not so much technological as sociological in nature."

So why do we keep staring at the technology? Because it is easier. We are, the authors say, mostly in the human communication business while believing we are in high tech. Like the vaudeville character who lost his keys in the dark but searches under the streetlight, "because the light is better there."

2Unpaid overtime produces nothing

The rushed manager's reflex is to squeeze more output from unpaid overtime. The authors call the belief behind it the Spanish Theory of Value: that a fixed amount of value exists and you extract more by squeezing labor harder. "That's not exactly productivity, it's more like fraud."

The hidden mechanism: for salaried people, every hour of overtime is followed by an invisible hour of "undertime", and workaholics eventually burn out and leave.

Notice that nobody who talks about productivity ever mentions turnover, the steady stream of people who quit and have to be replaced.

The Eagle project at Data General was a Spanish-Theory triumph: heroic unpaid hours, record output, and then the whole exhausted team quietly walked away. Productivity is benefit divided by cost, and the cost includes the people you lose.

3Parkinson's Law does not apply to your people

Many managers start from an assumption: left alone, people do as little as possible, so you have to tighten deadlines to force output. That assumption has a name, Parkinson's Law: "work expands to fill the time available." Except Cyril Parkinson was a humorist who "collected no data," and his quip was aimed at bloated bureaucracies, not a team of committed developers.

A real study measured it. Jeffery and Lawrence (University of New South Wales) compared 103 actual projects, sorted by who had set the original estimate, the planned deadline. Estimate made by the programmer alone: good productivity. Made by a neutral third party, an analyst: better still. And the uncomfortable finding: the 24 projects run with no estimate at all "far outperformed all the others," and those where the boss applied no schedule pressure had the highest productivity in the whole sample.

The lesson flips the manager's intuition: schedule pressure did not boost productivity, it sank it. An arbitrary deadline handed down from above does not motivate an already-invested professional — it mainly tells them they are not trusted. Hence DeMarco and Lister's verdict: a phony deadline "can only demean and demotivate."

4Quality is a lever, not a cost

Under time pressure, the only variable left to cut is quality: you cannot add people or drop features at the last minute. Yet people tie their self-esteem to what they build, and what counts to them is "not the quantity, but the quality." Wreck the quality with an impossible deadline and you wreck the motivation with it.

The counterintuitive turn: "Quality, far beyond that required by the end user, is a means to higher productivity." Letting developers hit their own quality bar makes the project faster, not slower.

The authors' line sounds like a paradox: "Quality is free, but only to those who are willing to pay heavily for it." In other words, aiming high costs nothing over time (fewer bugs, motivated people), as long as you accept the upfront investment. Hewlett-Packard built a quality culture so strong that people lined up to work there.

5It is the environment, not the talent

The Coding War Games are a programming tournament the authors run: on the same timed exercise, they pair two developers from the same company. The 1984-86 edition gathered 600+ participants across 92 companies. Raw result: the best performer is about 2.5 times faster than the middle of the pack, roughly ten times the worst.

The shock is what does not explain the gap: not the language, not salary, not years of experience (past six months). Two things do. First, the company itself: the two participants from the same firm scored alike, so what lifts them comes from the company, not their personal talent.

Second, the physical environment: the top 25% (the leading quartile) had more space, more quiet, more privacy, fewer interruptions. Across the sample, 58% found their workplace too noisy and 61% not private enough, and people who worked somewhere quiet delivered a third more bug-free code.

6Flow, and the hidden cost of interruption

Designing, coding and writing all demand flow: a state of deep, almost meditative concentration where the work just flows. You cannot flip it on. It takes "fifteen minutes or more of concentration before the state is locked in." Every interruption sends you back to the start: a five-minute phone call costs 5 + 15 = twenty minutes of real work. A dozen calls and the day is gone.

Hence brain time (time in flow) versus body time (time present). People report the second. The measurable fix is to count uninterrupted hours, not hours at the desk. The authors define the E-Factor (Environmental Factor) = uninterrupted hours / body-present hours, and measured it from 0.10 to 0.38 within a single company depending on the office. In other words, in the worst office barely 10% of desk time is real uninterrupted work; in the best, nearly 40%.

7The jelled team, and the seven ways to kill it

A jelled team is "a group of people so strongly knit that the whole is greater than the sum of the parts": it produces more than the same people working apart, and enjoys the work more. You spot one by its low turnover, strong shared identity (nicknames, in-jokes), sense of eliteness and shared pride. The legendary Black Team (IBM testers in the 1960s) dressed in black, cackled with joy when a program crashed, and the team survived the replacement of every single original member: the personality outlived the people.

You cannot manufacture a jelled team, only the conditions for one. But you can kill it easily. The authors call it teamicide:

• Defensive management: watching people instead of trusting them. "Visual supervision is for prisoners."
• Bureaucracy: mindless paperwork eating the day.
• Physical separation: scatter the members and the informal glue dies.
• Fragmented time: nobody can belong to several jelled teams at once.
• Imposed quality cuts: people building something shoddy avoid each other's eyes.
• Phony deadlines: arbitrary dates everyone knows are fake.
• Clique control: breaking up teams that work the moment a project ends.

8People are capital, not an expense (added in 1999)

Accounting treats spending on people as an expense, never as capital (an investment that pays off later). It is a modelling error with brutal consequences.

When Louise the expert leaves and Ralph replaces her, Ralph produces nothing on his first day: he even costs his colleagues time, since they have to train him, so his net contribution is negative. Through all those months while he ramps up, the company pays his salary while he delivers little: that accumulated lost output is the investment gone up in smoke. At one company the authors audited, bringing a skilled person back to full productivity took over two years and cost more than $150,000.

Laying people off burns that capital. "Companies that downsize are frankly admitting that their upper management has blown it." Written in 1999, and screaming louder in 2026 after the tech layoff waves.