From DataSelf Knowledge Base
Jump to navigation Jump to search

Entries of work-in-progress, ideas under development, and/or of mostly interest to DS staff.

'Less is more' is best understood as standing for an unstated or assumed ideal. Persons who use the phrase should be aware that it assumes a shared, common meaning where no such common understanding actually exists. This page is designed to illustrate these claims.

The phrase 'less is more' is confusing and often less than helpful for designers and others who have to design actual solutions and procedures.

Alternatives to 'Less is More'

  • Sometimes less is more.
  • Elegance is Ideal.
  • Principles (plural) of Simplicity
  • Simplicity is a balance (of factors). Simplicity is a balance of several competing aspects, values or measures of simplicity.
  • The short answer is no. The long answer is the rest of this paper.
  • "Do the Simplest Thing that Could Possibly Work" -- Software Design Principle
  • "You Aren't Going to Need It" (YAGNI).
    Don't add any code today that isn't required for todays needs. Build more general or flexible structures only when they are required then let the structure evolve as needed. YAGNI makes sense in the context of an evolutionary design and development process.
  • Less is More When/If/For Whom. Context makes all the difference.

Simplicity is an ironically complex subject.

Simplicity is a complicated thing to find.

Critiques of 'Less is More'

Seek simplicity and distrust it. -- Alfred North Whitehead

Dilbert's View

In this complicated world the simplest explanation is usually dead wrong. However a more simple explanation often sounds more right and more convincing than anything complicated.

Adams describes God's Debris as a thought experiment, challenging readers to differentiate its scientifically accepted theories from "creative baloney designed to sound true," and to "Try to figure out what's wrong with the simplest explanation."

-- wikipedia entry for God's Debris by Scott Adams

Maeda's 10 Laws of Simplicity (plus Three Keys)

Key Concepts:

  • Simplicity is an ironically complex subject.
  • Some things can never be made simple.
  • Simplicity is a balance between multiple types of simplicity.
  • Reviews of the book are sharply mixed.

See also in this wiki: The Laws of Simplicity by John Maeda

MIT Press Description

Maeda's first law of simplicity is "Reduce." It's not necessarily beneficial to add technology features just because we can. And the features that we do have must be organized (Law 2) in a sensible hierarchy so users aren't distracted by features and functions they don't need. ... Law 9: "Failure: Accept the fact that some things can never be made simple."
Emphasizing the delicate balance-work involved in simplifying the complex, Maeda admits the process isn't easy, and that his ten laws don't necessarily provide all the answers-in numerous places. -- Publishers Weekly review

Critical Reviews Show That Simplicity is Not Simple

The ideas (read: bullet point-level detail) that Maeda begins to talk about show promise. However, he never describes them in sufficient detail ... The book reminds me of the quote "Make things just as simple as they need to be, but not simpler." This pretty book is an example of the truth in that statement. -- Amazon Review
This little book can be pleasant, even delightful. But if your interest is for more serious, robust exploration, then look elsewhere. The title is ... misleading. The term "Laws" suggest principles that can be universally applied and have been rigorously tested. This book is really more of a set of loosely connected essays about design approaches. -- Amazon Review
Meandering stream-of-consciousness stuff, without much by way of concrete conclusions. I found myself reading carefully to see whether I could extract a deeper underlying point to each of the chapters, then skimming a paragraph at a time, then flipping pages at an increasing rate... and finally setting it down, never to be picked up again. -- Amazon Review
Fluffy rather than profound. This book was okay as far as it went, which was not very far. ... the commentary on the laws was light and superficial rather than deep and provocative. -- Amazon Review
There's no essence really there, just high-level general statements. -- Amazon Review
Tufte's "Envisioning Information" is the book you should read, if you haven't already, dealing with *this* subject thoughtfully and usefully. It feels like Maeda wanted to sink his design fangs into simplicity but while writing decided to save his teeth.

I found the insights illuminating at times, and a bit thin or frustrating at others. ... I think it's a worthwhile read, and I'll probably go back through again to distill it better (NOT an example of simplicity!), but it's brevity just doesn't allow for a full realization of the concepts.
To follow Maeda's meme of comparing his ideas with little bits of Japanese culture: the book is a bit like Miso soup -- a tasty prelude to something with real substance.

Software Design

If you want design to be simple, it must be a goal. It won't happen accidentally when more than a few hands get involved.

How do you know when it's simple enough? There's an empirical test. Write down rules, give them to a fresh newcomer of mean ability and intelligence, and see if they can apply and defend them in various cases — especially when attacked by a bright lover of complexity. Your average practitioner should be able to say, "The simple rule here dictates solution X to your wicked problem Y." You did it right when this [agreement] can occur. You did it wrong when it requires an expert to adjudicate normal discussion.

It's a design smell if any part requires an expert to grasp. Another design smell: you grasped it last week, but not today.
: http://lambda-the-ultimate.org/node/4852

Comments: The test brings to mind the principle of 'simple as possible, but no simplier'.

Criteria for a Simple System (Evolutionary Development, Test Driven Design)

In order (most important first):

  • Runs all the Tests
  • Reveals all the intention
  • No duplication
  • Fewest number of classes or methods

Software Expert Martin Fowler on Simplicity

Only if you have [the enabling practices of unit] testing, continuous integration, and refactoring can you practice simple design effectively.
But you have to ask yourself if the resulting code is really simple. For me it is, but then I'm familiar with the Decorator pattern. But for many that aren't it's quite complicated. Similarly JUnit uses pluggable methods which I've noticed most people initially find anything but clear. So might we conclude that JUnit's design is simpler for experienced designers but more complicated for less experienced people?
I think that the focus on eliminating duplication ... is one of those obvious and wonderfully powerful pieces of good advice. Just following that alone can take you a long way. But it isn't everything, and simplicity is still a complicated thing to find.

Less is More is Difficult

Essential Schools: 'The toughest to explain and live by'

PRETTY MUCH EVERYBODY agrees: "Less Is More" is the toughest of the Coalition's Nine Common Principles to explain and to live by. What does it mean? (An array of possibilities worthy of an old-style multiple-choice test springs all too easily to mind-reading fewer books, spending less time in school, perhaps even doing less homework?) Does it advise teachers to spend less time on some things and more on others? If so, what goes and what increases-and what effect do those changes have on student achievement?

Toughest to Explain: Translations

  • Abstract. Not fully formed.
  • Not actionable. Perhaps self contradictory.
  • Over-simplified, unfounded.
  • A prevarication - avoids telling the truth by avoiding the issue. A canard.
  • A complex topic being hidden by a seemingly simple phrase.

Constraints Force Creativity

Less is Often More?

One of the strangest phenomena studying foreign intervention in small wars is to examine what happens when the intervention force is constrained by force size and resources. In this case, the commanders are forced to adapt, and the result is often a period of deep-reflection, ingenuity, and creativity.

The most notable modern successes are El Salvador, Colombia, and the Philippines. In these cases, Special Forces were forced to adopt a "by, with, and through" mentality. They had to work with the security forces and political leaders. They could not bypass. As some of the evidence in both Iraq and Afghanistan would suggest, left unconstrained, Special Forces would prefer to act unilaterally choosing direct action over advising.

'Less is More' ... Sometimes

Less is More vs. Sometimes Less is More.
sometimes less is more. In other words, sometimes you want to dig deep into commentaries or resources that will examine an issue in depth, but at other times you just want a little quick exegetical help. At those times, the more concise the treatment of a passage, the better.

'Less is More' in Architecture

Reducing everything down to the purest, most elegant form is difficult, and only a truely gifted Architect can achieve that level of perfection, ...

Removing all the clutter, and the contradictions, and the character, and the color, and the messiness, and the struggle, and the inconsistency, and the uncertainty, and the imbalance, just to reveal an underlying structure, and an order, and a harmony, and a calm, centered peace…, is a disservice to our humanity.

Like replacing a beating heart with a thick block of glass.

But, Architects continue to strive for that perfection, and we continue to enlarge the divide between what we want and what is wanted, and I think we may have missed the point of what we were trying to do in the first place.

So, stop it.

Less is not more.


Physical Exercise

20 years of research — and especially the last 10 — have shown that less is not (much) less and that many people can probably get surprisingly good results with fewer and shorter visits to the gym.
training frequency could be significantly reduced with minimal sacrifice in results. ... Every available experiment shows basically the same thing: across the board, low frequency training got the same or at least surprisingly good results as higher frequency.


'Staying In Your Lane'

Key concepts: Value of defined roles, negotiated agreements, unilateral decisions.

Some self care activities are less obvious, like developing awareness about your individual patterns of thinking, feeling and behaving, as well using these insights to make adjustments to the way you look after yourself.
One other important aspect of self care that may appear less obvious--and consequently receive less attention--is what’s commonly referred to as boundaries, or put more simply, “staying in your lane.” What does this mean?
“Staying in your lane” means doing your part, and only your part. Paradoxically, doing more may actually leave you with less. Consider this typical situation: you complete assigned tasks on a shared work project ahead of schedule, and, without discussing it with your team, take charge of tasks assigned to a co-worker. You’ve done a lot, so where is that sense of accomplishment? That job well-done feeling you expected? Why don’t you feel good?
Think about it. You’ve done more than you should have, so perhaps you’re tired and depleted—this is the “less.” You may also feel resentful because you did more than others on a shared project, a decision you made unilaterally. And you didn’t consider your colleagues, who may well have less-than-happy feelings about this. You did not “stay in your lane.”
In moving into your co-worker’s lane, that person also gets less: the lost opportunity to contribute to the project and experience the sense of accomplishment consequent to a job well done. Moreover, perhaps your co-worker feels criticized or devalued, not held in high esteem. He or she may also feel irritated and annoyed by your appropriation of their role; esteem for you is diminished. Voila! Neither of you feel good.
The above is an experience frequently discussed by folks in my psychotherapy practice.

Comment: The author could also have noted that:

  • Other people may do the work 'in their lane' more efficiently, effectively, and better (of higher quality) than you.
  • You may be re-inventing the wheel -- repeating work already done by others.
... all relationships in every area of your life require defining a lane, and this is often a collaborative experience. The assigned tasks on a work project are the defined lanes initially negotiated, and to which all have agreed. Self-care entails defining your lane, as well as not crossing out of it or merging into that of someone else.
I love driving and so please indulge me for a moment in keeping with the driving metaphor here. Think of appropriating your co-workers’ tasks without explicit agreement as merging into another traffic lane without using blinkers to alert your fellow motorists. I think it’s easy to see how things can go awry there--and quickly!

This page is not linked to the broader wiki. The __NOINDEX__ magic word is used to request that external search engines not index this page.

This transformation benefited from a philosophy of “less is more” in all areas of the business.