Why I like early-stage startups

Early-stage startups aren't for everyone, but they're certainly for me. There's always more to do than you have time for. Some find that overwhelming and frustrating ("I always fail to achieve the goals I set for myself!"), because they look at it this way:

I prefer to look at it this way: 

Every single day, every single hour even, you can point to something you did that didn't exist before.

Progress isn't measured relative to what goals you set for yourself so much as how much is there that wasn't there an hour ago.

And that's awesome.


Leverage this

Slashdot post says (emphasis mine):

long-standing complaints about fraudulent purchases that leverage Apple's popular online music store

People seriously need to stop verbing that noun and start using normal words instead of trying to sound hip or edumacted.

The internets: you're doing it wrong

You can now rent Amazon Kindle books from your local library.

Does anyone else think this is completely absurd?


The Roggr Rule

Idly chatting on IRC with other nerds, and reading stories about failed startups, this particular quote got me thinking:
  • Problem 1: Founders
We are two founders (business oriented). In a very short time, we ended up 6 people with various business areas of expertise (web marketing, communication, finance, legal, etc.) but no tech person. Wrong. Each one of my co-founders was a kick ass guy/girl in their own area of expertise but every tech/web startup needs a tech person. This tech person is actually the core of any startup, everyone else is expendable (early stage).
Mistake #1: Assemble a small (2, 3) team. Get a tech co-founder.
My first reaction was "duh", which is a little glib and facile. But then, looking back at my previous startups, I came up with the following completely baseless, arbitrary, unsubstantiated, and therefore awesome, rule of startups, which I modestly named The Roggr Rule:
Any Web startup that doesn't have 2-3x as many techies as business people until it has 15+ heads will fail
Expect to read abundant case studies in best-selling business school textbooks soon.


Devs need to stop being such pampered whiners

The 37signals people are smart and have a lot of interesting ideas to make software development better.

The "Boycott A Meeting" movement, however, is bullshit and idiotic groupthink at its worst.

Bad, pointless meetings are bad and pointless and should be avoided.

Gatherings where people discuss features, ideas, implementations, etc. with a clear agenda at the beginning ("let's decide how to build X") and actionable outcomes ("you do this and that, I do this and that, we'll use technology A and B, and will have a prototype out by next Friday") are one of the best ways to foster good ideas, code quality, camaraderie, and productivity.

It's hip to be a contrarian and spout off against-the-grain blanket generalizations as facts, but when your blanket statements are complete bullshit, you lose a lot of your credibility and just come off as an arrogant opinionated mollycoddled sniveling little whiner. Being a self-centered opinionated impatient whining bratty know-it-all is not a requirement for cranking out lots of high-quality software.


Single sign-on across the web? No thanks.

Since the mid-1990s, large corporations (primarily) have been pushing single-sign-on-everywhere as the solution to all the ills of the world. "No need to remember multiple passwords, just use our authentication system!" Microsoft did it with Passport / Live ID, AOL did it, Facebook is trying to do it, Twitter and LinkedIn let you do it, and Google does it across all their services.

That's a bad idea for a number of reasons. Some of us have different credentials on different services on purpose. When I use services for my current employer, I like to use my work email address; it keeps my accounts clean when I change jobs. When I blog here, I use a non-workplace-specific work email address. When I log on to less serious sites, like YouTube, I use different credentials still. Single sign-on makes this more difficult--the easiest way around it is to dedicate a separate browser for each purpose, and that's not really a good solution. There is some overlap between work-work, work-general, and non-work--I like to have all my bookmarks in one place, for example, and so I have to set up bookmark sync between all my browsers. Sure, it's a good idea to do that anyway so I can have the same bookmarks on all my computers, but it's an extra step I'm forced to take because of single credentials.

I know Google now supports multiple sign-on, but you can't be logged into one service and be entirely logged out of another without logging out of all of them. In many cases I just don't want to be signed on into their services at all--I value my privacy, and I don't want everything I do on all Google sites to be linked to my identity by default. That should be my choice.

The purported convenience of single sign-on is primarily a way for large corporations to gather enormous amounts of very specific tracking information about users, and to collect sign-ups so as to drum up their numbers for shareholders. Microsoft's Passport had over 200 million users as of 2002--but creating a Passport account was an apparently required step for using Windows, so the actual number of active Passport users is likely a lot smaller than that.

I've worked in internet advertising and tracking for a long time and I know what it can do. I don't have a moral problem with it--tracking makes advertising more efficient and allows sites to tailor their experience to each one of their users. But it's getting harder and harder to avoid, and that's what bothers me.


Don't overload 404 please

Today I clicked on a Google Plus link in my email, which opened a tab in Firefox. I'm logged into Google Plus in Chrome, not Firefox. What did the link do?


It didn't tell me "You need to be logged in to see this page" and prompt me log in. It didn't return 401 or 403. It just said "the server can't find this resource."

That's arguably wrong. The page does exist--I opened it in Chrome without a problem. So unless you're well versed in http status code arcana, a 404 in this case violates the rule of least surprise and feels like a bug.

The existence of a resource at a URI does not depend on the authentication state of the user agent accessing that URI. If a resource exists, but you're not allowed to view it, 404 is arguably not the right way to signify that--use 401, or 302 to a login page.

Sure, you could argue a 401 or 403 tells you too much--it may reveal that the page does exist, which you may want to hide from unauthenticated users, and 404 is appropriate for
[...] when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable.
In this case, 401 is arguably applicable, so 404 isn't right.

GitHub does the same thing. I hope this doesn't become a trend.


The art of choosing fonts

Wells Fargo emails use a pretty wild array of fonts.

Reminds me of those vintage mixed-font posters (source).

This is why Apple wins on mobile devices

I recently switched to an Android phone because my non-evil carrier's data plan is not compatible with the iPhone. I like the MyTouch 4G fine--it's fast, and not hobbled by the same arbitrary restrictions Apple phones are. I like being able to install any email program I want and pick the best. But it's not as polished or slick as the iPhone, in terms of integration and general usability, and if the iPhone were available on non-evil carriers I'd seriously consider switching back.

This gauntlet of installation steps for the Amazon app store application is emblematic of the state of Android on mobile devices:

Download the Amazon Appstore app immediately by clicking [link] from your Android device, or follow the click-by-click guide below.

Click-by-Click Guide

You need to do this only once for each device. The clicks below should take less than 30 seconds.

Click 1

Open your device Settings and click "Applications".

Click 2

If unchecked, click "Unknown sources". If "Unknown sources" is already checked, skip to Click 4.

Note: AT&T Wireless does not support the Amazon Appstore for Android. See Help for more details.

Click 3

Click "OK" on the "Attention" dialog. "Unknown sources" will now have a green check.

Click 4

Open your notifications and click the e-mail message from Amazon Appstore.

Click 5

Click the link: [link]. The Amazon Appstore app will download to your device.

Click 6

Open your notifications and click "Amazon_Appstore.apk".

Click 7

Click "Install".

Click 8

Click "Open".

That's it! Sign in with your Amazon.com account and start enjoying thousands of apps for Android. You need to do this only once for each device.
"That's it"? Seriously?

Most of this is the price of freedom (in the free-software sense) and the all-purpose nature of Android, which is an "open-source software stack for mobile devices" (as opposed to a UI and operating system designed for exactly two devices, the iPhone and iPad): generic software is inevitably less integrated and smooth because it's meant to function in a wide variety of heterogeneous environments (think off-the-rack v. bespoke suits). What's sad is that most attempts at improving the native Android UI and integration seem to be driven more by silly branding and business deals than by a genuine concern for user experience.

Many of the most successful computing products have benefited from a (more-or-less) benevolent dictator making the hard choices about what is or isn't going into the final product: Apple, of course, but also Linux, MySQL and Python come to mind. Compare that to the confusing, inconsistent array of products (even open source) churned out by headless democratic nerd posses like the Mozilla Foundation with its multitude of browsers (Firefox, Camino, SeaMonkey), calendars (Sunbird, Lightning), extensions ("add-ons", "extensions", "plug-ins") and skinning engines (personas v. themes, which are "add-ons" themselves); or the Linux UI community, with Gnome and KDE and so many other options.

Maybe it's time for a strong leader to emerge and make the Android people focus on one optimal, uncluttered, integrated experience. Fat chance.



CompSci people love recursion. It's elegant and makes for short code that works magically. Of course plain old loops can be faster, less memory-hungry, and easier to grok at 3am after coding for 15 hours, but no matter: recursion rocks.

Still I was surprised to find out that even 419-scammers have become hip to recursion, with this brilliant scam-fighting scam email I got today.

Attention Sir/Madam ,

The Federal Government of Nigeria through provisions in Section 419 of the Criminal Code came up with punitive measures to deter and punish offenders.The Advance Fee Fraud section deals mainly with cases of advance fee fraud(commonly called 419) such as obtaining by false pretence through different fraudulent schemes e.g. contract scam, credit card scam, inheritance scam, job scam, loan scam, lottery scam, “wash wash” scam (money washing scam), marriage scam. Immigration scam, counterfeiting and religious scam. It also investigates cyber crime cases.

This is to officially announce to you that some scam Syndicates were apprehended in Lagos, Nigeria few weeks ago and after several interrogations and tortures your details were among those mentioned by some of the scam Syndicates as one of the victims of their operations.

After proper investigations and research at Western Union Money Transfer and Money Gram office to know if you have truly sent money to the scam Syndicates through Western Union Money Transfer or Money Gram, your name was found in Western Union Money Transfer database amongst those that have sent money through Western Union Money Transfer to Nigeria and this proves that you have truly been swindled by those unscrupulous persons by sending money to them in the course of getting one fund or the other that is not real, right now we are working hand in hand with Western Union and Interpol to track every fraudsters down, do not respond to their e-mails, letters and phone calls any longer they are scammers and you should be very careful to avoid being a victim to fraudsters any longer because they have nothing to offer you but to rip-off what you have worked hard to earn.

In this regard a meeting was held between the Board of Directors of The Economic and Financial Crimes Commission (EFCC) and as a consequence of our investigations it was agreed that the sum of Two Hundred And Fifty thousand US Dollars (US$250,000.00) should be transferred to you out of the funds that Federal Government of Nigeria has set aside as a compensation to everyone who have by one way or the other sent money to fraudsters in Nigeria.

***Please note that we will NO LONGER be liable for any loss, cost or expense, whatsoever, suffered or incurred by You in connection with the fraudsters. Be warned!

We have deposited your fund at Western Union Money Transfer agent location EMS Post office Lagos, Nigeria. We have submitted your details to them so that your fund can be transferred to you. We have also paid the Registration and Safe Keeping fees and for security reasons we have also insured your fund to avoid misappropriation.

Contact the Western Union agent office through the email address stated below inform them about this notification letter and the transfer of your fund;

[scam email removed]

Yours sincerely,

Michelle Jones (Miss)

Assistant Investigation Officer.
The Economic and Financial Crimes Commission (EFCC)
15A Awolowo Road, Ikoyi, Lagos.
+234 1 2625189
[scam URL removed]


Please note that some fraudsters are claiming to be Directors or staff of The Ecomomic and Financial Crimes Commission have recently been sending phony e-mails/letters and also calling unsuspecting persons, with intent to defraud them. It is important to note that these fraudsters are criminals engaged in Advanced Fee Fraud known in Nigeria as 419. Every day, people throughout the world are falling victim to scams of one kind or another. But remember - if it sounds too good to be true, it is probably a scam. In the circumstance, we unreservedly advice you to dissociate yourself from all correspondence and transactions entered into based on evidently fraudulent and fictitious claims.

What we need now is anti-anti-scam scam emails.


Estimating Software Development

Are We There Yet?

As an engineer's career progresses, it's more or less inevitable for her to have to do increasingly complex project management and interact with business folks . Much of the time, what this means is that somebody (usually selling something, either to customers for money or to the board of directors for approval and/or money) needs to know when Flanginator 2.0 will be released. Perhaps just as often, it means that somebody already sold Flanginator 2.0 (in beta, if you're lucky) on a contract starting six weeks from yesterday and they need to know what can be crammed into the next six weeks so they can tell the client what they actually bought. In non-dysfunctional organizations, an engineering manager is eventually called upon to answer a few simple questions:

  • How long will Flanginator 2.0 take to build?
  • How much of Flanginator 2.0 can you do to get something out by date X?
  • What resources do you need to build Flanginator 2.0 by event X?
  • Why is Flanginator 2.0 taking so long?
Ideally the engineer is summoned early on, before dates are set and products are sold, but in practice that's not always the case. This is where the art and science of software development estimation comes in. And it's a bit of a paradox, because engineers are both the best and the worst people to do this.

The Reluctant Leading The Blind

Simplifying grossly, it's helpful to see the typical web shop as a place where software engineers, the Makers' Guild, build things business people sell, and business people, the Merchants' Guild, sell things software engineers build.

Time (to market) and timing are everything to the Merchant, while quality, cleverness and/or craftsmanship are everything to the Maker; and both are completely reasonable. The sooner the Merchant gets to sell a product, and the more closely the product availability can be tied to some important externality (e.g. a trade show, a conference, your customers' budget calendar), the sooner the revenue rolls in, and the harder it is for the competition to catch up. Complementarily, the higher-quality the product, the more satisfied the Maker and her customers are, the more revenue rolls in, and the harder it is for the competition to catch up.

Note each guild's goals are exactly the same as the other guild's--make money and beat the competition. But the two camps are going about it from two very different perspectives: the Merchant is very concerned with time, shrinking it or molding it to fit into a complex web of external calendars and deadlines over which she has very little control. By contrast, time is the least of the Maker's concerns, because she has to worry about building a product that works with no splinters or dead-ends or a shaky foundation--it'll be ready when it's done, and we can't compromise code quality / scalability / employee morale / features / database structures / code reviews / our finely chiseled system architecture just to get the product out faster.

In the best-case scenario, this tension leads to a very brisk product release schedule with constant improvements to products that sell themselves because they're finely tuned to what the market wants. In the worst-case scenario, engineers hate the slimy loose-cannon idiots from sales, and sales people hate the scruffy maladjusted untucked nerds from engineering who couldn't sell a warm jacket to a naked Eskimo.

The Thanksgiving Dinner Parable

Taking my cues from a long-dead craftsman from the Mediterranean region, who used to get a ton of mileage out of ostensibly non-à-propos at all yet profoundly relevant stories about people and things unrelated to the question at hand, I'd like to step back from engineering and sales for a moment to try to get at the crux of the biscuit of software estimates, by considering the commonly-shared experience of the Thanksgiving dinner (at least here in the US; feel free to substitute any other magniprandial calendricality of your choice).

In very simple terms, a Thanksgiving dinner is a family gathering on the last Thursday in November during which a large quantity of home-cooked food is consumed, also at home, by nuclear families and sometimes Others (usually not until they have reached the Significant stage). The meal normally includes a very large turkey, cranberry sauce, mashed potatoes or yams, some non-starchy vegetable, stuffing, gravy, some manner of bread, pumpkin pie, and beverages. It is widely accepted that the average Thanksgiving convive will describe with the most fondness and enjoyment those events having involved the maximum amount of home-cooked items, especially when made entirely from scratch, as against, say, canned cranberry sauce or frozen Sara Lee pumpkin pie, which isn't half bad, if you ask me.

Now, if you ask a Thanksgiving dinner maker how long the whole shebang is going to take, you'll probably get a wide range of answers. A young, first-time cook might say "oh golly, I have no idea, it'll take at least a week, and it's already Tuesday!" as s/he rushes to the grocery store. A Thanksgiving veteran might say "I'd say a morning of shopping, thaw the bird overnight, a day of cooking, so let's call it three days." I'd bet some serious Thanksgiving dinner makers put a lot more time into it, while Thanksgiving dilettantes may devote just a few hours (or none at all and just go to the restaurant or order in). I'd also bet not a single one of those guesses will be near the time it actually takes when all is said and done. People are simply not very good at guesstimating how long things take, unless said things are very few, very well-defined and well-rehearsed, and immune to externalities like a flat tire on the way to the store, a gas leak, frigid temperatures adding five hours to the bird's usual thawing time, etc.

Of course nobody would ask the Thanksgiving dinner maker for a very, very specific estimate of how long it will take, or a very, very detailed breakdown of every little task with a time and a name attached to each. If you requested a Thanksgiving task list from a naive cook you'd probably get something like this:

  • go shopping (2 hours)
  • thaw the frozen turkey (36 hours)
  • cook turkey (6 hours)
  • make pumpkin pie (2 hours)
  • etc.
In reality, though, what actually happens is this:
  • drive to Trader Joe's (10 minutes)
  • find a place to park and walk to store (10 minutes)
  • shop (25 minutes)
  • stand in at the register in the crowded store (10 minutes)
  • go back to car, load trunk, return cart (5 minutes)
  • drive to Safeway for the rest of the stuff (10 minutes)
  • find a place to park and walk to store (10 minutes)
  • shop (25 minutes)
  • stand in at the register in the crowded store (10 minutes)
  • go back to car, load trunk, return cart (5 minutes)
  • go to the farmer's market because the asparagus was just ugly (10 minutes)
  • shop at farmer's market (1 hour)
  • get gas (10 minutes)
  • go home (10 minutes)
  • unload (10 minutes)
We've already blown the "go shopping" bullet point estimate (2 hours) by 75% (3 1/2 hours). I'll spare you the expansion of the rest of the list, as I trust the point is made--as absurdly detailed as the longer breakdown is, it's the only way you can get close to how long any single piece of functionality of your Thanksgiving dinner is going to take. The larger/fuzzier the piece ("cook turkey" is a lot more than just sticking a bird in an oven--there's stuffing, basting, gravy, turkey skin hydration and temperature monitoring, etc), the less accurate the ballparks inevitably are.

Many software engineers are Thanksgiving dinner makers, thinking in terms of blocks of functionality that often require a lot of work. And because writing software usually means building something that you haven't built before, there's very little directly applicable hard evidence in your past experience to guide you in your time estimate for the new feature. Some well-rehearsed tasks can be estimated very accurately assuming everything works (e.g. kickstart a new server on standard hardware), but that assumption itself is often faulty since, well, nothing actually works all the time--we're talking about computer hardware and software, and we're barely out of the Ford Model-T era of sophistication and reliability.

So one key to better estimates is to learn and practice the skill of breaking those chunks down into well-defined tasks that can likely accomplished by one or two people in a day or less. If that's too hard, break up your larger features into smaller feature subsets, and break those down into tasks. Use Post-It Notes, with names and time estimates on each of them, line them up on a wall, then add up the times--there's your time estimate. Of course it'll be rough, and three times as long as anyone expected, so that's where you start cutting features and grouping tasks into releasable phases that can be rolled out in daily or weekly increments, or major versions of your software over a longer period of time.

There are diminishing returns the deeper you go into details for your estimate; splitting up a day's work into eight one-hour segments (or smaller) requires a huge amount of upfront analysis and thinking that will most likely be inaccurate or irrelevant by the time you start, since you haven't started writing the software yet and today's guesses about which individual classes and member variables you'll need two weeks from now are mostly a waste of time as the features and implementation details will have changed three times between now and then. So save the very detailed (sub-1-day) breakdowns until you've broken up your feature set into phases, and each phase into bits of functionality, and don't tackle too much in advance--a couple of release cycles at the most, because the work you do today for phase 1 may turn out to invalidate the guesses you make about phase 4.

All that means is that software estimates are just that: estimates. The only time you can precisely say how long a project is going to take is after it's done, and even then it's rarely practical to be exact, because being exact requires either sneaky or overbearingly bureaucratic time-tracking shenanigans, and who has the time?

Note this doesn't absolve the Makers of the responsibility to produce decent estimates, to consciously work at improving them, and to make every reasonable effort to build quality products in accordance with what often seems like a completely fanciful set of arbitrary external deadlines. On the other hand, frank conversations need to take place with the Merchants so that truly arbitrary deadlines that only exist in a Merchant's mind are objectively and clearly separated from the handful of hard deadlines the blowing of which can have truly serious consequences, so that pressure, potential disappointment and ultimate recriminations are kept to a bare minimum.

Real and Fake Deadlines

In addition to estimates, a software engineer's job also requires becoming creative and conversant in the art of compromise. Do you really need the Flanginator to have an electronic stereo klaxon with 127 foot-switchable sounds, or will a hand-activated horn suffice? Does the Flanginator positively, absolutely need to be out and tested by February 12th, or is there flexibility?

Some compromises can't be done: a big turkey will not thaw satisfactorily in two hours. You also can't just eat cranberry sauce and nothing else. Often they can: maybe Whole Foods mashed potatoes are just as good as the ones you were going to make before you fell in the shower and sprained your potato-mashing wrist. Sometimes they're not worth it: do you really want to go to Whole Foods on Thanksgiving Thursday morning, or call in a caterer with 12 hours' notice?

So another key is to be honest with the whole team (Merchants and Makers) and distinguish between real and fake deadlines. Real deadlines are events or signed contracts where having some product is a requirement, like a trade show or a meeting to pitch investors. Blowing those is like having Thanksgiving on Friday--ça ne se fait pas. Sacrifices will likely need to be made all round if the timing gets tight (cut features, hacks, throw-away code). The responsibility is best shared across the team, and your Merchants need to be on board with (and shoulder some of) the sacrifices made to make the deadline. Fake deadlines are those features that just "need to go out tomorrow so this reporter who told me she might write a piece about us for next month's issue can see we're on the ball." Those are more like dinner with friends: no one will die if you skip a weekend, or hang on Saturday rather than Friday, or order in instead of home-baking your famous prime rib cheesecake.

No Eye-Rolling

It's hard to find organizations where engineers don't roll their eyes and complains "Jeez, sales sold something we can't possibly build again. Jill must be trying to max out her quarterly bonus / they have no idea what it takes to build that thing." Those organizations' sales folks are also more likely to wonder "How can we be expected to bring in revenue if engineering won't build products we can sell? Our customers close their budgets by November, so if we don't have Flanginator 2.0 ready to demo by October 17 at 2:17pm EST, then it's an entire year's work down the toilet." This is bad, but not very difficult to address.

Educate your developers and product folks by getting the sales folks' perspective on what the market wants. The sales force is on the ground, talking to customers every day, and has a unique perspective on what kinds of products can be sold, so sales should be involved in the product development. Even a small UI tweak being considered to make something fit more gracefully into a page can have a huge impact on the sellability of a product (maybe it means your paying partner's logo will look smaller, or be their name will be moved off to a less desirable position). The only worse thing than having to scramble to hotfix a roll-back of this change is getting a call from sales right after they hear about the tweak from their very angry paying customers. It's not fair to sales, it's not fair to engineers, and worst of all it's not fair to your paying customers. Get sales involved.

On the engineering side, invite your engineers to industry events, focus groups, and user testing; heck, encourage them to run some of those user-testing sessions. They're inexpensive and eye-opening, and nothing beats hearing the same three wishes or complaints directly from real customers.

Ultimately nothing beats product and business leaders with some technical sense, engineering leaders with some business sense, and engineers who are realistic and honest about what can and can't be done. Ideally the skill sets in a product development organization overlap a bit like this:

If you don't have that today, get started on it now, because your organization is a vital organism that must--and can--change, adapt, learn and improve.