Dan Grigsby

A beep; a pause. Another beep; another pause. Third beep; third pause. Eleven beeps in quick succession. Listening to the kid in the row in front of me reset his Timex following our flight one time-zone westward helped me understand why building web apps has been so so little fun recently.

Two buttons provide enough of an input mechanism to set a $10 drug-store watch. Hold down one button, wait for the LCD numerals to start flashing (or, fancy-schmancy, listen for a beep) and plug away at the other button until you’ve cycled forward to the right value. Hold down that first button down if you want a different column of numbers.

By any measure, that’s a crummy UI. Thing is, it’s good enough. It’s good enough for the bottom-of-the-line digital. Moving up-market the UI gets even worse: my REI bought analog watch uses a single rotating stem to set six hands on spread over 4 dials. That’s an arguably worse UI still. But again, it’s good enough.

Sometime in the recent past we traded in “good enough” web UIs for UIs measured against desktop applications. Google is widely credited with ushering in this era. They showed us that it was, indeed, possible to build beautifully interactive web applications using JavaScript to manipulate the DOM. While we were at it, we traded in the limitations of tables and simple HTML for the granularity and rigor of CSS.

Working with CSS and the DOM is aggravating. Plenty of reasons for that [1], most defendable is probably the inconsistencies between browsers. Naturally you can overcome most of these things by exerting effort. That’s effort spent working on something that is, in all likelihood, ancillary to the purpose of your application.

I suggest we take back “good enough” and justify it by applying Barrel of Rocks metaphor of market segmentation.

Sink uses a barrel to represent the total market for installed software. The barrel gets filled with stones whose size represents the size of the market-opportunity. Operating systems and office-applications are boulders; there’s only room for a few of each. Here, a glance, the barrel is full. But, of course, there’s lots of space between the boulders. This space is can be filled with rocks, and the space between rock with pebbles and so on.

With the barrel representing the total market for web applications everything becomes clear: Google, whose applications set the broad market standard for installed-application-like UIs, is a boulder. They want people to switch from installed software to their broad market web applications, so they need these fine interfaces and their market opportunity justifies the time/cost/complexity.

Are you building a boulder, a rock or a pebble? You’re not very likely to be directly competing with Google, nor is your application likely to be a installed-to-online switchover application, so good enough ought to be good enough.

Start simple and carefully add your application-like features later. Focus on features that offer substantive depth (e.g., keyboard shortcuts) over flashy eye-candy to promote power users of your app — see Kathy Sierra’s Engaging Users essay for inspiration.

[1] For a more technical slant on this, you might like Neil Mix’s Beyond Dom article.

Minnesota can attract well-known software/IT companies to establish Minneapolis/St. Paul based “outpost developer offices.”

Repeatable Pattern

I’ve noticed a pattern of well-known software/IT companies locating development offices (as opposed to, say, sales offices) in the Minneapolis/St. Paul metropolitan area.

Adobe is, perhaps, the best known success story: they’ve had a presence in Arden Hills for some time that produces some of their marquee products.

Dow Jones’s Minneapolis office is the home to over 100 developers who’ve built for a large swath of Dow Jones’ online offerings.

As part of my involvement in the local developer and software business communities, I’ve become involved in working with Microsoft to create a product development office here.

Less formal, though no less important, is Sun’s investment in Minnesota: Sun has been quietly hiring some of Minnesota’s best software minds to lead initiatives — some public, others as skunk works — that form the basis for the companies resurgence.

Seagate, Oracle, Veritas and others have engineering offices here too.

Larger Pattern

Though these companies were drawn to Minnesota for a variety of reasons they share a common theme:

Minnesota provides an environment where serious software can be built at a significant discount over coastal alternatives.

Interestingly, the pitch for Minnesota here runs parallel to the value proposition offered by “Indian outsourcing,” though without the negatives.

India Looked Good On Paper

The World Is Flat, Thomas Friedman’s oft cited book, illustrates the pre-conditions that made India appear to be an attractive location for outpost developer offices early this century:

Indian culture/society hold engineers in high regard, and India’s institutions are geared towards producing a renewable supply of well trained, employable, productive engineers. Good engineers paired with what was, effectively, free broad band and lower wages, India held great potential.

To a limited extent, that potential was realized: Large enterprise software development projects — those ERP projects/implementations with armies of undifferentiated developers that consultancies sell to giant multinationals — fit well into this model because the physical distance, the many time-zones that separate the participants, and the language difficulties could be overcome by enormous specifications, volumes of documentation, and Process with a capital-P.

However, companies whose product is software — and this point is critical, i.e., places were software was not a side-effect, were it was not used to support the business, but where bytes were the business (whether installed software or web based) — did not generally succeed in India.

For these folks, all of the front-loaded specification work and the delays in communications that a dozen time-zone bring, cause the process to fall down. You can’t build software this way when software is your product. I won’t attempt to provide a comprehensive explanation of why, deferring instead to 20+ years of research and literature, exemplified by The Mythical Man Month.

Enter Minnesota

We, Minnesotans, have had success building software-as-the-product. It’s illustrated by the examples above and from home-grown success stories like Digital River.

Our culture that values engineers. We have institutions to nurture them. We are a wired state, as evidenced by Popular Science when they recognized the metro area as the Top Tech City.

Developer salaries are at least a third lower in Minnesota than on the coastal tech centers. All in, fully loaded, it costs less than half as much to build software here as on the coasts.

Also, we’re at most two time zones or a few hours flight away. I am, in fact, writing this from an airplane on my way to New York, where I’ll be putting the theme of this essay into practice:

For the last few years, I’ve largely made my living building new software products/services for established coastal companies.
Their examples illustrate the sweet-spot in the market that we should target to draw software companies into Minnesota:

Sweet Suite Spot

My clients are venture backed companies transitioning from “emerging” to “established” status. Their stories follow a similar pattern:

The company is founded/funded to produce a narrowly-targeted piece of software. They succeed, building a “best of breed” application in an emerging space. As the broader market that their product lives in matures, buying-behavior changes: people move from buying best-of-breed applications to buying a suite of applications.

An “historic” example of this is the office-application suites. Recall that the choice used to be “Wordperfect vs. Word,” followed by a later choice of “Lotus 1-2-3 vs. Excel.”

When a company emerge as a market leader, with stand-alone best-of-breed product, only to find the market moving towards buying suites then they very quickly need to flesh out the empty pieces in their roster. They will license other people’s products to fill the gaps where they can and they’ll build the rest.

In the office-suite space we’ll examine the winner: Microsoft bought PowerPoint and developed Excel.

There’s a certain unsubtle difference to building out the suite vs. building a new idea in a virgin space: You’ve got a crib: your competitor has done the work to test out what works in a word processor and what doesn’t, so your job is a bit easier.

But it turns our that building out a suite turns out to be very nearly impossible for companies at this (or any) stage. It took the collective total of their entire engineering team arrive at this point; it’s impossible for them to double down and develop new products with their fully utilized existing team.

At this point, it becomes a balance sheet issue: they need to fill in their suites at minimal cost.

To these folks I say, “Enjoy Minnesota! It’s all here.” We’ve got the talent and we’re affordable.

We can build on our success stories. They won’t come to us, but we can actively recruit these businesses. Identifying them won’t be hard. It’ll take a directed, block-and-tackle sales job pairing the incentives that state’s economic development policy makers can offer with folks like me to literally drive the message home, door-to-door, in Silicon Valley and get these companies here.