Everything is miscellaneous. Sounds obvious, right? Boring, even. If it weren't for rave reviews from some sources I respect, I never would have picked up this book. And I certainly wouldn't have made it past the first few pages, which discuss the finer points of silverware drawer organization. But I have a neurotic tendency to finish books I start - and I liked Weinberger's previous book - so I kept with it.
By the end, Weinberger completely dissects the implications of the title. Everything is miscellaneous, so don't try to categorize. Put all your information in a giant heap, attach simple metadata (tags) to elements that you find interesting, combine it all, and let the web sort it out. This is the secret behind Flickr, Google, Amazon, and zillions of other extremely useful, innovative, and seemingly magical web sites. The power to sort through miscellaneous, unorganized data is a new phenomenon, powered by the internet, and is quickly replacing previous organizational methods that were built to organize objects within limited physical space (such as the Dewey Decimal System and the card catalog system).
This is a wonderful book for anybody designing software, a process that inevitably forces the designer to decide how best to store information and display it to the user. Weinberger provides a clear answer: organize minimally, if at all. Let customers define their own categorizations. Provide few limitations. Create an easy-to-use, simple, enjoyable experience. The better the experience, the more customers you'll attract. The more customers you attract, the more information they'll give you. The more information they give you, the more useful the information becomes. The more useful the information becomes, the more powerful your application becomes. The more powerful your application becomes, the more customers you'll attract. A virtuous cycle indeed.
Friday, April 4, 2008
Friday, March 14, 2008
Oozy Plans
So, you work at a big software factory. It's pleasant enough, in a very sterile, non-evil, Office Spacey way. But your company isn't the best at project planning. You fall into a trap that lots of large companies fall into when they try to put together software projects. The project works something like this:
Step 1: Executive or non-technology department (Marketing, "The Business Unit", etc.) dreams up great idea.
Step 2: Idea dreamer upper tells technology group to build The Thing (oh, and how long do you think it will take?).
Step 3: Technology group assigns project to a project manager.
Step 4: Project manager - well-meaning but perhaps under pressure - gets a few reliable heads into a room and quickly puts together The Plan, complete with a code freeze date, a testing complete date, and a release date. Don't worry, this plan is just a SWAG. It isn't written in stone.
Step 5: Project manager presents SWAG to executives.
Step 6: Executives write project plan in stone.
All is well until the developers begin designing and building the project and discover it's going to take approximately nine months longer to complete than they have time for, assuming everyone works nights and weekends. At this point, the project managers begins thinking and comes to the conclusion that Just a Few More Developers will do the trick. Or maybe we'll Just Get Lucky and it will all work out in the end.
Step 7: The Mythical Man Month ensues.
This is a good way to create very high turnover or build a large unwieldy project that is useless at best and unmaintainable at worst. Fortunately this problem is easy to fix, but the solution is not always obvious and takes a little discipline.
Insert:
Step 3.5: Project manager locates developers (the actual people who will write the code).
Step 3.6: Project team builds spec. Developers get to help.
Step 3.7: Project manager asks developers for detailed estimates of the time it will take. No task is allowed to exceed 16 hours.
Yes, steps 3.x take a little time, sometimes months. But you'll have to do these steps anyway and if you do them before step 4 instead of after step 6, you're going to get a schedule you can actually rely on. You know, the kind that hurts your hand when punch it. The kind that doesn't ooze all over the floor when it's dropped. And your developers will probably come up with creative solutions you never thought about that will save you loads of time and money. Plus, they'll enjoy themselves more and feel like they have some control over their lives and stay at your company and you'll get very large bonuses for the rest of eternity because your team will be so phenomenally productive.
Step 1: Executive or non-technology department (Marketing, "The Business Unit", etc.) dreams up great idea.
Step 2: Idea dreamer upper tells technology group to build The Thing (oh, and how long do you think it will take?).
Step 3: Technology group assigns project to a project manager.
Step 4: Project manager - well-meaning but perhaps under pressure - gets a few reliable heads into a room and quickly puts together The Plan, complete with a code freeze date, a testing complete date, and a release date. Don't worry, this plan is just a SWAG. It isn't written in stone.
Step 5: Project manager presents SWAG to executives.
Step 6: Executives write project plan in stone.
All is well until the developers begin designing and building the project and discover it's going to take approximately nine months longer to complete than they have time for, assuming everyone works nights and weekends. At this point, the project managers begins thinking and comes to the conclusion that Just a Few More Developers will do the trick. Or maybe we'll Just Get Lucky and it will all work out in the end.
Step 7: The Mythical Man Month ensues.
This is a good way to create very high turnover or build a large unwieldy project that is useless at best and unmaintainable at worst. Fortunately this problem is easy to fix, but the solution is not always obvious and takes a little discipline.
Insert:
Step 3.5: Project manager locates developers (the actual people who will write the code).
Step 3.6: Project team builds spec. Developers get to help.
Step 3.7: Project manager asks developers for detailed estimates of the time it will take. No task is allowed to exceed 16 hours.
Yes, steps 3.x take a little time, sometimes months. But you'll have to do these steps anyway and if you do them before step 4 instead of after step 6, you're going to get a schedule you can actually rely on. You know, the kind that hurts your hand when punch it. The kind that doesn't ooze all over the floor when it's dropped. And your developers will probably come up with creative solutions you never thought about that will save you loads of time and money. Plus, they'll enjoy themselves more and feel like they have some control over their lives and stay at your company and you'll get very large bonuses for the rest of eternity because your team will be so phenomenally productive.
Subscribe to:
Posts (Atom)