Why software sucks (And what to do about it) All the following is attributed with appreciation to Scott Berkun http://www.scottberkun.com/essays/essay46.htm First, people only complain about things they care about. How people respond to things: What is this for? I have it but haven’t tried it often. This sucks. This is acceptable. This is cool / I love it. This works so well I don’t even think about it.
One common reason for suckage The creator wants to share with the consumer their world, the internal world of how it works Creator: I love the power of Unix/AH\JAX/C#/whatever Consumer: I want to finish my work and go play.
Translation table for “this sucks” This doesn’t do what I need I can’t figure out how to do what I need This is unnecessarily frustrating and complex This breaks all the time It’s so ugly I want to vomit just so I have something prettier to look at It doesn’t map to my understanding of the universe I’m thinking about the tool, instead of my work
Translation table for “this doesn’t suck” Responses to good software: This satisfies my needs I can figure out how to do what I need This is smooth, seamless and fun This never fails It’s beautiful It is based on my understanding of the universe I think about the results I want, not the tools
How does good happen? A combination of skills are needed For example, interaction design, SW engineering, QA, product planning/strategy, visual design, project management… Berkun’s 1st Law: If you don’t apply the right skills at the right time, you will make things that suck
The Learning Curve Myth Best designs require no learning curve. A good Learning Curve: The design returns value beyond the “cost” of learning. The design matches the learning curve expectations of the user. Designers determine to steepness and length of the learning curve.
The expectation gap Berkun’s 2nd Law: No matter what you do, someone, somewhere will think your software sucks. The larger the user community, the more complex the expectations. If you are trying to help people, or make something for others to use, you are obligated to study their expectations.
Goodness is fragile (assuming you care about being good*) Even with good intentioned people, decent resources, a reasonable plan, keeping things together and on track is amazingly hard. What’s out of your control? politics/people, miscommunications, unavoidable complications, frustrating setbacks, disruptive competitors, bureaucratic firestorms Stuff happens * Not caring means you wouldn’t notice one way or the other
Construction vs. Design A process that explores different perspectives on the work, business, engineering, aesthetics, customers, the environment and integrates them into a plan, or a direction for a plan. CONSTRUCTION Construction is the act of building things with technology.
Two mindsets DESIGN-centric CONSTRUCTION-centric Starts by figuring out the experience and after it has some shape, available technologies are used to make that experience real. CONSTRUCTION-centric Starts with the technologies first and figures out the desired experience later on. Without design, construction can go wherever it pleases, without regard for anyone but the creator.
Berkun on Computer Science Taught from a construction mentality. Aspects of design are covered, but at the internal level. Design of object models Data structures and networks … not at the level where the technology meets the world. His conclusion… a CSc degree increases the odds of suckage.
Berkun’s suggestion on what to do It’s up to leaders and managers to decide which skills are important to figure out when and how to use them. For programmers working alone, they are the leaders. For teams, there are probably (hopefully) leaders who can define what matters and what doesn’t.
How does “good” happen? Think like the creators (not the user) and ask: How did they do this? How much time did it take them? What techniques did they use? How many people were involved? How did they engineer it to achieve the effects it has? What training did they have? How much of the engineering is even visible when I use it? What makes it so good? Why can't I stop looking at it, using it, sleeping with it, or rubbing it all over my body? How did it work so well that it did so much for me without me even thinking about it? What were they trying to do? Were they happy with the result? How do they see it? How would I have made something like this? What other creators do I know and how do they respond to this thing? How does the rest of the world respond to this thing? Why is their response different than mine?
Read!!! The Design of Everyday Things, Don Norman. Most well known UI design and human factors book in the world. It serves as a fantastic introduction to thinking about the mental processes people use to interact with the world and breaks down why many objects are so prone to causing frustration. It's well written and filled with pictures. The Elements of Friendly Software Design, Paul Heckel. The perfect companion to design of everyday things, since it focuses on how to approach things from the creator's view, not the analysts view. It's a hidden gem. Flow, By Mihaly Csikszentmihalyi . Here is the best reading about what's going on when you get lost in your work or play. Good software has the same effect, helping people get lost in the experience instead of struggling with the tools. Digital Woes: Why we should not depend on software, Lauren Weiner. Collection of stories about why software failures, of various kinds, are inevitable. Written for a lay audience and a better read that other similar books I've read. The Inmates are Running the Asylum, By Alan Cooper. It excels at capturing many of the underlying reasons bad things are made, breaking down how technologists and businessmen can allow their biases to get in the way.