In a column entitled "March of the Engineers," the humorist and social critic Russell Baker lamented the complexity and sophistication of his office's new telephone system...Baker closed his column by defining the new telephone system as "another bleak example of the horrors created when engineers refuse to leave well enough alone."
In The Design of Everyday Things, Donald Norman wrote that "new telephone systems have proven to be another excellent example of incomprehensible design."
A primary cause of complexity is that software vendors uncritically adopt almost any feature that users want. Any incompatibility with the original system concept is either ignored or passes unrecognized, which renders the design more complicated and its use more cumbersome. When a system's power is measured by the number of its features, quantity becomes more important than quality. Every new release must offer additional features, even if some don't add functionality.
Who advocates in the requirements process for the product itself—its conceptual integrity, its efficiency, its economy, it’s robustness? Often, no one. As often, an architect or engineer who can offer only opinion based on taste and instinct, unbuttressed as yet by facts. For in a classical Waterfall Model product process, requirements are set before design is begun.
The result, of course, is a grossly obese set of requirements, the union of many wish lists, assembled without constraints. Usually, the list is neither prioritized nor weighted. The social forces in the committee forbid the painful conflicts occasioned by even weighting, much less prioritizing.
Any attempt to formulate all possible requirements at the start of a project will fail and would cause considerable delays. — Pahl and Beitz, Engineering Design
As Project Manager, I had to reject the requirements document as totally impractical, and have a quite small team of architects, marketers, and implementers extract the essence.
Requirements proliferation must be fought, by both birth control and infanticide.
Niklaus Wirth of Pascal fame wrote a famous paper in 1995 called A Plea for Lean Software. His take is that “a primary cause for the complexity is that software vendors uncritically adopt almost any feature that users want”, and “when a system’s power is measured by the number of its features, quantity becomes more important than quality”.
First, and most importantly, it’s not the features that matter. You’re not going to create something people really love by making a big list of Slack’s features and simply checking those boxes. The revolution that has led to millions of people flocking to Slack has been, and continues to be, driven by something much deeper.
Building a product that allows for significant improvements in how people communicate requires a degree of thoughtfulness and craftsmanship that is not common in the development of enterprise software. How far you go in helping companies truly transform to take advantage of this shift in working is even more important than the individual software features you are duplicating.
People are afraid to let design have time to actually figure out the right thing to make, because "whatever will the engineers do?" – fuck you, there's plenty for the engineers to do. Go fix some technical debt. Go fix those 700 bugs that you de-prioritized or marked as won't fix because you're an asshole.
I'm sorry, I love engineers. I don't know why I'm yelling at them. But you know, there's plenty for the engineers to do. There's all sorts of cleanup. They can work on dev-ops stuff! They can work on their build process! Make it faster! I'm not worried about keeping the engineers busy. If you think that the only thing that engineers can do is build yet another stupid feature that nobody is going to use, then you're a garbage designer and you should quit.
The most important consideration for any software or web excursion is content: the content of the text and other communicative media, as well as the content of the code that executes the business processes. The ability to tick off a page or piece of functionality as being done only produces a nominal successful result; the careful crafting of what one of these objects says produces a real one.
Features don’t work, in the sense that they can be easily gamed. A brittle and perfunctory implementation, done quickly, is going to score more intramural brownie points over a robust and complete one. If the question is "does product A have feature X?" then the answer is yes either way.
Scrum does not say “only focus on output”, but, unfortunately, humans will optimize for what they measure.
If you worry about story points & hitting your estimations, that’s what is going to consume your attention. That is what you and your team will optimize for.
And that is the core critique of Scrum as it is practiced: That it focuses a product team’s attention so heavily on delivery — on building lots of features quickly & efficiently — that teams fail to focus on spending time to discover what the right thing to build is.
In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, “I don’t see the use of this; let us clear it away.” To which the more intelligent type of reformer will do well to answer: “If you don’t see the use of it, I certainly won’t let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it.”
Users are accustomed to a minimum of quality, and they expect that of all new products.
If our product does not [meet basic expectations of quality], people will automatically believe that it is a bad product and they will not take it seriously. It is not what they expect.
Hence my suggestion that the MVP has died and the MAP: Minimum Awesome Product was born.
Analytics apps don't tell you much about usage behavior. You might be able to see how many users performed an event, or how many times they did it. But none of the analytics packages out there are good at showing you how often people do things. Are they using to-dos once a week? Every day? Only signing into the app once a month but happily paying for years?
Time matters. You can't understand usage without time.
"Feature complexity is like surface area and quality of execution is like height. I want a base level of quality execution across all features. Whenever I commit to building or expanding a feature, I'm committing to a baseline of effort on the user experience."
There’s a distinction to make: The set of features you choose to build is one thing. The level you choose to execute at is another. You can decide whether or not to include a feature like ‘reset password’. But if you decide to do it, you should live up to a basic standard of execution on the experience side.
Features can be different sizes with more or less complexity, but quality of experience should be constant across all features. That constant quality of experience is what gives your customers trust. It demonstrates to them that whatever you build, you build well.
Glass looks and feels perfectly tailored to my photo sharing needs and expectations. For me it’s even better than pre-Facebook Instagram in the sense that it pushes me to select and share what I think are good photos (same as it happens with Flickr), rather than making me obsess with getting ‘the Instagram shot’ at all costs every day or multiple times in a day. It doesn’t cheapen photography like Instagram has done for years.
That’s why I hope Glass’s founders/developers will resist feature creep. Resist user objections like: I don’t think Glass is offering that much for the subscription price they’re asking. There are a lot of people who will gladly pay for having a cleaner, simpler, focused experience.
Whilst Feature Parity often sounds like a reasonable proposition, we have learnt the hard way that people greatly underestimate the effort required, and thus misjudge the choice between this and the other alternatives. For example even just defining the 'as is' scope can be a huge effort, especially for legacy systems that have become core to the business.
Most legacy systems have 'bloated' over time, with many features unused by users (50% according to a 2014 Standish Group report) as new features have been added without the old ones being removed. Workarounds for past bugs and limitations have become 'must have' requirements for current business processes, with the way users work defined as much by the limitations of legacy as anything else. Rebuilding these features is not only waste it also represents a missed opportunity to build what is actually needed today. These systems were often defined 10 or 20 years ago within the constraints of previous generations of technology, it very rarely makes sense to replicate them 'as is'.
Finding value is the result of enabling individual and group-level discovery attempts. It's not the result of everyone following one leader's gut.
What just happened is a new software product/feature was created that no customer wanted. This happens way too often. In fact, most hyper important software projects that must be done by date certain or else, have deep flaws that cause some variation of this phenomenon, flaws that include:
Not wanted - Company specified a solution to a problem that customers don't actually have
No Rarity - Company is pursuing an iKnockoff of existing products. The market already has two scaled competitors with working solutions, customers naturally spend budget on products that are already successful to avoid risk
Incorrect Packaging - Customers need a website, but the company created an iOS app instead
Incorrect Pricing - Customers need SaaS pricing, but the company created a shrink wrapped, on-premise solution with CapEx and maintenance agreements instead
How would you change this structure so that you could put a masonry brick on top of it without crushing the figurine, bearing in mind that each block added costs 10 cents? If you are like most participants in a study reported by Adams et al. in Nature, you would add pillars to better support the roof. But a simpler (and cheaper) solution would be to remove the existing pillar, and let the roof simply rest on the base.
A series of problem-solving experiments reveal that people are more likely to consider solutions that add features than solutions that remove them, even when removing features is more efficient.
The horizontal axis represents the investment the organization makes. As investment increases, the organization spends more resources on improving the quality (remember, Noriaka was a quality guy at heart) or adding new capabilities.
The vertical dimension represents the satisfaction of the user, moving from an extreme negative of frustration to an extreme positive of delight. (Neutral satisfaction being neither frustrated nor delighted is in the middle of the axis.)
It’s against the backdrop of these two axes that we see how the Kano Model works. It shows us there are three forces at work, which we can use to predict our users’ satisfaction with the investment we make.
Doing it right requires a different pace of working and a much broader thought process than “ok, let’s get this thing out the door.” Which is super tough because most workplaces place a huge emphasis on getting things out the door, and fast. Little agile tickets that are expected to be completed in micro sprints to me seem to be antithetical to doing it right.
In our cultural obsession with billionaire entrepreneurs we laud new features more than the maintenance and incrementalism work of making old features better and more accessible. Maintenance looks like red minus signs in the spreadsheet. New features look like green plus signs. New features look better on our LinkedIn profiles. New features have that pizzazz, baby.
When gardening, the building of planters and initial planting is a very short process. The majority of your time is spent nurturing and monitoring growth. I personally feel the struggle between maintainer work and new shiny feature work. I enjoy that new feature smell but I know that my day-to-day is more like a janitor on a boat mopping up someone else’s barf. In terms of metaphors, the gardening metaphor is certainly better, and it acknowledges that design and development still tend to be more creative endeavors.
Yagni originally is an acronym that stands for "You Aren't Gonna Need It". It is a mantra from Extreme Programming that's often used generally in agile software teams. It's a statement that some capability we presume our software needs in the future should not be built now because "you aren't gonna need it".
The lake was silent for some time. Finally, it said:
"I weep for Narcissus, but I never noticed that Narcissus was beautiful. I weep because, each time he knelt beside my banks, I could see, in the depths of his eyes, my own beauty reflected."
If he were to tire of the Andalusian fields, he could sell his sheep and go to sea. By the time he had had enough of the sea, he would already have known other cities, other women, and other chances to be happy. I couldn't have found God in the seminary, he thought, as he looked at the sunrise.
When someone sees the same people every day, as had happened with him at the seminary, they wind up becoming a part of that person's life. And then they want the person to change. If someone isn't what others want them to be, the others become angry. Everyone seems to have a clear idea of how other people should lead their lives, but none about his or her own.
"When you really want something, it's because that desire originated in the soul of the universe...And, when you want something, all the universe conspires in helping you to achieve it."
"'Well, there is only one piece of advice I can give you,' said the wisest of wise men. 'The secret of happiness is to see all the marvels of the world, and never to forget the drops of oil on the spoon.'"
There must be a language that doesn't depend on words, the boy thought. I've already had that experience with my sheep, and now it's happening with people.
He was learning a lot of new things. Some of them were things that he had already experienced, and weren't really new, but that he had never perceived before. And he hadn't perceived them because he had become accustomed to them. He realized: If I can learn to understand the language without words, I can learn to understand the world.
"I'm afraid that if my dream is realized, I'll have no reason to go on living.
"You dream about your sheep and the Pyramids, but you're different from me, because you want to realize your dreams. I just want to dream about Mecca. I've already imagined a thousand times crossing the desert...I've already imagined the people who would be at my side, and those in front of me, and the conversations and prayers we would share. But I'm afraid that it would all be a disappointment, so I prefer just to dream about it."
There was a language in the world that everyone understood, a language the boy had used throughout the time he was trying to improve things at the shop. It was the language of enthusiasm, of things accomplished with love and purpose, and as part of a search for something believed in and desired.
Yet the boy felt that there was another way to regard his situation: he was actually two hours closer to his treasure...the fact that the two hours had stretched into an entire year didn't matter.
It reminded him of the wool from his sheep...his sheep who were now seeking food and water in the fields of Andalusia, as they always had.
"They're not my sheep anymore," he said to himself, without nostalgia. "They must be used to their new shepherd, and have probably already forgotten me. That's good. Creatures like the sheep, that are used to traveling, know about moving on."
Maybe he was also learning the universal language that deals with the past and present of all people. "Hunches," his mother used to call them. The boy was beginning to understand that intuition is really a sudden immersion of the soul into the universal current of life, where the histories of all people are connected, and we are able to know everything, because it's all written there.
"Maktub," the boy said, remembering the crystal merchant.
In one of the books he learned that the most important text in the literature of alchemy contained only a few lines, and had been inscribed on the surface of an emerald.
"It's the Emerald Tablet," said the Englishman, proud that he might teach something to the boy.
"Well, then, why do we need all these books?" the boy asked.
Two nights later, as he was getting ready to bed down, the boy looked for the star they followed every night. He thought that the horizon was a bit lower than it had been, because he seemed to see stars on the desert itself.
"It's the oasis," said the camel driver.
"Well, why don't we go there right now?" the boy asked.
He had only one explanation for this fact: things have to be transmitted this way because they were made up from the pure life, and this kind of life cannot be captured in pictures or words.
Because people become fascinated with pictures and words, and wind up forgetting the Language of the World.
When he looked into her dark eyes, and saw that her lips were poised between a laugh and silence, he learned the most important part of the language that all the world spoke—the language that everyone on earth was capable of understanding in their heart. It was love.
...He had been told by his parents and grandparents that he must fall in love and really know a person before becoming committed. But maybe people who felt that way had never learned the universal language. Because, when you know that language, it's easy to understand that someone in the world awaits you.
He tried to deal with the concept of love as distinct from possession, and couldn't separate them...if anything could help him to understand, it was the desert.
...He followed the movement of the birds, trying to read something into it. Maybe these desert birds could explain to him the meaning of love without ownership.
He knew that any given thing on the face of the earth could reveal the history of all things...Actually, it wasn't that those things, in themselves, revealed anything at all; it was just that people, looking at what was occurring around them, could find a means of penetration to the Soul of the World.
"If what one finds is made of pure matter, it will never spoil. And one can always come back. If what you had found was only a moment of light, like the explosion of a star, you would find nothing on your return."
"And what went wrong when other alchemists tried to make gold and were unable to do so?"
"They were looking only for gold," his companion answered. "They were seeking the treasure of their Personal Legend, without wanting to actually live out the Personal Legend."
"The wise men understood that this natural world is only an image and a copy of paradise. The existence of this world is simply a guarantee that there exists a world that is perfect."
"The desert will give you an understanding of the world; in fact, anything on the face of the earth will do that. You don't even have to understand the desert: all you have to do is contemplate a simple grain of sand, and you will see in it all the marvels of creation."
"People are afraid to pursue their most important dreams, because they feel that they don't deserve them, or that they'll be unable to achieve them. We, their hearts, become fearful just thinking of loved ones who go away forever, or of moments that could have been good but weren't, or of treasures that might have been found but were forever hidden in the sands. Because, when these things happen, we suffer terribly."
"There was a time when, for me, a camel's whinnying was nothing more than whinnying. Then it became a signal of danger. And, finally, it became just a whinny again."