Why Human Nature Beats Automation: Lessons on Boosting Software R&D Efficiency

Human Factors in R&D Efficiency

Software development is fundamentally a human activity. Over‑reliance on automation often creates hidden costs because testers spend most of their time maintaining brittle scripts or analysing results. A concrete illustration is a Hawthorne‑effect experiment conducted within a development organization. Two groups of teams were defined: one group applied new efficiency tactics (pre‑run smoke tests, precise test selection) while the other kept the existing workflow. After a fixed period the demand‑delivery throughput (number of requirements delivered per unit time) was measured for all teams. Unexpectedly, every team improved, and some control teams improved more than the experimental teams. The sole common factor was that the throughput numbers were published regularly, making each team aware that their performance was being observed. This behavioural shift confirms that respecting human psychology—visibility, recognition, and a sense of observation—can be a stronger lever than any technical change.

Physical Constraints and Laws

Moore's Law and the Anti‑Moore Law

Gordon Moore (1965) formulated three related observations that roughly double every 18 months:

Number of transistors on an integrated‑circuit chip.

Micro‑processor performance (speed) while price per performance halves.

Computational capability purchasable for one US dollar.

Eric Schmidt (former Google CEO) coined an “anti‑Moore” rule: a software‑oriented company that does not keep pace will see its revenue halve within the same 18‑month window. The rule emphasizes that delayed delivery reduces the economic value of a product, creating pressure to shorten cycle times.

Other Immutable Laws

Additional “physical” constraints that shape productivity include:

Conway’s Law – system architecture mirrors the communication structure of the organization.

Brook’s Law – adding manpower to a late project makes it later.

Hofstadter’s Law – tasks take longer than expected, even when accounting for Hofstadter’s Law.

Knuth’s Optimization Principle – optimal solutions often require careful analysis rather than brute force.

Iterative Development vs Waterfall

The traditional waterfall model enforces a linear, phase‑based flow (requirements → design → implementation → test → release). Each feature must traverse the entire pipeline before delivery, which makes the process slow to react to change and inflates the time‑to‑value.

Iterative development decomposes work into short cycles (sprints, iterations). Each iteration delivers a usable increment, allowing earlier feedback, risk mitigation, and faster capture of market value. Compared with waterfall, iteration reduces batch size, shortens lead time, and aligns better with the 18‑month cadence implied by Moore’s law.

Practical Practices to Improve R&D Efficiency

Avoid Conflicting Goals

Goal transparency before decomposition : share high‑level objectives across teams first; identify and resolve contradictions before breaking them into sub‑goals.

Seek common higher‑level objectives : align disparate teams (e.g., development and testing) around a shared outcome such as “early delivery of high‑quality product”.

Reduce Formalism

Eliminate unnecessary rules that generate waste. A concrete example: a test‑case review was moved from a formal meeting room to a portable TV in a lounge. Participants were prohibited from using laptops, drinks were allowed, and the session finished within one hour. The relaxed setting increased focus and reduced meeting overhead.

Break Organizational Boundaries

Adopt joint‑management for ambiguous areas and encourage a “one‑person‑multiple‑abilities” mindset. This reduces single‑point dependencies and promotes cross‑team collaboration, especially for tasks that lack clear ownership.

Control and Constraints

Apply the broken‑window principle: promptly correct undesirable habits before they spread. Enforce reasonable coding standards and avoid the myth that “no refactoring is needed because the code is perfect”. Consistent early correction prevents technical debt from compounding.

Clear Incentives and Penalties

Reward teams that reduce resource consumption through optimisation; saved resources are re‑allocated to the same team, reinforcing the behaviour. Light‑hearted ceremonies (e.g., “red strawberry” awards) can publicly acknowledge high performers and gently signal corrective expectations.

Encourage a Small‑Wheel Economy

While avoiding unnecessary duplication, allow limited “wheel‑building” when it introduces genuine innovation. Virtual incubator teams provide transparent coordination and resources for promising small‑scale tools. Once a tool matures, it can be abstracted into a shared platform, achieving a balance between reuse and innovation.

阅读原文，跳转我的仓库地址