Just as container ships can carry more cargo because they use a standard form factor for storing the cargo, software containers can run more apps on each server by using a standard way to share the operating system without all the wasted overhead of virtual machines.
- Containers bundle together all the pieces you need to run the app into one package.
- Containers make it easy to deploy apps to local servers and the cloud.
- Docker makes it easy to create containers.
Also check out Steven J. Vaughan-Nichols’ What is Docker and why is it so darn popular?.
Whenever I feel downtrodden and powerless I channel my inner Edna Mode and imagine it’s me, not Elastic Girl, she’s whacking over the head…
Confront the problem!
Thanks in advance for beta testing my new podcast. I’d love to hear what you loved and what you think sucked. You can email me at victor (at) victorlombardi.com.
Subscribe to the audio version on iTunes
Listen online on SoundCloud
Watch the video on YouTube, or right here…
One reason I love bouldering is that it’s game-like. No matter how much experience a climber has, we’re all at a certain level with certain climbs (they’re actually called “problems”) that currently challenge us. It’s like playing a well-crafted video game: the levels you’ve finished are easy, the levels ahead of you are frustratingly hard, but the level you’re currently on is a good match of difficulty for your skill level; and you can feel the flow.
I recently started learning a new programming language and I find it similarly game-like. Every new technique is a new challenge. Every new algorithm is a new challenge. The easy stuff is boring, the crazy theoretically stuff is frustrating, but the next chapter in my book is just right.
And like video games, in bouldering these problems are codified. So I can say, “I can do all the V0’s in this gym, and I’m working on the V1’s” and other climbers know something about my abilities.* Codified problems exist elsewhere too. Here’s some to help people improve their skills playing Go.
I’d love to see graded problems for interaction design. They would make it fun to solve problems, alone or socially, and communicate to each other our level of ability. “But Victor,” you might say, “interaction design problems don’t have a defined solution like a boulder.” Actually the boulders don’t either. People can solve the same problem different ways, but there are rules everyone must follow that give the game useful constraints. As long as you follow the rules and get to the top you’ve solved the problem. Some climbers are more elegant than others, and the same would be true in interaction design.
* The Moonboard is like graded problem-meets-Github, a single wall with over 800 bouldering problems contributed by various route setters.
Why We Fail is available in eBook form at O’Reilly and all the reviewers there gave me 5 stars! Yay!
Paul in Austin writes:
The case studies alone provide an very interesting read to anybody who has some interest in technology in general.
Each case study has been thoroughly researched with plenty of references. The author also provides video clips to help the reader visualize the user experience of the discussed products.
In addition to user interface developers or designers, product managers and architects will also benefit from the methods for avoiding future UX failures described in the second half of the book.
BOTTOM LINE Yes, I would recommend this to a friend
Ken in Hoboken writes:
Too many books focus on success but I feel the best way to learn is by studying failures.
Prior to reading “Why We Fail”, the only other book I read along the same lines was “Billion Dollar Lessons: What You Can Learn from the Most Inexcusable Business Failures of the Last 25 Years” by Carroll & Mui.
I am an engineer, not a designer, but I often consult on projects where no UX person is hired, forcing me to assume that role in some fashion. I found this book to provide great insights that I would not have otherwise considered.
For example, as an engineer, I focus on meeting the user requirements, but the case study on the failure of the Microsoft Zune music player (Chapter 5) demonstrates how much more powerful the user experience is over the feature set.
I found it an eye-opening revelation in Chapter 9 that Microsoft’s many expensive failures is due to its practice of sweeping mistakes under the rug and never sharing experiences with their product groups.
Chapter 7’s discussion on ethics is a valuable addition to the material.
I highly recommend this book.
BOTTOM LINE Yes, I would recommend this to a friend
I had a five-minute conversation with an angel investor last week and described the product I’m working on. His response: “Similar things are being done by bigger companies with giant marketing budgets, so you’ll need a very clever marketing idea to succeed. What is it?”
There was an uncomfortable pause. On one hand, I haven’t thought up any great marketing ideas yet and wondered if that was a hole in my plan. On the other hand, I was pretty sure this investor and I had very different perspectives on product development, but I didn’t have the language to succinctly express that gap.
I did understand what he meant. A few years ago I managed a large online dating service. We radically updated the design and added great features, but it was the online marketing that kept the revenue coming in. Why? I believe that while the design was good, the product wasn’t positioned to differentiate it from the competition. By contrast, if you design a product that’s different and more exciting than the competition, like the Anki DRIVE, there will be a lot more free media exposure and word of mouth to complement paid marketing.
My downfall, I think, is that I was trying to tell this investor about the product rather than show him. If my new and improved positioning is a result of product design, I need to show the product. For example, if I verbally described the Anki DRIVE as, “a racing game that combines an iOS app with physical race cars” that’s sounds mildly exciting. Watching the video is so much better…
As I write this there’s a group of about 15 developers and designers standing near my desk in a heated but constructive argument about how to check the design is right before the code heads off to QA.
Occasionally the dichotomy of agile vs. waterfall is raised, and sometimes “agile” is used as a euphemism for “flexible” as in, “well, there was an update in design document X, and we’re agile, so you should be able to integrate that.”
If there’s one thing I’ve learned from doing agile it’s that agile ain’t wishy washy, i.e. it’s not really some sort of flexibility nirvana. Any software development process relies on firm lines drawn around what, when, and how the work gets done. Otherwise, shit don’t get done.
Yes, agile is better at responding to change. But it is effective, somewhat counterintuitively, because it responds to change with a high degree of rigidity. For example, if the stories aren’t written in a way that makes it clear to developers how to code a feature and how to test it, it doesn’t get accepted into a sprint. Once stories are accepted into a sprint nothing else can start until the next sprint. And so on. When I first encountered all this rigidity I thought the developers were acting like self-involved prima donnas. Actually, they’re just enforcing the rules that make the process work.
Agile responds to change, not wishy washiness.
For over seven months I’ve been working with the good folks at Alexander Interactive on some ambitious work for MetLife. Here’s a peek into that work with a focus on process.
I’m the guy at the whiteboard in the Tokyo board room on page 73 :-)
A benefit of being a speaker at Failcon was getting an invitation to a talk hosted by Anit Guha of Orrick Legal. Here’s some of his wisdom that I noted down:
- When choosing a name use the uspto site and a 3rd party search service
- Avoid incorporating in California; use Delaware C Corp. Not only because of the company-friendly laws in DE, but because everyone incorporates there so everyone is familiar with the legal aspects involved.
- Founder vesting: vesting important if someone leaves. Typical is four years with a one year cliff, maybe some acceleration too. Can backdate the start of vesting if significant work was done before company was formed.
- Worker classification: consultants vs employees; employees involve more overhead. But you must follow legal definition, state and federal laws when bringing someone on (you can’t avoid the employee overhead if the person is actually working as an employee).
- Invention assignment – very important that everyone signs and agrees that ideas and inventions belong to the company; it’s pretty broad, it’s negotiated individually
- Use offer letters for everyone
- Use release agreements for involuntary terminated employees. They can refuse to sign; you need to pay them to make it enforceable.
- Investor “finders” must be a registered broker dealer, otherwise you can’t pay them for that service.
- Rule 701 disclosure obligations, options valued over 5 mil in 12 month period should be disclosed.
- Only raise from accredited investors.
- Taxes at acquisition can lead to a liability if you’re not careful.
While I was researching my book Why We Fail: Learning from Experience Design Failures I spent some time reading about people’s experience with RealNetworks, particularly the RealPlayer, and wondering if they were worthy of inclusion in the book, particularly the don’t be evil chapter. At that point there was no smoking gun, no hard evidence that Real intentionally did the wrong thing.
But this week a story was published which confirmed my suspicions. It’s called The Graph That Changed Me. Here’s an excerpt:
One day my manager showed me a horrible graph. It was pretty simple: the graph was steady, then it dropped straight down, then after a short period, the line shot straight back up and stayed level again:
Artistâ€™s rendering of why you probably donâ€™t like RealPlayer much
â€œThatâ€™s what happens when we do the right thingâ€, he said while pointing at the drop, â€œand thatâ€™s how much money we lose. We tried it just to see how bad it was for our bottom line. And this is what the data tells us.â€
â€œWow,â€ I said, taken aback. My employer clearly had two options: â€œdo the right thingâ€ or â€œbe profitableâ€. That was the position they had maneuvered themselves into through a series of bad management decisions.
That “series of bad management decisions” may involve a slippery slope of subtle temptations and minor rationalizations, not one big bad decision to be evil. But having been there I know it’s all too easy to fall into the trap of binary thinking. You can hear it in that story:
two options: â€œdo the right thingâ€ or â€œbe profitableâ€.
Design thinking is abductive, inventing new options to find new and better solutions to problems. In the universe of all possible businesses, were there more options than just â€œdo the right thingâ€ or â€œbe profitableâ€? Of course. We just need to be willing to try harder, apply our creativity, and make “do the right thing and be profitable” two constraints of the design problem.
Love this Steve Jobs story:
…Jobs turned around Apple and did it pretty quickly. He did two primary things as far as I can tell. First, he got his people into the top jobs and got rid of the executives who had been calling the shots before he showed up. And second, he brought focus to the product line, and thus everything else.
There’s this great scene in the book where Jobs draws a classic four quadrant chart, consumer and pro on one axis, desktop and laptop on the other. And he says “we are going to make one computer for each quadrant and we are going to kill all of the other product lines”.
Rosenfeld Media asked me my opinion of Amazon’s idea to use drones to deliver packages. Here’s a short excerpt from the interview:
Say what you will about Jeff Bezos, the man knows how to touch off a media storm. Which is precisely what ensued after Bezos told 60 Minutes that Amazon is testing the use of drones to deliver goods. Immediately, everyone was discussing the prospect of ordering a box of tissues from Amazon and having a drone arrive at your doorstep in half an hour.Â Weâ€™ve asked some Rosenfeld Media experts to join the fray on this audacious idea.
Itâ€™s a longshot that this will ever happen. Â But letâ€™s imagine for a moment that Amazon pulls this off. Â A terrible road to go down, or awesome?
Victor Lombardi: The danger is in trying to answer this question using reason rather than experimentation. And thatâ€™s because drone package delivery is so new we have no idea if itâ€™s awesome or not. To find out, we need to test it. The reason we fail to get these things right is because we fail to treat them as experiments. We fall in love with ideas, with visionaries, with progress for the sake of progress. And that leads to failure.
Read the the full interview at Rosenfeld Media.
This blog has been quiet for so long because I’ve been working on my first book, and it’s finally published. Why We Fail: Learning from Experience Design Failures is about websites and consumer electronics that were successfully launched and hailed as great designs, but failed unexpectedly when people used them, plus my attempt to explain why that happened and what people who make them can do to avoid failing.
As I work on Nickel I realize that normal people don’t understand life insurance. It’s so important to protect our families from financial problems and yet frustratingly difficult to understand.
So I tried setting down in as few words as possible the process of getting basic coverage. Here’s my first draft:
Life insurance pays your family a large sum of money when you die (or pays you when your spouse dies). These days most of us have some sort of debt (for example, a mortgage) and expenses (children’s college tuition) that our family could have trouble paying without our salary. Life insurance solves this problem.
It works like other insurance: you get a policy, you pay for it every year, and when something bad happens the insurance company pays up.
How to buy life insurance:
1. Figure out how much life insurance you need so your family doesn’t have to pay it all off without you. Add these together:
* How much you owe on your mortgage
* How much you owe on any other debts you have
Then figure out how much more insurance you would like. Add these together:
* The cost of big expenses now or in the future, like college tuition
* Extra money to help your spouse. Remember, she/he will be grieving after you die and not necessarily ready to start hunting for a better job.
Add all of the above. That’s the “coverage” you need, the amount of the policy. For some people $100,000 is enough, others need $1 million or more.
2. Ask friends and family for a life insurance agent or financial planner they trust. Buy the insurance through them. Do not pay them. They are paid a commission by the life insurance company, so you are essentially getting free advice. Also, ask him or her to explain how to deduct the cost of the insurance on your taxes.
3. Sign up for a simple “Term Insurance” policy (start simple; you can always get more coverage later). You’ll fill out some forms, answer questions about your health, and maybe have to get a physical. Answer all questions honestly. And pay your bill every year.
In another case of it’s the experience not the design, Consumer Reports found that BMW and Harley Davidson motorcycles were three times more likely have have serious mechanical problems versus a Japanese brand, but their owners were more likely to buy that brand again.
On the other side of the coin though, when asked whether they would buy their bikes again, 75% of Harley-Davidson owners said â€œdefinitely yesâ€ while 74% of BMW and 72% of Honda owners made a similar remark. Meanwhile, only 63% and 60% of Yamaha and Kawasaki owners, respectively, said the same about their motorcycles.
We don’t know if this surprising correlation is due to brand loyalty or a different overall experience of the product that goes beyond reliability, but it’s an interesting data point.