Friday, December 19, 2008
This is the work of a reader of the Sports Guy's columns (if you don't know who the sport's guy is.... tch tch)
I thought reader Ian in Portage, Mich., summed up the season nicely: "Hey, check out what I did for the last six hours trying to make this work all the way through. OK, Kansas City beat Oakland, which beat Denver, which beat Cleveland, which beat Cincinnati, which beat Jacksonville, which beat Green Bay, which beat Seattle, which beat San Francisco, which beat Buffalo, which beat San Diego, which beat New England, which beat the N.Y. Jets, who beat Arizona, which beat Miami, which beat St. Louis, which beat Dallas, which beat Washington, which beat New Orleans, which beat Tampa Bay, which beat Minnesota, which beat Carolina, which beat Atlanta, which beat Chicago, which beat Indianapolis, which beat Baltimore, which beat Philadelphia, which beat the N.Y. Giants, who beat Pittsburgh, which beat Houston, which beat Tennessee, which beat Detroit, which beat NOBODY."
Wednesday, December 10, 2008
The good folks at Evernote released a new product functionality today. The ability to take a picture and have it show up on your Evernote account with you doing nothing more than take the picture. The magic is not in taking the picture or the integration, to me the magic is in the words "you doing nothing more than take the picture". This is exactly what product management should be about, seamless, frictionless ways to enlist a person to use your product.
I am jealous, I want to use Evernote but I ended up paying money and buying OneNote and I feel guilty :-/ even though I stopped using OneNote a while back. *sigh*.. :) Maybe evernote should start a program where I can turn in my OneNote software and get a 15% discount or something so I don't feel guilty.
Any way this is very cool and imho a potential game changer -> http://bit.ly/6jEj (Evernote blog post)
Congratulations! fine people of Evernote.
Galls Law -> http://bit.ly/iFIK (Gall's Law).
Monday, December 01, 2008
Posting for Jeff!
From: Jeff Chambers <email@example.com>
Date: Mon, Dec 1, 2008 at 7:47 PM
Subject: Babyslist.com Site Launch
I'm happy to announce the beta launch of another Austin Startup Lab company called BabysList.com. BabysList is a niche site that will serve the Austin and surrounding communities by assisting parents that want to sell, swap and search for all things baby, locally. It's my hope that this site will develop into a marketplace for parents to help others in their community that don't have the means to buy "new" baby products as well as provide a platform for letting stay at home moms and dads make additional income without the cost of shipping charges and risk of fraud.
BabysList was "born" (sorry I had to :) ) when Jen and I were shopping for Elise before she arrived. I was amazed at how much stuff we needed and what it all cost. Given the life cycle for most baby items is measured in months, I saw them as barely used, or in some cases not even used at all before the child grew out of that product. I set out to create a place where parents could market their used baby items to a very specific, local audience as well as find great bargains on all sorts of things for their baby.
This holiday season is shaping up to be a hard time for many people, so if you have any items that you were waiting for your next garage sale or were going to donate, I would ask you to consider posting them on BabysList so that local parents needing a little help with finances this holiday season have an alternative to buying "new". It's good for everyone when we all lend a helping hand.
Check it out: http://www.babyslist.com
Thanks for your support,
The Chambers Family – (Jeff, Jen and Elise)
p.s. Tell a friend or blog about babyslist!
Thanks to Bokardo.
An interesting bit came across my twitterstream the other day:
“A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.”
Yup, seems to hold for the complex systems we know and love: organic life, government, law, medicine…and of course Twitter.
Let’s imagine for a moment that it does hold. This would change lots of things, including much of the software world, which is laden with complex behemoths who frustrate us daily.
- Building simpler software from the start
Obviously, if Gall’s Law is true then more teams would start out building really simple software instead of overly complex stuff. Sometimes, though, it’s hard to think that way. Instead, the thinking seems to be, if we’re going to be as successful as (X), then our system needs to do more than (X). But in complex, social software, that may actually be impossible, since (X) didn’t spring fully-formed into life, either. Most of the software people try to emulate quickly took years and years to evolve to where it currently is. (as an aside, my recent argument is to focus on designing to support a specific activity and nevermind emulating success for its own sake)
- Meeting solid metrics before adding features
This is an interesting idea: make sure that your software works at some basic thing before you add features to it. I’ve seen on a couple projects in which there was a tension between the current under-performing software and the ambitious engineering plan that adds a lot more features. Which do you do? Stop and get people using the simple software first or push on and hope that people will come flocking after you’ve added a few more features? Well, according to Gall’s Law you get the simple software working first. My question is…are there teams who actually do this? Are there any that have actually said: “we have not reached our initial goals, let’s stop adding features and work on the ones we already have”?
- Changes by design
The overall effect of Gall’s Law is that most software would start off simple and evolve over time. So we wouldn’t end up with the software we imagined, but the software that managed to live through the early use and subsequent selection process. Accepting this as a rule, could we somehow plan for this evolution even though we don’t know what it will bring? Can we plan for this change? I think so, by building in feedback and reporting mechanisms and merely acknowledging to change the design based on such feedback.
Of course, the reason why we add feature after feature is because we don’t realize we’re doing it: we don’t see the accumulation of complexity…we only see adding “one more thing”. In the same way that a camel wouldn’t feel the slight addition of weight but ends up with a broken back, we don’t really feel each additional feature until its too late.
Gall’s Law might not be an actual law, but it sure seems like a good thing to keep in mind when you get into those inevitable project debates about improving what you have vs. adding new features.