General ITAdvanced

Kidlin’s Law Explained: Meaning, Origin, Examples, Problem-Solving Method, Importance in Business, IT and Daily Life

Kidlin’s Law is a popular problem-solving principle usually expressed as: “If you write the problem down clearly, then the matter is half solved.” A modern v...

Bison Technical Team Enterprise IT specialists

Updated 22 Aug 2026 14 min read 2 total views

Kidlin’s Law is a popular problem-solving principle usually expressed as:

“If you write the problem down clearly, then the matter is half solved.”

Advertisement

A modern variation says:

“If you write a problem down clearly and specifically, you have solved half of it.”

The idea is simple but powerful: before trying to solve a problem, define exactly what the problem is.

Kidlin’s Law is not a scientific or mathematical “law.” It is better understood as a problem-solving adage or management principle. Its central lesson is that many problems remain difficult not merely because the solution is difficult, but because the problem itself has not been properly identified.

For example:

Poor problem definition:

“Our server is slow.”

This gives very little useful information.

Better problem definition:

“Between 10:00 AM and 1:00 PM, when more than 20 RDP users are simultaneously active, CPU utilization repeatedly reaches 95–100%, while RAM remains below 75%. Tally and Chrome response times then increase significantly.”

The second statement immediately narrows the investigation toward CPU contention, processes, concurrent workloads, scheduling and application behaviour.

That is Kidlin’s Law in practice.

Who Invented Kidlin’s Law?

This is where an important correction is necessary because many internet articles present uncertain information as established history.

There is currently no reliable historical evidence identifying a real person named Kidlin as the inventor of Kidlin’s Law. Modern sources themselves acknowledge that its precise origin is uncertain.

Various internet sources attribute it to a fictional character called “Kidlin” in a James Clavell novel. However, these claims are inconsistent. One source says King Rat, another says Noble House, while still other internet claims mention a supposed Clavell book called Snow Tiger. The latter attribution is particularly problematic because the available investigation notes that no evidence has been found for such a Clavell book or character.

Therefore, it would be inaccurate to state confidently that “James Kidlin invented Kidlin’s Law” or to assign it a definite invention date.

Historically safer conclusion

Origin: Uncertain
Inventor: Not reliably established
Date invented: Not reliably established
Status: Popular problem-solving/management adage rather than a formal scientific law

One 2025 investigation describes the saying as circulating since at least the 1980s but was likewise unable to identify who “Kidlin” actually was.

For a technical or knowledgebase article, this uncertainty should be stated rather than repeating an unsupported attribution.

The Basic Principle Behind Kidlin’s Law

Kidlin’s Law can be represented conceptually as:

Unclear Problem → Confusion → Wrong Assumptions → Wrong Solution

whereas:

Clear Problem → Defined Scope → Relevant Data → Root-Cause Analysis → Appropriate Solution

Writing does not literally complete 50% of the technical work. The phrase “half solved” is figurative.

Its meaning is that accurately defining the problem eliminates a substantial amount of unnecessary investigation.

Why Does Writing a Problem Down Make Such a Difference?

When a problem exists only in our mind, several things may be mixed together:

facts,
assumptions,
emotions,
symptoms,
suspected causes,
consequences,
possible solutions.

Writing forces these elements to become explicit.

Consider:

“The internet isn't working properly.”

What exactly does that mean?

It could mean:

Internet connection down → ISP issue

or:

Internet connected but websites don't open → DNS issue

or:

Only one PC affected → local PC/network issue

or:

Only one website unavailable → website/server issue

or:

Wi-Fi connected but very slow → congestion/interference

or:

Primary WAN responds to ping but DNS fails → router health-check/failover configuration issue

The phrase “internet isn't working” therefore describes a symptom rather than a sufficiently defined technical problem.

Kidlin’s Law Example 1: Computer Running Slowly

Suppose a user reports:

“My computer is very slow.”

A technician could immediately start:

deleting temporary files,
upgrading RAM,
replacing the SSD,
reinstalling Windows,
disabling services,
scanning for malware.

But none of these actions is justified yet.

Apply Kidlin’s Law.

Ask questions and write the problem:

“The Windows 11 PC takes approximately 12 minutes after login before it becomes responsive. Task Manager shows disk utilization at 100% during this period while CPU remains below 25% and RAM below 60%. After disk utilization decreases, performance becomes normal.”

Now the problem has changed dramatically.

The technician knows:

Problem occurs: After login
Duration: Approximately 12 minutes
CPU: Normal
RAM: Normal
Disk: 100%
After disk activity drops: PC becomes normal

Therefore, replacing RAM merely because “the computer is slow” would probably be unnecessary.

Investigation can instead concentrate on:

startup applications,
Windows Update,
antivirus scans,
indexing,
disk health,
synchronization applications,
background services,
storage latency.

That is exactly the value Kidlin’s Law provides.

Kidlin’s Law Example 2: Business Problem

Imagine a company says:

“Sales are falling.”

Management immediately proposes:

“We need more advertising.”

This is a classic mistake.

“We need more advertising” is a proposed solution, not a problem definition.

Apply Kidlin’s Law.

Suppose analysis produces:

“Website enquiries remain approximately unchanged at 1,000 per month, but enquiry-to-order conversion has fallen from 12% to 7% during the last six months, primarily among customers requesting delivery within 48 hours.”

Now management knows something very different.

The issue may not be marketing at all.

Possible causes might include:

insufficient stock,
slow quotations,
higher prices,
delivery delays,
poor sales follow-up,
competitor availability,
payment problems.

Spending more money generating additional enquiries could actually waste money.

Kidlin’s Law Example 3: Software Development

A customer tells a developer:

“Your billing software is slow.”

This is not sufficiently actionable.

After investigation:

“When invoices contain more than 100 line items, clicking Save takes between 18 and 25 seconds. During this period SQL Server CPU remains normal, but the application sends individual INSERT queries for every line item rather than using a batch operation.”

Now developers have:

Trigger: 100+ items
Affected operation: Invoice Save
Delay: 18–25 seconds
Database CPU: Normal
Observed behaviour: Repeated individual queries

Instead of randomly optimizing the whole application, developers can investigate the invoice-saving/database interaction.

Kidlin’s Law is therefore particularly valuable in software engineering.

Example 4: Printer Problem

Complaint:

“Printer isn't printing.”

That statement could represent dozens of different failures.

Rewrite it:

“The network printer responds to ping from all PCs. Windows reports it as Ready, but print jobs remain in the queue with status ‘Printing’. Printing the printer's internal configuration page works normally.”

This immediately tells a technician that:

printer hardware probably works,
network communication exists,
paper/toner/mechanical printing is functional,
the issue may lie in the Windows spooler, driver, port or print-processing path.

Again, clearer definition dramatically reduces the troubleshooting area.

A Useful Kidlin’s Law Problem Statement Formula

For technical and business environments, a practical template is:

[WHO/WHAT] experiences [SPECIFIC PROBLEM] when [CONDITION], causing [MEASURABLE EFFECT], beginning/occurring [TIME/PERIOD], while [IMPORTANT OBSERVATIONS].

For example:

“Remote users experience 5–10 second delays when opening Tally reports between 11 AM and 2 PM when concurrent sessions exceed 20, while CPU usage reaches 95% but network latency remains below 10 ms.”

This is considerably more useful than:

“Tally is slow.”

Six Questions to Apply Kidlin’s Law

Whenever troubleshooting a problem, write answers to:

1. WHAT is happening?

Describe the observable problem.

2. WHERE is it happening?

Identify the device, department, application, process, server, branch or location.

3. WHEN does it happen?

Always? Randomly? After login? During peak load?

4. WHO is affected?

One user, several users, everyone, one department or one customer group?

5. HOW MUCH is the impact?

Measure:

seconds,
minutes,
percentage,
number of failures,
users affected,
revenue lost,
CPU utilization,
memory consumption,
error frequency.

6. WHAT CHANGED?

Ask whether anything changed shortly before the problem appeared:

Windows update,
software update,
hardware replacement,
configuration change,
network change,
new employee,
new process,
policy change.

This final question can dramatically reduce troubleshooting time.

Symptom vs. Problem vs. Cause vs. Solution

Understanding these distinctions is essential.

Consider:

“Customers complain that invoices arrive late.”

Symptom

Customers receive invoices late.

Defined problem

Invoices generated after 4 PM are not automatically emailed until the next morning.

Possible cause

The email-processing service runs only during a scheduled window.

Root cause

Scheduler configuration was changed during a previous server migration.

Solution

Correct the scheduling configuration.

A common mistake is jumping directly from symptom → solution.

Kidlin’s Law encourages:

Symptom → Definition → Evidence → Cause → Root Cause → Solution

Kidlin’s Law and Root-Cause Analysis

Kidlin’s Law works extremely well as the first stage of root-cause analysis.

A practical workflow is:

Step 1 — Write the problem

↓

Step 2 — Verify facts

↓

Step 3 — Separate symptoms from causes

↓

Step 4 — Measure the problem

↓

Step 5 — Determine scope

↓

Step 6 — Generate possible causes

↓

Step 7 — Test each hypothesis

↓

Step 8 — Identify root cause

↓

Step 9 — Implement solution

↓

Step 10 — Verify that the problem is actually resolved

This can then be combined with established tools such as:

5 Whys,
Ishikawa/Fishbone Diagram,
Pareto Analysis,
fault-tree analysis,
process mapping,
logs,
monitoring,
debugging,
A/B testing,
hypothesis testing.

Why Is Kidlin’s Law So Important?

1. It Prevents Solving the Wrong Problem

An excellent solution to the wrong problem is still a failure.

If a server is slow because CPU capacity is exhausted, adding disk capacity may accomplish nothing.

Correct diagnosis comes before optimization.

2. It Separates Facts from Assumptions

Suppose someone says:

“The antivirus is slowing down the server.”

That is an assumption.

A better statement is:

“During the slowdown, antivirus process X consumes 45–55% CPU for approximately 20 minutes.”

Now there is evidence that can be investigated.

3. It Reduces Emotional Decision-Making

Statements such as:

“The software is useless.”

or:

“The employee never does anything correctly.”

are emotional judgments rather than technical problem statements.

Writing requires measurable observations.

4. It Makes Problems Measurable

You cannot reliably determine whether something has improved unless you establish a baseline.

Instead of:

“Website is slow.”

write:

“Average page-load time increased from 1.8 seconds to 6.2 seconds after the latest deployment.”

After correction, performance can be measured again.

5. It Improves Team Communication

Five people may interpret:

“Our ERP is slow”

in five different ways.

A written problem statement establishes a common understanding.

This is particularly important in:

IT teams,
software development,
project management,
customer support,
engineering,
management,
consulting.

Kidlin’s Law in IT Troubleshooting

IT professionals already use the philosophy of Kidlin’s Law, even if they do not call it that.

A good support ticket contains:

Device: Windows Server 2025
Application: SQL Server
Problem: Query timeout
Started: 18 August
Frequency: Approximately 10–15 times daily
Affected users: All ERP users
Error: Timeout expired
CPU: 80–95% during incident
RAM: 72%
Network: Normal
Recent change: Database update installed 17 August

This ticket is dramatically more useful than:

“ERP giving problems. Please check urgently.”

Kidlin’s Law in Software Debugging

Software developers can apply the same principle to bug reports.

Bad bug report:

“Login doesn't work.”

Good bug report:

“In application version 4.2.1 on Chrome 151, users whose passwords contain the '+' character receive HTTP 401 after submitting valid credentials. The same accounts successfully authenticate through the mobile application.”

The second statement gives developers something reproducible.

And reproducibility is one of the most valuable characteristics of a software bug report.

Kidlin’s Law and AI Prompting

The principle has become even more relevant with generative AI.

Compare these prompts:

“My server is slow. Give solution.”

with:

“Windows Server has 25 RDP users, approximately 18–20 simultaneously active. During working hours CPU frequently reaches 100%, RAM reaches 85%, and users report delays mainly in Chrome and accounting applications. Network latency remains normal. What measurements should I collect to isolate whether the bottleneck is CPU scheduling, memory pressure, storage latency or application processes?”

The second prompt will normally produce a much more useful response because the problem is better constrained.

Better problem definition → Better AI context → Better analysis → Better answer

AI does not eliminate Kidlin’s Law. In many situations, it makes the principle even more important.

Kidlin’s Law Does NOT Mean Every Clearly Written Problem Is Easy

This is an important limitation.

Writing:

“Our company needs to reduce operating costs by 20% without reducing workforce, service quality or production capacity.”

does not magically solve the problem.

The problem may still be extremely difficult.

Kidlin’s Law means that clarity creates a better starting point for solving it, not that writing automatically supplies the solution. Modern explanations similarly caution that complex problems still require investigation and judgment after definition.

A Practical Problem Definition Template

Before solving an important issue, complete this template:

Problem

What exactly is wrong?

Expected Behaviour

What should normally happen?

Actual Behaviour

What actually happens?

Scope

Who or what is affected?

Frequency

Always, sometimes or under specific conditions?

Starting Point

When did the problem first appear?

Impact

What is the measurable consequence?

Evidence

What data, logs, screenshots, measurements or observations support the problem?

Recent Changes

What changed before the issue appeared?

Suspected Causes

What possibilities currently exist?

Unknowns

What information is still missing?

This converts an unstructured complaint into a technical investigation.

Kidlin’s Law in One Practical Sentence

The philosophy can be summarized as:

Don't begin by asking, “What is the solution?” Begin by asking, “Can we describe exactly what is wrong?”

That difference is enormous.

Conclusion

Kidlin’s Law teaches one of the most fundamental lessons in problem solving:

Clarity must come before solution.

The familiar formulation—“If you write the problem down clearly, then the matter is half solved”—should not be interpreted mathematically. Writing a problem does not literally perform half the required work.

Instead, carefully documenting a problem forces us to identify:

what is happening, who is affected, where it occurs, when it occurs, how frequently it happens, how serious the impact is, what evidence exists and what remains unknown.

That process reduces ambiguity and makes root-cause investigation substantially more efficient.

Kidlin’s Law is therefore valuable far beyond personal productivity. Its philosophy can be applied to IT troubleshooting, software debugging, business management, engineering, project management, customer support, decision-making, AI prompting and everyday life.

Its historical origin, however, should be presented cautiously. Despite confident claims across the internet, reliable evidence establishing an inventor named Kidlin or a definite invention date is lacking. The principle is best regarded as a widely circulated problem-solving adage of uncertain provenance, rather than a formally discovered scientific law.

The practical lesson remains extremely useful:

A vague problem invites guesses.
A clearly defined problem invites investigation.
A measurable problem invites verification.
And a correctly identified problem makes the right solution much easier to find.

FAQ

1. What is Kidlin’s Law?

Kidlin’s Law is the principle that if you write a problem down clearly and specifically, you have effectively completed an important part of solving it.

2. What is the exact wording of Kidlin’s Law?

The commonly circulated wording is:

“If you write the problem down clearly, then the matter is half solved.”

Several slightly different versions exist.

3. Who invented Kidlin’s Law?

The inventor has not been reliably established. Claims identifying a specific “James Kidlin” or fictional origin should be treated cautiously because the available historical evidence is inconsistent.

4. When was Kidlin’s Law invented?

There is no reliably documented invention date. One modern investigation reports that the saying appears to have circulated since at least the 1980s, but this does not establish when or by whom it originated.

5. Is Kidlin’s Law a scientific law?

No. It is a problem-solving adage or management principle rather than a scientifically established law.

6. Does writing a problem really solve 50% of it?

Not literally. “Half solved” is a metaphor emphasizing how important accurate problem definition is.

7. Why should a problem be written down?

Writing forces you to clarify facts, assumptions, scope, impact and missing information.

8. Can Kidlin’s Law be used in IT troubleshooting?

Yes. It is particularly useful for technical troubleshooting because detailed problem descriptions dramatically narrow the possible causes.

9. Can software developers use Kidlin’s Law?

Yes. Precise bug reports, reproducible test cases, logs and expected-versus-actual behaviour are practical applications of the same philosophy.

10. Can Kidlin’s Law be used with AI?

Yes. Clearly specifying the problem, environment, constraints, observations and desired result generally gives an AI system much better context than a vague question.

11. What is the difference between a symptom and a problem?

A symptom is what you observe, while a properly defined problem describes the specific condition, scope and impact requiring investigation.

12. What should a good problem statement contain?

It should ideally identify what, where, when, who, frequency, magnitude, impact and supporting evidence.

13. Can Kidlin’s Law be combined with the 5 Whys?

Yes. Kidlin’s Law can define the initial problem, after which the 5 Whys technique can be used to investigate its root cause.

14. What is the biggest mistake Kidlin’s Law helps prevent?

It helps prevent jumping to a solution before accurately identifying the problem.

15. Is Kidlin’s Law useful for business management?

Yes. It helps managers distinguish symptoms, assumptions and proposed solutions from the underlying business problem.

16. Does Kidlin’s Law work for personal problems?

The principle can be applied to personal decisions as well. Writing down exactly what is wrong, what outcome is desired and what constraints exist can make a difficult situation easier to analyze.

17. Is “We need new software” a good problem statement?

Usually not. It is a proposed solution. A better question is: What existing business problem would new software need to solve?

18. How does Kidlin’s Law save time?

It reduces investigation of irrelevant possibilities and prevents teams from spending resources solving the wrong problem.

19. What is a simple Kidlin’s Law troubleshooting format?

Use:

Expected result → Actual result → When → Where → Who is affected → Frequency → Impact → Evidence → Recent changes.

20. What is the main lesson of Kidlin’s Law?

Define before diagnosing, diagnose before solving, and verify after implementing the solution.