Agile Glossary

Rules of Simplicity

What is Rules of Simplicity?

A set of criteria, in priority order, proposed by Kent Beck to judge whether some source code is “simple enough”:

  • the code is verified by automated tests, and all such tests pass
  • the code contains no duplication
  • the code expresses separately each distinct idea or responsibility
  • the code is composed of the minimum number of components (classes, methods, lines) compatible with the first three criteria

Common Pitfalls

The first criterion is easy to judge but implies something far from trivial: namely that the source code in question is “correct”, or has no defects. Unit tests are at best suggestive evidence that a program has no defects and certainly no definite proof. Pragmatically, however, Agile discourse considers them an excellent first line of defense.

The next two criteria leave more room for subjective judgment. For instance, code duplication can be taken literally, as character-for-character duplication. Since unfortunately “copy-paste programming” remains common industry practice, this is a frequent occurrence, which can be alleviated through diligent refactoring. However, competent programmers also recognize more subtle forms of duplication.

Similarly, many distinct attempts at formalizing the third criterion exist, none of them regarded as definitive. Examples include “low coupling and high cohesion” and the SOLID design principles.

Origins

Add to Bookmarks Remove Bookmark
Add to Bookmarks Remove from Bookmarks
Add to Bookmarks Remove from Bookmarks

Thank you to our Annual Partners​

Join us today!

Agile Alliance offers many online and in-person events and workshops for our members. If you’re not currently a member, you can join now to take advantage of our many members-only resources and programs.

Get the latest Agile news!

  • This field is for validation purposes and should be left unchanged.

By subscribing, you acknowledge the Agile Alliance Privacy Policy, and agree to receive our emails.

Additional Agile Glossary Terms

An acceptance test is a formal description of the behavior of a software product, generally expressed as an example or a usage scenario. A number of different notations and approaches have been proposed for such examples or scenarios.
Test-driven development (TDD) is a style of programming where coding, testing, and design are tightly interwoven. Benefits include reduction in defect rates.
The team meets regularly to reflect on the most significant events that occurred since the previous such meeting, and identify opportunities for improvement.
A product backlog is a list of the new features, changes to existing features, bug fixes, infrastructure changes or other activities that a team may deliver in order to achieve a specific outcome.
An acceptance test is a formal description of the behavior of a software product, generally expressed as an example or a usage scenario. A number of different notations and approaches have been proposed for such examples or scenarios.
Test-driven development (TDD) is a style of programming where coding, testing, and design are tightly interwoven. Benefits include reduction in defect rates.
The team meets regularly to reflect on the most significant events that occurred since the previous such meeting, and identify opportunities for improvement.

Help us keep the definitions updated

Discover the many benefits of membership

Your membership enables Agile Alliance to offer a wealth of first-rate resources, present renowned international events, support global community groups, and more — all geared toward helping Agile practitioners reach their full potential and deliver innovative, Agile solutions.

Not yet a member? Sign up now