If you don't like long fairy tales, skip ahead to the conclusions!
Once upon a time, there were three little pigs who set out to become building contractors.
One insisted everyone build their house on his land using only his materials, and charged too much money. He didn't sell that many houses, and this story is not about that little pig.
One believed that people should build their own houses, and that houses should be built for free. Many people were very interested in this, and often started building such houses, but found it too difficult and gave up, and this story is not about that little pig either.
Pig Makes Good: The Early Years
All of these pigs grew up in houses made of bricks, but this was a new planet where bricks weren't available (I did say "set out", didn't I?), so they had to make do with other materials instead. At first, they made houses out of these materials the way their brick houses were made back home, but there were so many people wanting houses in the same place that they started joining them together in various ways.
The main pig became very successful, not only making houses for nearly everyone on the planet, but employing lots of builders to do so; soon, there wasn't a single builder who knew everything needed to build a complete house.
As more people came to the new planet, most of the big's earnings came from building hotels and blocks of flats. They still built lots of houses, but stopped thinking about how those would be made because that wasn't where the money was, and besides, those folks will always buy their houses anyway.
Wolf Atrocities: The Response
After a while, folks started complaining that homeowners were being eaten by wolves, and the quality of houses came into question. Wolves will be wolves, it was agreed, but surely the idea of a house is to protect one from them?
Some folks suggested building houses out of sticks instead of straw, but the pig said "we have too many pre-built walls that we already made out of straw; it would take far too long to re-do everything in sticks".
Others felt that building out of straw vs. sticks didn't matter too much, as long as you did something about the open windows and weak door hinges.
The pig said "if you want stronger doors, speak to the Door Lock team. What's that about 'hinges'? We don't have a "Hinge Team", so we can't pass those suggestions anywhere. I promise we'll make doors with even stronger locks in future! (the squeaky things at the other end of the door will stay the same, of course)"
The pig also said "we've always built with open windows, and other businesses have come to depend on them. How are folks going to deliver goods and services if they can't climb in through the window? Why not retire to one of the bedrooms, and lock yourself in? If you get eaten, it's your fault, because you will insist in walking around in other rooms that aren't meant for you - you are a resident, not a chef or a barman, so you don't belong in the kitchen or living room."
So the new houses were built with stronger locks and new bedroom doors. And as folks still needed to eat and go to the bathroom, they'd leave the bedroom doors unlocked and get eaten while in the other rooms.
Conclusions
1. The past can tell you only so much about the future.
If you focus on large-volume quality data from the real world while designing new products, you will design products that solve yesterday's problems while being wide open to tomorrow's new problems.
To avoid this trap, you need to brainstorm new designs with homeowners from the start, rather than present them with a near-completed beta product where the design is already cast in stone. You also need to listen to theorists who cannot point to detailed real-world data because what they are talking about does not yet exist in the real world, and pay as much attention to these as you do to the detailed real-world feedback you get on things that already exist.
2. Straw and sticks will never be bricks.
Know that you're forced to build with weak materials (exploitable code) and design your structures accordingly. Any functionality may suddenly become a death trap or fire hazard, no matter what it was designed to be; so make sure such things can be amputated or walled off at a moment's notice.
3. Airliners should not attempt aerobatics.
Know that you are human, and are building with straw and sticks. Don't build death-defying skyscrapers that pose deliberate and unnecessary risks to homeowners. In particular, don't build in facilities that allow arbitrary passing wolves to overpower residents in their houses, even if that is appropriate design when you are building hotels owned by wolves.
Risky tricks like DRM, product activation, linking real-time WGA to DoS payloads etc. have no business in teetering edifices built from twigs.
4. Expose wildcard teams to new ideas.
Microsoft gets better at what they do well, while remaining poor at what they do poorly, or on issues to which they remain oblivious. Why is this?
Partly this is from over-reliance on rich but historical data, as per my first conclusion in this list. But it is also because their ability to develop is structured by present resource commitments. For something they already do, there will be a product team; any idea on how to do that stuff better may reach this team, who will understand what it's about and can swiftly incorporate such feedback.
But if they've never seen the need for something, they will have never formed a team to develop it. Any feedback on such matters will fall on dry ground; there is literally non-one there to process such material.
5. Handle unstructured feedback.
Microsoft regularly solicits feedback via surveys etc. but once again, these measure what is measurable, rather than what's important - so the objective of "getting new ideas" remains un-met.
Yes, it's easier to capture data gathered as responses to radio buttons, checkboxes, ordered pick lists and yes/no questions - but that limits input to what the designers of the survey had thought of already.
At the very least, every survey should end with a generic question such as: "On a scale from X to Y, how well do you think this survey covers what you feel should be surveyed?" followed by a large empty "comments" text box.
A high dissatisfaction score should warn you that you are digging in the wrong place; the response might be to form a wild-card team and pass the dissatisfied returns to them for assessment of any free-form comments that may give a sense of where you should be digging instead.
6. The cheapest lunch is where you haven't looked yet.
The saying "whenever I lose something, it's always in the last place I'd think to look for it!" is a truism, because once you find it, you stop looking. In fact, "lost things" are just the least successful tail of your usual access methods.
You stop looking when you find an answer, but that doesn't mean you have the best answer - there may be better ones if you'd look a bit further.
With a mature product that still has problems, the biggest gains are most likely to be found where no-one's started looking yet - rather than improving existing strengths past the point of diminishing returns.
7. In the land of the blind, name tags aren't useful.
The Internet is an unbounded mesh of strangers, so identity-based solutions don't apply. Once you initiate networking, as opposed to generic Internet access (e.g. after you log into a secure site), such solutions may become useful... but even then, only if the user has a template of expectations to match whatever identity has been proven. Even then, the process is only as robust as the twigs out of which it is built, and the Internet is a very windy place.
For this reason, I'd rate risk management as more important for malware and safety, both out on the web and within the system. This is the barely-touched area that is most likely to provide your cheapest lunch.
8. Who are the wolves?
All pigs become wolves in the dark.
We are the wolves, and so are you. There's no such thing as a special set of saintly piggies (e.g. "media content providers", "software vendors", etc.) who can be trusted with raw pork.
No comments:
Post a Comment