lessons from others: a chumby engineer

As kids, we don’t listen to the advice of other people. We’re too busy being independent thinkers, individuals, rebellious, and caught up in our own autonomous futures. We’re also unconsciously sick of being constantly told what to do and molded by parents, institutions, and school.

Part of the process of getting older is appreciating the (value of, which itself is an ‘adult’ phrase, yeah?) experiences shared by other people, and our learning from mistakes and successes of others. This is probably why adults keep trying to “advise” kids, and we adults just don’t get why kids don’t listen. I also believe this sharing of experience is one of the best things about the Internet (and maybe one of the worst if you get idiots sharing poor experiences that make no sense or are rife with, well, idiocy).

Anyway, in comes an experience-sharing interview: “MAKE’s Exclusive Interview with Andrew (bunnie) Huang – The End of Chumby, New Adventures.” I have a Chumby. While I’d known about the Chumby for years, I didn’t actually pull the trigger on purchasing one until last year. Sadly, I jumped on just in time for the wagon to reach the end of the trail: the chumby is on the way out. While it still works, the Chumby is basically dead-thing-uhh-sitting, since its apps rely on the central server for updates and actual function. I see today the forum’s aren’t working, and my never work again for all I know… (also sadly, I do not have one of the cute, awesome, little bean-bag type plushy ones that I fell for years ago; mine is a hard upright piece of plastic…)

But Huang has plenty of advice to give in this long interview, where he talks about entrepreneurship, design, kickstarter, funding, pricing…

The hardware model is radically different from the software model. Software is innately scalable; you can acquire a hundred thousand users overnight. Monetizing the user base in software is trickier, but most software plays start with scale and then worry about money.

This sort of discussion is worth having in really any part of IT. Are you making infrastructure decisions based on what the business wants, or creating a space for the business to find uses for what you do? I’m no expert in this area, but sometimes you need to worry about how your infrastructre or solutions scale and are agile and fill multiple needs quickly, and let the business worry about the monetization, ya know?

In the face of ‘ship or die’, one should not be looking to ship the perfect product. It is more important to ship a product that’s good enough, than a great product that’s late.

I think we in security can relate to shipping unfinished products. But hey, that’s the name of the game.

But that does show one of the flaws of fact-based reasoning. Engineers love to make decisions based upon available data and high-confidence models of the future. But I think the real visionaries either don’t know enough, or they have the sheer conviction and courage to see past the facts, and cast a long-shot. It’s probably a bit of both. Taking risks also means there’s a bit of luck involved.