The Lost Art of Simplicity
•Download as PPTX, PDF•
21 likes•8,866 views
Simplicity is a lost art in the application development space. The Wikipedia definition of Simplicity is “Simplicity is the property, condition, or quality of being simple or un-combined. It often denotes beauty, purity or clarity. Simple things are usually easier to explain and understand than complicated ones. Simplicity can mean freedom from hardship, effort or confusion.” This is a beautiful statement that we often lose sight of when we are building our applications. Instead we are on a never ending quest to fill out a checklist of features or to build something clever forgetting about the actual needs of our users to get a specific task done. This session takes complexity to task and challenges you to bring simplicity to the center of your development with some straightforward ideas and guidance. Full writeup of the presentation and patter at http://sn.im/lostartofsimplicity
Recommended
Recommended
More Related Content
What's hot
What's hot (18)
Viewers also liked
Similar to The Lost Art of Simplicity
Similar to The Lost Art of Simplicity (20)
More from Josh Holmes
More from Josh Holmes (20)
Recently uploaded
Recently uploaded (20)
The Lost Art of Simplicity
- 1. The Lost Art of SimplicityJosh Holmesjoshholmes.comjosh.holmes@microsoft.com
- 2. sim·plic·i·ty (sm-pls-t) n. 1. The property, condition, or quality of being simple or uncombined. 2. Absence of luxury or showiness; plainness. 3. Absence of affectation or pretense. 4. a. Lack of sophistication or subtlety; naiveté. b. Lack of good sense or intelligence; foolishness. 5. a. Clarity of expression. b. Austerity in embellishment.
- 3. Simplicity is an acquired taste. Mankind, left free, instinctively complicates life - Katherine F. Gerould
- 4. I adore simple pleasures. They are the last refuge of the complex. - Oscar Wilde
- 5. Our life is frittered away by detail. Simplicity, simplicity, simplicity! - Henry David Thoreau
- 6. Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction. - Albert Einstein
- 7. Most of the fundamental ideas of science are essentially simple, and may, as a rule, be expressed in a language comprehensible to everyone. - Albert Einstein
- 8. It takes a long time to make something complicated simple, but if you do, it will work w/o problems for a long time. - F. Andy Seidl, http://faseidl.com/
- 9. The Innovator’s Dilemma that disruptive innovations are almost never the result of technological breakthroughs but are instead recombinations of existing and often inexpensive technology in forms the former market leaders don’t pursue. - Clayton Christensen
- 10. Dealing with complexity is an inefficient and unnecessary waste of time, attention and mental energy. There is never any justification for things being complex when they could be simple. - Edward de Bono
- 13. "Think simple" as my old master used to say - meaning reduce the whole of its parts into the simplest terms, getting back to first principles. - Frank Lloyd Wright
- 14. Simplicity is not the goal. It is the by-product of a good idea and modest expectations. - Paul Rand
- 16. Engineering
- 17. We need to be very careful about the lure of complexity. We should not fall into the trap of thinking that if it’s hard to design, it must be good; that if it’s using the latest technology, it must be good; that if all our friends think it’s really cool, it must be good. - Gerry McGovern
- 18. Programming without understanding how programming languages really work is like painting with the brush held between the toes of one foot - Steve Yegge
- 19. When thought is too weak to be simply expressed, it's clear proof that it should be rejected - Luc De Clapiers
- 20. I apologize for the length of this letter, but I didn't have time to make it shorter. - Mark Twain
- 21. Process
- 25. The whole point of human-centered design is to tame complexity - Don Norman
- 26. Things should be made as simple as possible, but not any simpler. - Albert Einstein
- 27. If you find yourself talking more than walking, shut up, cut the vision in half, and launch it. You can always fill in the gaps later. - Jason Fried
- 28. Never again will I make the simple into the complex. Something of true value does not become more valuable because it becomes complicated. - Donald Curtis
- 29. The whole is simpler than the sum of its parts. - Willard Gibbs
- 32. Simplicity is not only a function of intuitive design, but also tailoring the design so the application is the right tool for the job- Scott Karp
- 33. Aesthetics
- 34. When you are around accomplished craftspeople for any period of time, you start to notice how easy their work seems to be for them. You also notice that they have a lot of tools, many of which you've never seen before, all of which seem perfectly suited for the task at hand. I’m often struck by the elegance of their function and how simple and well suited both to the task and to the individual doing the task they seem. - Dennis Kennedy
- 35. The ability to simplify means to eliminate the unnecessary so that the necessary may speak. - Hans Hofmann
- 36. Making the simple complicated is commonplace; making the complicated simple, awesomely simple, that’s creativity - Charles Mingus
- 37. The challenge for designers is straightforward, if somewhat easier said than done: Give customers the features they need, presented in a way that makes the easy tasks obvious and the complex tasks simple to discover when you’re ready to handle them. - Josh Clark
- 38. Remember that at the root of all complex problems lies a simple solution. - Luke Wroblewski
- 40. The first requirement for an exemplary user experience is to meet the exact needs of the customer, without fuss or bother. Next comes simplicity and elegance that produce products that are a joy to own, a joy to use. True user experience goes far beyond giving customers what they say they want, or providing checklist features. - Nielsen Norman Group
- 41. Go confidently in the direction of your dreams! Live the life you've imagined. As you simplify your life, the laws of the universe will be simpler. - Henry David Thoreau
- 42. All artwork used in this presentation is licensed under Creative Commons by Frits Ahlefeldt, aka hikingartist Support his amazing craft at http://hikingartist.com
- 43. The Lost Art of SimplicityJosh Holmesjoshholmes.comjosh.holmes@microsoft.com
Editor's Notes
- Let’s start off by talking about what simplicity is. The official dictionary definition has 5 parts. We are going to focus in on the first definition. Simplicity is the property, condition or quality of being simple or uncombined. This is a beautiful statement that is unfortunately missing in much of our current application development. When we talk about something being simple, often people just right to the fourth definition assuming that it’s lacking sophistication or good sense and intelligence. That it’s foolish. As technologists, our tendency when we see something that’s simple is to say “Oh, I could write it in a weekend”. There’s a fair amount of NIH (Not Invented Here) tendencies that are just part of our culture. This is a dangerous concept. The last definition is the one that I really like. To have a something that has “Clarity of Expression” is awesome. Put that with the first definition and we really have something. I’m striving to solve problems in ways that are “Simple and uncombined” with “Clarity of Expression”. http://hikingartist.com/Peopletypes_g54-King_type_p124.htmlhttp://www.thefreedictionary.com/simplicity
- One of the great things about the human race is that we are a race of problem solvers. And we take great pride in our solutions. The issue is that the solutions that we are most proud of are the ones that only we can understand. The best ideas, however, are the ideas that are immediately obvious once someone shows it to you. It’s that head smack “Duh” moment that accompanies those great ideas that I really like.http://hikingartist.com/animals_g58-evolution_p60.html
- Let’s use the example of this guy dreaming about having that apple for lunch… It’s a fairly simple problem on it’s face. We, as IT folks, get the IT equivalent of this issue day in a day out. http://www.flickr.com/photos/hikingartist/3010374978/
- Can I get report of sales by geography? How about splitting that by demographics such as age or gender? What’s the effect of our current marketing efforts on sales of our latest line and how does that differ by geography or demographic? Could I enter a contact I met at the picnic into our CRM? Could that be blue? http://hikingartist.com/Cartoon_illustration_g29-Still_want_that_apple__p262.html
- Our biggest fear is that the user is going to go get a copy of Access or something equally destructive and try to solve the problem themselves. Often they can effectively solve the short term problem and in the process bring down the enterprise… And this is a dangerous thing because as they open up the simple tools such as access and solve just their problem, they are potentially causing other issues like data redundancy throughout the company or duplicating efforts with another group. Often these solutions are even done with ignorance to larger concerns such as privacy laws. Even so, they are solving their problem in the short term and that was their goal. http://www.flickr.com/photos/hikingartist/3010374978/
- To head that off, we just, we start throwing our favorite technologies and designs at the problem to solve it in the most “elegant” way. This quickly results in over engineering the task at hand. One immediate and obvious danger is that we take that simple request and roll it into the next version of the application that’s going to be 18-36 months down the road ignoring the fact that it’s a pain that the user is feeling today. What happens when, 18 months down the road, the user that has requested that feature has solved the problem some other way? Or if that user is not even employed by the company anymore? http://www.flickr.com/photos/hikingartist/3010375012/sizes/o/
- And the solution that results is not only over engineered but it’s reminiscent of a certain coyote with all of the possible ways that it can fail. The reality is that the more complex a problem is, the more ways that it can fail. As a solution ramps up in complexity and “cleverness” it quickly becomes more fragile because there are more moving parts and more possible points of failure. Just because something is using the latest or coolest technology, doesn’t mean that it’s the best idea. If that latest or cool technology reduce complexity in some way, such as reducing the number of tools, streamlining process or raising the bar on the usability then there is a good argument to leverage it.http://www.flickr.com/photos/hikingartist/3009540065/
- In all of this, we are missing the obvious. There are known simple solutions to a lot of the requests that we get on a day to day basis. The first thing that we have to get over is the NIH complex that we all have. When you get a new request is your first thought, I can build that… Or is your first thought, I bet that’s been built… The second thing that we have to recognize is that the simple solution is probably the right one. If the solution that we have come up with is a so complicated that we are amazed with ourselves and proud of it, it’s probably the wrong direction. http://hikingartist.com/Cartoon_illustration_g29-Want_an_apple_p261.html
- We can’t keep down this destructive path of building more and more complex solutions that take eons to develop when the users have needs that we are not addressing in the short term. http://hikingartist.com/Cartoon_illustration_g29-Want_an_apple_p258.html
- We are living in denial that we are the problem. It’s our insistence that we are the technical gods and know everything that is driving this as a problem in the industry in the first place. http://hikingartist.com/Cartoon_illustration_g29-Not_to_be_disturbed_p398.html
- Ok. Now what? Where are we now and what can we, as mere cogs in the wheels, do to tackle this problem? http://hikingartist.com/Cartoon_illustration_g29-Short_term_solution_p408.html
- There’s, unfortunately, not a magic solution to the issue of complexity. Simple is hard. Often you have to come up with several complex solutions that you can boil down to the simple solution. Often, in an effort to find the right solution, I will solve or at least map out solutions to a given problem in several different ways with a number of technologies ranging from desktop to web to mobile to non-technology solutions. Kind of like going to a shoe store and trying on a ton of different styles and sizes of shoes, you can get a lot of interesting ideas from checking out all of the different solutions. You might be surprised by the solutions that make the most sense at the end of the day. http://hikingartist.com/Cartoon_illustration_g29-Wizard_type_3_p111.html
- All of that said though and as much as I’m talking about Simplicity in this talk, the reality is that Paul Rand has it right. “Simplicity is not the goal. It is the by-product of a good idea and modest expectations”. http://hikingartist.com/Motivation_g56-The_just_enough_Type_p116.html
- Out of the sea of ways to improve, I’ve picked three that I want to talk about today. First is Engineering. Second is Process.Last but definitely not least is User Experience. http://hikingartist.com/animals_g58-Hatching_type_p117.html
- Starting off with Engineering, we, as the IT world, tend to go rampant with technology with little to no thought to the consequences. Even though we are trying to make people’s lives easier, at best we do no harm. At worst, we cause a lot of pain and anguish for our users. The answer that a lot of us, and I’m guilty of this too, turn to is to vet our ideas and our UI designs with our peers. The issue is that our peers are also technologists who are just as geeked as we are about X new technology. This just perpetuates the problem. http://hikingartist.com/Peopletypes_g54-The_akward_type_p86.htmlhttp://www.gerrymcgovern.com/nt/2004/nt_2004_11_22_complexity.htm
- We need learn the fundamentals of programming. I once interviewed a fellow for a position as an architect. He had 14 years of experience as a technical lead in his shop and several years of experience before that in other shops and I was pretty sure, based on his resume that this would be a formality. But there was something that was unsettling about the interview and I couldn’t put my finger on it until I asked him what should have been on of my first questions – “What’s the difference between a class and an object?”. He couldn’t answer the question. That’s when I realized that he didn’t know the basics of OO. He had grown up as a COBOL developer and transitioned over to a position where the tools allowed him to be a productive programmer without understanding the underlying principles. This is not the tools fault, it’s his fault for not doing the due diligence to understand the work that the tools were doing for him. I differentiate between VB Users and VB Developers. Developers could use any tool in the box but choose VB because it’s more productive. Users point the data control at an Access database and think that they have a program. We need to get back to learning the fundamentals of programming. http://hikingartist.com/Cartoon_illustration_g29-Painting_strategy_p257.html
- http://hikingartist.com/Peopletypes_g54-The_engineer_p121.html- Luc DeClapiers - http://en.wikipedia.org/wiki/Luc_de_Clapiers,_marquis_de_Vauvenargues
- An unfortunately common problem that I see in the industry is that given group of developers knows one or two technologies and approach every problem with that technology as the solution. The reality is that that there are tremendous number of technologies at their disposal from web applications to desktop applications to mobile applications to hybrid solutions of all of those. You need to approach each problem with an open mind as to what is the best solution for that problem. Sometimes you’ll find that the solution is not actually a technical solution at all. The real solution here is to take the time to explore all of the possible solutions, technology based or not. http://hikingartist.com/meetings_g55-hammer_management_p129.html
- The next big thing that we need to talk about is Process. People tend to either skip over thinking about their process. http://hikingartist.com/relationships_g57-Consultant_p33.html
- But every once in a while, it is important how you accomplish the goals because the means to the end are as critical as the end itself. http://hikingartist.com/animals_g58-I_did_it_I_m_flying_p4.html
- http://hikingartist.com/Free_print_versions_g79-Blind_leading_the_blind_p745.html
- The processes that I favor are the ones that start and end with realizing that we write software for humans, not for computers. This is squarely in the camp with the agile methodologies. The idea is that not only do you start with the user, but you have the users sitting with you as you develop your application. Unfortunately, many people pay lip service to this concept but rarely actually practice it. I was recently in a long envisioning session with a customer about the next version of their client facing applications. We spent a lot of time hashing through their current application and came up with a number of ways that we might be able to save time or give a better experience. But at some point I backed up and asked the question, what are the top three things that your customers do with the application? If we knew that, we could focus on surfacing those to three tasks in the UI to help cut complexity and time out of the user’s day. The reality is that they couldn’t answer that question. There were some guesses and opinions thrown out but nothing definitive that they could throw out. Their homework assignment was to go back and find that out.I find this as an issue in a lot of customer engagements. Very few companies actually know how many of their users are using Windows 98 or IE5 but there is an assumption that it’s an issue so a lot of complexity is built into the system in order to accommodate what might very well be a small portion of their audience. The other side of this issue is that there’s what the users say that they want and what they actually need. There are some simple examples. “Could you Web 2.0ify my site?” “I need a X (where X is some buzzword that they just read in some article) technology application” Or any other place where technology enters requirements. This is where we need to redirect the user’s requirements by asking them about their goals and aspirations and then start figuring out what they need from that. “Oh, you want to cut down on the amount of text that your users have to type while increasing the accuracy of their reporting? How about we replace that block of text by allowing them to select a picture of what they are looking for? Yeah, we can do that without requiring them to wait on the page to reload.”http://www.flickr.com/photos/hikingartist/3208741909/sizes/o/
- Let’s take a short step back and examine how complexity comes to our applications in the first place. Often complexity sneaks in under different names. One of my favorite is “Enterprise” which almost automatically means a complexity multiplier of 10. The idea here is that we have to be “Enterprise Quality”. This implies a certain engineering rigor, stability and scalability. One huge issue that I have with this term is that if you look at a mid to large sized enterprise with 10k, 20k or even 50K users you are still looking at a user base that would be considered a rounding error on some of the larger consumer facing applications such as Facebook, Twitter, Wikipedia and the like. http://hikingartist.com/animals_g58-Trojan_trap_p106.html
- http://www.37signals.com/svn/archives2/simple_means_launching_something.phphttp://hikingartist.com/relationships_g57-The_coordinator_type_p82.html
- One of the biggest problems is that we try to, for a large number of reasons, try to boil the ocean with our applications. When we build out our project plan and it’s going to be an 18 month cycle before the users get a new version, they are going to go to battle tooth and nail to get their feature request on the docket because they know that if they are not able to get it in this release, it’s going to be at least 36 months out. All of these features crammed into a release adds not only a lot of complexity but a lot of risk to the endeavor. We have to get past the misperception that features equal value. Features do not equal value. Solving people’s problems equals value. The amount of complexity and risk that we add with these massive project plans hurt out ability to solve someone’s problem in a reasonable time frame. http://hikingartist.com/animals_g58-Fishing_type_p112.htmlhttp://en.wikipedia.org/wiki/Willard_Gibbs
- None of this means that I’m not solving complex problems. It just means that I’m layering simple solution on top of simple solution to solve those complex problems. http://hikingartist.com/Free_print_versions_g79-Building_bridges_p747.html
- http://www.hikingartist.com/Free_print_versions_g79-intricate_consensus_p602.html
- http://publishing2.com/2008/01/27/simplicity-drives-technology-adoption/Scott Karphttp://hikingartist.com/Cartoon_illustration_g29-Using_the_wrong_tools_p613.html
- http://hikingartist.com/Cartoon_illustration_g29-Alian_man_just_landed_p284.html
- You need to start small. Even if you know that the end game is far bigger, what’s that first step? What’s the minimal set of features that you need to get started? This is a struggle for a lot of people as we all want to go for the big vision. The natural tendency is to think that more is better but in a lot of cases, more just gets in the way of success. This is a core concepts that groups like 37 Signals have held. Their motto is that the first order of business is to get running and start building a customer base. You can worry about scaling later. But if you spend too much time worrying about scaling up front, you’ll never get out there to build the customer base in the first place. http://hikingartist.com/meetings_g55-Fools_can_t_you_see_the_bird..._p12.html
- On the other side of the coin, you need to have a clear concept of the future as you are getting started. I often see applications that are built with no concept future requirements and accidentally build in roadblocks to success. There are a lot of simple things that you can do that will future proof your application to some degree. It’s not hard to build in, if you start from the beginning with a tiered and separated architecture so that you can replace bottle necks if they start to pose a problem. This is sometimes a hard balance to hit but it’s an important one to tackle. There are a lot of straight forward things you can do such as adopting some of the great architectural patterns such as MVC (Model View Controller) or MVP (Model View Presenter) combined with great practices such as Test Driven Development (TDD). TDD is more than just building regression tests. It forces you to design and build your application in a modular fashion that allow you to make changes and modifications to your application quickly and with confidence. MVC and MVP are architectural patterns that work well with TDD and provide for great separation of concerns to further provide the agility that you need to grow and scale your application over time. http://hikingartist.com/meetings_g55-Not_quite_ready_p7.htmlhttp://en.wikipedia.org/wiki/Hans_Hofmann - who is Hans Hofmann
- http://www.lukew.com/resources/articles/pursuit_simplicity.htmlhttp://hikingartist.com/animals_g58-Looking_for_attention_p6.html
- http://globalmoxie.com/blog/design-simplicity~print.shtmlhttp://hikingartist.com/Free_print_versions_g79-Regrets_p753.html
- http://hikingartist.com/relationships_g57-Staying_in_the_box_p18.html
- So where to from here? As I look into the future, I see a world where we are working hand in hand with our users to solve their real needs rather than reacting to what they say that they want and confusing checklists of features with value. I dream of the day when we are able to respond to the users needs as quickly as we can get them to express those needs to us to the point of being able to forecast and proactively provide exactly the functionality that the user needs, nothing more, when they need and not a moment before they do. To do that, we need to forgo our egos, our love of complexity and our die hard grip on our favorite technologies and focus on the user. http://hikingartist.com/meetings_g55-The_observer_type_p135.html
- You call to action is to go to war against complexity. Stand up for simplicity. Take the extra time that it is going to take to build the uncombined solution that has clarity of expression. Don’t confuse simple with lack of sophistication. Focus on your user and their needs. As you do this. As you take on this challenge and “as you simplify your life, the laws of the universe will be simpler”. http://hikingartist.com/Motivation_g56-The_gatekeeper_type_p48.html
- Before I finish, I need to say a quick thank you to Fritz Ahlefeldt. He’s a Danish artist with obvious talent. He publishes a large amount of his work under creative commons. If you like this art, you can see much more at http://www.hikingartist.com and support him and his amazing craft.