Saturday, January 31, 2009

Gnip: What's worked well, and what hasn't.

Gnip's almost a year old. That combined with a great week which included a stellar board meeting, technical clarity around specific areas, business/requirements clarity around specific areas, and an impending big release motivated this blog post.

We have built an amazing back plane that's driving a true marketplace for modern data, while solving fundamental data access issues on the network today. We have a growing revenue curve with tons of blue sky ahead. We're turning our back on verticals that would kill us, and embracing the sweet spots. It's always a difficult road ahead, but just like 2008, 2009 is going to be a killer year for Gnip. I'm so stoked to be a part of this.

I wanted to take a quick look back on 2008 and outline the positives and negatives that stick out in my mind; maybe you can make use of them in your startup.

On the plus side we...
  • Never compromised on hires, despite delivery schedule impact.
  • Hired experience, breadth and depth. While expensive, it sure beats babysitting and training kids when you have to be executing a mile a minute.
  • Leveraged "the cloud" for ultimate hosting environment flexibility.
  • Solved real problems in the industry. One of our investors, First Round Capital, sums this approach up well on their website: "Companies must provide a unique solution to an existing urgent need. We don't invest in companies which try to change consumer behavior or create a new consumer need."
  • Made pragmatic decisions to cut features that were weighing too heavy on operations, despite vocal community suggesting we do otherwise. Don't drown yourself.
  • Let the business definition, and customers, evolve naturally. Steadfast tunnel vision would have left us in the dust.
On the minus-side we...
  • Ran too long with too big a feedback loop between business, technology, and customers. From software development, to business evolution, small, fast, tight feedback loops are fundamental. Hell or high-water, make certain any open questions get nailed down immediately.
  • Didn't "load test" all possible scenarios (difficult to predict no matter how you slice it). Until your business model is crystal clear, pressure every edge of your software so you know where the sweetspots are, and where the fragility is.
  • "Pragmatically" pair-programmed for too long. Wishy-washy process led to confusion, lack of clarity, and inefficiency. Once we drew the line in the sand and declared to ourselves that we were _a pair programming shop_, no questions asked, the seas parted and clarity became crystal around the process.

Friday, January 9, 2009

Dear Federal Government: Invest in Schools

When you're scrambling to figure out how to inject nearly a trillion dollars into an ailing economy, please consider some of the more obvious "trickle down" venues for spending (yes I'm fully aware of who coined "trickle down" and that it was squarely focused on private markets, but I like the irony of using it here). I appreciate the thought of converting government buildings to be more energy efficient, but when you're having trouble spending a trillion dollars because so many of the potential programs don't pass the "pork barrel spending" test, consider our public education system. Any American would appreciate any amount of money going into schools, and I suspect you could easily burn a few hundred billion dollars to set the stage for a highly educated USA in coming generations.

I'm lost when I read in the New York Times that the Obama crew is struggling to find programs that add up to $800B, and there has never been any mention of public education as an outlet. The jobs created in building new schools, renovating old ones, employing more teachers, finally getting teacher pay to a livable level (at least!), providing modern learning tools and programs, modernizing the public schools bus transportation program in an energy efficient manner, and on and on. Open your eyes folks, or explain to me why the schools aren't a good place to dump untold sums of money; "privatizing schools" doesn't count as an answer BTW.

Thursday, January 8, 2009

Estimating Code (Stories)

I've worked in several "Agile" development teams over the years; from developer, to manager. Estimates are always one of the challenging things around software; both development's actual estimates (making them is very hard), as well as management's interpretation/understanding of them.

Some advice to developers:
Never utter the words "that is easy," because if you do, rest assured that everyone in the room has a radically different definition of "easy" (which is fluid in and of itself), and 3/4s of the room will expect the work to be done before the conversation is over. When I hear the words "that's a one-liner," I cringe. That "one-liner" inevitably takes hours of work. Try to consider the full spectrum of your process. When you make that "one-liner" change, what are the ramifications to your test infrastructure, for example? Whatever environment, or team setting, you are in, you need to understand it so you are able to fully estimate a Story.

Too often developers have tunnel vision into their specific area, and we lose sight of the bigger picture. Story/work estimation is part of a bigger picture, and developers need to be aware of that when we're estimating things.

Some advice to managers ("managers," product managers, project managers, whatever):
If you ever hear the words "that is easy" or "that's a one-liner," take it with a grain of salt. Gently prod to vet the surrounding estimates. The coding itself, may indeed be an "easy" "one-liner," but the ramifications to tests that have been written, or to QA, or to operations/production, or deployment, or system administration, may be huge.

Everyone on the team needs to have an understanding of their process and software life cycle in order to have a sense of what code is going to do downstream. There are plenty of "one-liners" that can bring your software to it's knees for weeks.

Software construction doesn't work well when the "customer" (Product Management, CEO, contracting client, yourself, whomever) is disconnected from the process. That disconnect can be organizational, emotional, intellectual, or otherwise. If you're building software and you feel disconnected from your customer, fix it. If you're having software built for you and you feel disconnected from development, fix it.

Sunday, January 4, 2009

I can't believe I have to say this...

I assume everyone around me has the same thoughts, background, and experiences as myself, buzzing around in their heads. I'm always amazed when I discover this isn't true. Note, the sarcasm. I just noticed something disturbing in a demographic I wouldn't have expected to see it in; twitter. Twitter is a niche marketplace with tech savvy users (or at least it used to be). However, evidence of Twitter going mainstream just hit me in the face. Twitter just blasted a front-page service warning to users about a phishing scam some of their users have seen, and fallen victim to. I was taken back to my days at AOL when corporate communications felt it prudent to internally educate employees about phishing scams. I knew I was in trouble when I saw one of the Internet's supposed powerhouses having to educate its employees about such a topic.

I can't believe I have to say this, but... dear latest-web-generation, understand the risks around you, as well as how to avoid falling victim to scams, while reading email and web browsing.

Here are my general safety/scurity rules of thumb that apply to surfing anything running in a browser (webmail, shopping, browsing, whatever). I should disclose that my world view is confined to Mozilla based derivative technologies such as Firefox and Thunderbird, though there are generally equivalents to these tips/techniques for IE.
  1. Pay attention. There's no super secret amazing technology that lets a wrongdoer steel your information magically. Computers, the Internet, and email are surprisingly secure. 99 times out of 100, if someone lost information, it was because they weren't paying attention. They either clicked a link they weren't supposed to, and exposed themselves to some form of phishing, a bug exploit, or downloaded software they shouldn't have.
  2. Use a decent password. Something like 2/3's of all MySpace account passwords are the word "password." You can guess the quality of the remaining 1/3rd.
  3. Clicking on links, even "evil" ones, is ok; it's what you do once you've arrived at the final destination where you can get into trouble. Every now and then someone exploits a browser security hole and gets you to go to the webpage that does the exploiting, but these are very rare. Related to #1, pay attention on every page you're on.
  4. Never give a web page information if something (e.g. an email from your "bank") directed you to the page to do so. The old-world equivalent of this rule is "never give your social security number to someone who calls you on the phone." There is never a legitimate email, or web-page that asks you for personal information of any kind, if it initiated the exchange; 99 times out of 100 it's a scam. Giving web-pages your information is perfectly secure, as long as you initiated the exchange. For example, if you get an email suggesting your account information is out of date, guess what, it's not, someone's trying to scam you. If your account information is out of date, you'll find out on your own terms; only update account information under those circumstances. Legitimate services' privacy policies and terms of service clarify that they will never ask for your personal information, under any circumstances; that's all you need to know.
  5. Always notice the fully-qualified-domain-name of a web-page you're about to enter information into. If it's not where you think you should be entering information; don't. Just pay attention to the domain name; 99 times out of 100, that's enough. For example, http://paypal.services.com is bogus. http://services.paypal.com is valid.
  6. Always ignore graphics and text in a web-page that say things like "this page is secure." The only thing that guarantees encrypted security of data transmission is an https URL (e.g. https://your-bank.com). Be aware of your browser's encryption/security UI elements and features, and look out for those. I have never seen a browser exploit that fooled the base-level ssl certificate UI; trust your browser.
  7. Hover over a link to determine where clicking it will take you. If the hovered link isn't where you want to go, don't bother clicking on it. I suspect there are some cute DOM tricks to obfuscate where clicking a link will take you, so to be really sure about where clicking a link will take you, select the link text (note, that's different than a click), right-click it, then select "view selection source" from the context menu. From there, you'll see the actual href that will be navigated to upon click.
  8. If you're generally suspicious/interested, install Live HTTP Headers for Firefox based browsers, or HTTP Watch for IE, and watch/block the traffic you don't want. Firefox 3.1 (finally!) supports native HTTP header interrogation as well. Just view the page info (Tools->Page Info) and click the "Headers" tab.
Good luck.

Saturday, January 3, 2009

HOW-TO: Force incompatible Firefox Add-ons to Install

If you ride Firefox versions harder and faster than add-on developers upgrade their add-ons for compatibility, this post is for you.

Firefox add-ons include their Firefox version compatibility within their .xpi install file. Often developers will put a "maxVersion" field in their add-on to mitigate potential compatibility issues between their add-on and future version of Firefox. 99% of the time however, there aren't any compatibility issues when there are minor (or even major) version upgrades of Firefox, yet you're prevented from installing your favorite add-on because of the add-on thinks it's incompatible. Here's how you can force the add-on to install. NOTE: your mileage may vary; you may indeed be installing an add-on that is not compatible with your up-version of Firefox; use at your own risk.
  1. Download the .xpi for the add-on you want, directly to your hard-drive, bypassing the default installation behavior of Firefox. To do this, find the .xpi file for the add-on, generally through a Google search. addons.mozilla.org tries to be smart and prevent you from even downloading add-ons that aren't compatible with your browser, so you have to work around this and find the direct link to the .xpi. Once you find a link to the .xpi, right-click it and select "Save link as..."
  2. Crack open the .xpi file. .xpi files are simple zip compressed archives, so you can unzip them like any other .zip file. "unzip your-file.xpi". That will un-archive/un-compress the contents of the .xpi file. You might want to do this in a dedicated directory for cleanliness' sake.
  3. Open "install.rdf" (that was extracted in the previous step) in a text editor, modify the "maxVersion" field and save the file. Make sure this field is at least at the level of your version of Firefox. Use '*' accordingly to indicate any version number.
  4. Re-generate the .xpi file with the updated install.rdf file. You do this by running the "zip" command like so "zip -f your-file.xpi".
  5. Install your-file.xpi by opening it in the browser via File->Open. Follow the install steps Firefox presents.