Here are the slides (as a PDF) and the 1-page handout for the speech I’m giving tonight at Agile SoCal. It’s entitled Simplicity Appreciation 101. (Note: These materials have been revised greatly since I debuted the topic at Code Camp last January.)
Tag Archives: simplicity examples
On Shortening Wait Times
According to The Laws of Simplicity by John Maeda, shortening wait times goes a long ways towards the appearance of simplicity. People hate to wait, and systems that make people wait seem more complicated than systems that don’t. So, for one thing, an engineer charged with improving the performance of a system would do well to first look at the places in the UI where the user is made to wait and optimize those areas, before moving on to areas where the user does not need to wait. Continue reading On Shortening Wait Times
Simplifying User Requirements
It’s often said that one of the virtues (and challenges) of an organization adopting an agile methodology is that it will highlight existing dysfunctions. (The challenge being not to shoot the messenger.) One of the dysfunctions that typically, quickly surfaces is how user requirements can get overly complicated. In an environment that relies on written specifications that are “thrown over the wall” it’s the natural tendency of everyone involved to be as thorough as they can be. And who can blame them? In one respect, it’s their job to think of every contingency and bring all of their experience to bear. Working in a vacuum, it’s only natural to want to err on the side of caution.
Unfortunately, this all too often means that a requirement statement will take on a life of its own. As it evolves and gets fleshed out, the original reason or impetus for the requirement becomes clouded. It is barely retained through implication, if at all.
Allow me to illustrate… Continue reading Simplifying User Requirements
Simplicity Appreciation 101
If you happen to be near Raleigh, NC on December 7th, I’ll be speaking at the local Agile developer’s group while I’m out there on business. The title of my speech is “Simplicity Appreciation 101,” and here’s the synopsis…
Update: Due to a scheduling conflict, I was not able to deliver this talk in Raliegh, but I did present it at the Fullerton Code Camp on January 29th. The slides are available for download on the Downloads page.
Complexity is insidious. It creeps in and takes hold and doesn’t let go. Time and again, we see major undertakings fail due to overwhelming complexity. That’s why proponents of Agile methodologies all tout the virtues of simplicity. “Do the simplest thing that works.” “YAGNI.” “KISS it!”
But what exactly is “simplicity?” Can it be dissected and described? In many ways, simplicity is ethereal and personal, gleaming only in the eye of the beholder. But, yes, it can be broken down and viewed with an objective eye. In this presentation, we’ll explore dozens of examples of simplicity from the realms of software development, business enterprises, and life, in general. We’ll look at specific cases of simplifications as well as tools and techniques recommended for achieving simplicity.
Our starting point will be ten observations about simplicity by an MIT professor named John Maeda. In his book, “The Laws of Simplicity,” he describes how simplicity relates to size, time, context, emotions, trust, and more. These revelations alone provide a solid foundation for making better decisions to achieve simplicity, but, time permitting, we’ll also consider the nuanced wisdom of Albert Einstein, Mark Twain, Winston Churchill, and others.
For further information about this event, see the group’s MeetUp page: http://www.meetup.com/agileRTP/
This Simplification is a Lifesaver (literally)
Somebody at the American Heart Association figured out that, in most cases, CPR can be just as effective if only the heart-massage part is done, without the breathing part, and that hands-only CPR is WAY better than doing nothing. So, they’ve launched a campaign to spread the word, complete with how-to videos and smart-phone apps. See http://handsonlycpr.org/.
This is a drastic simplification, and there’s a big lesson in this for us Agilsts. Continue reading This Simplification is a Lifesaver (literally)
Lessons in YAGNI
YAGNI stands for “You Ain’t Gonna Need It” (yet). It’s a mnemonic meant to remind us developers not to speculate. That we should only put in code that addresses the task at hand and worry about tomorrow’s challenges tomorrow. There are many good reasons for this advice, the chief among them being that situations may change between the time that the speculative development happens and the need for the feature actually arises. In that case, the speculative development will turn out to have been wasted development time that could have been spent on addressing more immediate problems.
I thought I had learned this lesson years ago. I thought I was pretty sensitive to YAGNI and had a good track record for resisting it. But, recently I introduced a bug in a system that I was working on, and the ultimate reason for the bug is that I had committed the “crime” of speculative development. Continue reading Lessons in YAGNI
“Why are manhole covers round?”
The famous Microsoft interview process (as described by William Poundstone in "How Would You Move Mount Fuji? Microsoft’s Cult of the Puzzle…") asks the candidate, among other things, to solve puzzles such as the quintessential question, “Why are manhole covers round?” It’s a question with multiple answers (see below), and the interviewer is looking for how the candidate approaches the question more than what answers are givens.
I view this question as a quintessential example of simplicity. Continue reading “Why are manhole covers round?”