Similarly, you don’t work on great technology at a startup.  Startups, by and large, aren’t about technology — at least, not the Web 2.0 startups like Facebook, Foursquare, Twitter, Groupon, etc.   They are about business model discovery.  So if you are fundamentally a technologist at heart, whose heart sings when you’re making a better file system, or fixing a kernel bug, you’re not going to be happy at a startup.   At least, not if the startup is run competently.

Ted might have a point about Web 2.0 startups, but there are still  technology startups in software. These startups generally need to prove out their product and market rather than their business model. Business model innovation is sometimes part of the exercise. But more often the company is executing on a standard business model, with some need to validate the market, a greater need to validate/implement the technology, and most importantly a need to link the innovative technology to an addressable market. Much has been written about this, because it is the traditional structure of startups.

Web 2.0 startups are trendy right now because they are disturbingly capital efficient. Companies like Diapers.com and Groupon have negligible technology risk. Proving out the business model costs very little money in the age of Everything as a Service (EaaS). They generate good stories about selling virtual goods before they exist, of zero-inventory supply chains and zero-employee companies. Investors like the idea of low risk high reward returns, even if they are still uncomfortable with the decreased emphasis on capital.

But while those companies are grabbing headlines and mindshare there is plenty of deep technology innovation going on in startups. There are more innovative database startups at various stages in their life than I can remember right now (e.g. Vertica, Clustrix, Tokutek), not to mention the NoSQL startups (Cloudera, Basho), messaging companies (Solace, Kaplan, 29west), visualization companies (Panopticon, Spotfire), and hundreds of other software startups with a sizable technical product innovation challenge ahead of them. And there are plenty of recent success stories that wouldn’t have been able to build their company without great technology (VMware, Google, Amazon).

It’s great that business model innovation is well enough understood that it is top of mind for developers. Understanding what key innovations are required, be they business or technical, and what are the most efficient ways to validate them, is key to success in any startup. It’s too bad that some engineers think that there is no longer a place for great engineering at startups. Not all startups require great engineering, but many still do.

Ted’s trying to defend Google against claims that Facebook is poaching all the engineers. From where I stand, he’s right. Plenty of great engineers are going to work at Google, more than are leaving. And Google is able to run projects like ChromeOS, LLVM, and AppEngine. Projects that wouldn’t be the same in a startup.

But if you were going to find fault with Google in this, consider: Googlers now believe they are doing engineering that can’t be done anywhere else. If that was true, it would mean they don’t have anything to fear from startups. Believing that is a step towards the hubris and ossification that Google is working so hard to avoid.

Consumer goods suffer greatly from this problem. They are produced and distributed by large and complex organizations. Consumers, particularly in traditional retail settings, have little to go on but what it says on the box and the brand. And in recent times, brands have become commodities themselves, with everyone from Martha Stewart to Sesame Street selling their name. In order to make this market work, we need better technology at the point of sale.

Enter Buy It Like You Mean It.

Send them a barcode (via SMS or otherwise) and they will send you back a customized report about that product and how it aligns with your personal political or social inclinations. This information is crowd-sourced, Wikipedia style, from what I imagine will become an active community of corporate watch dogs. In the short term, they are focusing on chocolate, to build a complete database and work the bugs out of their system. But I’m sure it won’t be long before they branch out. And probably build an iPhone application.

I’m a huge fan of the application of technology to improving market dynamics, and especially of applying technology to level the playing field between consumers and corporations. Since the first time I heard the idea, I’ve been excited about Vendor Relationship Management (VRM), the dual of the ubiquitous Customer Relationship Management (CRM). A lot of this stuff is still in the conceptual stages, such as ProjectVRM at Harvard. Buy It Like You Mean It is a refreshingly concrete application of the same ideas.

I imagine a future in which self-organized blocks of consumers, aided by software, can effectively hold their own against even the largest vendors. Chinese “team buying” (Tuangou) is an early example of this. I look forward to using technology to share information with other consumers about my credit card company, auto mechanic, airline, or hotel. Actually, I can already do that. So instead I look forward to using technology to digest and aggregate all the freely available information, and to even more directly manage my relationship with these vendors, all the way to making purchase decisions for me.

Much appreciation to Taza Chocolate for hosting the launch party. They are a stone ground chocolate factory in Somerville, making ultra-high end chocolate. If you have a chance to tour their factory, I highly recommend it.

The model of being more-realtime has it’s problems. In order to use the tool, I need to expose everything I do in my browser (when I don’t remember to turn off the tool). The upside is the medium system gets more information, which may make it more valuable to other users. The downside is I have less control over what goes into it. The system I was conceiving of, which would be similar to Pearl Comments, would just be focussed on collecting comments that users actively gave.

Pearl Comments is actually an interesting bit of technology, which is being under-utilized in its current incarnation. They use it to moderate interactions between web designers and clients (it enables clients to privately comment on any page, and to see other comments from the developers or clients). I think a system like that, extended in a social way (so I put comments into groups, and my friends are members of groups, and I see all comments from groups I am a member of) would be better.

Let me know if you want a me.dium beta invite. It’s not going to be very interesting unless a bunch of people use it.

Jesse Vincent just shared with me a
copy of their book
href=”http://www.amazon.com/exec/obidos/ASIN/073571410X/innocuousorg-20/ref%3Dnosim/104-5794965-3152724″>De
fensive
Design for the Web: How to Improve Error Messages, Help, Forms, and
Other Crisis Points. It was a very quick read this morning
before breakfast, and I think also worthwhile, even though I am not
currently a builder of real webapps. I find well designed web
applications interesting, and like learning more techniques for doing
it. This book is mostly about user-level guidelines, rather than
technical detail. But that is important too, since when building
technical frameworks it is important to enable the right kinds of user
interaction.

The book is pretty good. It gives a set of 40 guidelines with real
examples of sites that break and sites that follow the guideline. The
guidelines mostly focus on what to do when something goes wrong or how
to keep something from going wrong. The core idea is that when looking
at the usability of your website, the error cases are as important as
the non-error cases.

One area in which I disagree is their support of restrictive forms.
They encourage sites to prevent users from entering incorrect data
through the use of drop down lists (for things like states or dates)
and client-side validation with JavaScript. The principle is that if
you keep users from ever entering bad data, then you are sure they
won’t have a confusing experience fixing errors. I tend to find that
these restrictive forms harm my user experience more than they help
though. I’d rather type a free-form address, or phone number, or date,
and be corrected, than have to mouse- or arrow-around in 6 drop down
lists to enter two dates.

Combining client- and server-side validation of form data is an
interesting challenge for framework development. Is it possible to
easily combine these so that site developers don’t have two divergent
code bases (most likely in different languages) to maintain?
Consolidating this functionality probably requires JavaScript code
generation, so that the server-side encoding of the validation rules
can be pushed down to the client. I’m not aware of any JavaScript code
generation that really makes for a usable system, so maybe this idea
would be doomed anyway.

Because it ignores technical details and focuses on user experience,

href=”http://www.amazon.com/exec/obidos/ASIN/073571410X/innocuousorg-20/ref%3Dnosim/104-5794965-3152724″>De
fensive
Design for the Web is a quick read. It’s guidelines are not
perfect, but they are reasonable. It presents you with a helpful
checklist which can be used to improve your crisis points, and thus to
improve your sites whole user experience. And it is lightweight enough
you can throw it at a coworker without be charged with assault. I
recommend it for people doing webapp development.

The first issue was that Typo doesn’t like to run in a subdirectory on a webserver. That is, it wanted to be at ntsh.innocuous.org/, not innocuous.org/ntsh. This offended my sensibilities somewhat, so I decided to beat it into submisssion. This involved tracking down a bunch of places where paths were hard coded, which included a few places in the templates and the CSS.

The second issue was that FastCGI on lighttpd seems to have been designed for php. You can easily tell it to delegate *.php to FastCGI. You can tell it to delegate /ntsh/* to FastCGI, but that has the problem that /ntsh/stylesheets/base.css doesn’t work, because the RubyOnRails dispatcher doesn’t know how to serve static pages.

You also have the problem, and this is the showstopper, that for some reason the AbstractRequest.request_url_base function helpfully strips off the directory of your request path when you use it this way. That is, it turns xml/rss/feed.xml intofeed.xml. As you might imagine, losing the xml/rss part confuses the cool new routing feature of Ruby on Rails. So this was unacceptable.

I had to give up my delusions of configuring lighttpd in some clean way, and instead use the trick that a bunch of web pages recommended: server.error-handler-404. This configuration file setting tells the server to delegate 404 errors somewhere, and that somewhere can be the Typo dispatcher. Combined with the conditional configuration functionality of lighttpd, this is actually quite sufficient to get Typo up and running. But it still feels like a hack for some reason.

The conclusion I’m coming to, as I’ve come to many times before, is that I’m a bad sysadmin. I expect to be able to bend software to my will, and make it work the way I want, which should be elegant and conform to my expectations. When doing sysadmin work, it is important to use the software you are given, the way someone else designed it to be used. But it always has to get to be 1am before I remember this principle.

For anyone who is interested, here is the relevant chunk of lighttpd.conf:

$HTTP["host"] =~ "\.innocuous\.org$" {
    server.document-root = "/var/www/vhost/innocuous.org/pages"

    $HTTP["url"] =~ "^/ntsh/" {
        server.error-handler-404   = "/ntsh/dispatch.fcgi"
    }

    fastcgi.debug = 0
    fastcgi.server = (
                "/ntsh/dispatch.fcgi" =>
                    ( "ntsh" =>
                        (
                            "socket" => "/tmp/ntsh.socket",
                            "bin-path" =>
                              "/var/www/vhost/innocuous.org/ntsh/public/dispatch.fcgi",
                            "min-procs" => 1,
                            "max-procs" => 5,
                            "max-load-per-proc" => 4,
                            "idle-timeout" => 20,
                            "bin-environment" =>
                              ( "RAILS_ENV" => "production",
                                "RAILS_ROOT" => "/var/www/vhost/innocuous.org/ntsh"),
                            "check-local" => "disable"
                        )
                    )
        )
}