Socrata

Matt & I are back in the office after spending most of the week in San Francisco at Web 2.0 Expo last week. The show was interesting. Lots of extravagance and an interesting mix of people walking through the exhibit halls. We made a point to ask what brings people to the conference. Here’s a random assortment of why people came to the show and who dropped by our booth for a demo and visit:

1) Lots of people seem to be suffering from information overload throughout the year, fall behind on keeping up with what’s going on, and then use an event like Web 2.0 Expo to catch up over the course of a few days.

2) A lot of business development folks were wandering around, talking up the capabilities of their respective companies. In hindsight and depending on your company’s goals and objectives, I think this is the best ROI for attending a show like Web 2.0 Expo. If a primary goal is to establish relationships with potential partners, I think walking the exhibit halls is more effective than having a booth.

3) A handful of VCs and investment bankers came by to introduce themselves.

4) I was surprised by more than a few job seekers stopping by. Maybe there are cheap tickets to be found, but it seems a little pricey to pay for a ticket to Web 2.0 to walk around and look for a job.

5) Bill Lucchini and Alex Chriss of Quickbase stopped by for a demo of blist. Usually legacy incumbents discount and ignore the up and coming startups, so it was nice to be on their radar and that they made a deliberate effort to come check us out.

What was most interesting to me, however, is how many “web 2.0″ companies were not there. Where were Facebook, imeem, Scribd, meebo, iLike, Mig33, slide, Twitter, Mint, Mahalo, Xobni, TripIt, et al? The widespread absence of these early stage companies made it feel more like an enterprise software trade show than a web 2.0 “unconference.”

There were far more enterprise and web 1.0 companies than web 2.0 startups. Oracle, Microsoft, Adobe, Amazon, Yahoo, Rearden Commerce, ABC, Rackspace, NetApp, AOL, Intel, Nokia, Novell and F5 Networks were all there. The handful of web 2.0 startups I remember include Sprout, Triggit, Morfix, LongJump, Mashery, Photobucket (although now part of Fox Interactive Media/MySpace). Also present were a few tweeners – companies I wouldn’t categorize as either legacy/1.0 or web 2.0. These are the “pick and ax” companies of the Internet creating software and services to allow enterprises as well as web 1.0 and web 2.0 companies to do their thing – Amazon Web Services, Atlassian Software, Jive Software, StrikeIron, Kapow, MindTouch and JackBe.

Web 2.0 Expo was an interesting event. We met lots of smart people and continued to spread the good word about the work we’re doing at blist. If we had it to do over again, instead of renting a full 8×10 (or bigger) booth, we’d either simply go as attendees or at most sign up for one of the modest kiosks in the Long Tail Pavilion. Because it was densely populated with a number of cool startups, the Long Tail Pavilion drew great traffic and it was half the price of our traditional booth.

We all know that the three most important determinants influencing the value of homes are location, location and location. Well it’s true of all real estate, including space on the trade show floor. We moved our booth at Web 2.0 Expo early this morning to a middle aisle with more foot traffic, based on our observations from yesterday. When we selected our booth initially, it wasn’t obvious from the floor plan that our booth faced a wall. We thought it faced “in” to the show, which is what the booths on the opposite perimeter do as well. We had a number of booths to choose from and what looked like bad booths because they were at the back, ended up being good ones because they were along the lunch/break/rest area where a lot of people congregate.

Now we’re in a middle aisle, near our friends from Sprout and across the aisle from Atlassian Software. I think the takeaway for people considering exhibiting at a trade show is to call the coordinator and try to get a feel for what the floor plan doesn’t convey. Ask questions. “Which direction will this booth face?” “Where is the lunch area?”

Matt & I are at Web 2.0 Expo in San Francisco. Like many of you, I lived through the first Internet bubble. One seminal learning that impacted me in a positive way during the first boom was buying a few aeron chairs for my home at an auction selling off Corio’s assets. Their offices were spectacular. They had hundreds of aeron chairs still in plastic wrap, never having been sat in.

I’m sensing a similarly concerning indulgent attitude at Web 2.0 Expo. We bought a used scaffolding and updated the artwork for our first trade show booth. It’s fine. It fits us. Second hand it still cost us about $4,000. That’s a lot of money. We also save a little money by forgoing the $1,200 Internet connection in our booth. We can run blist on our laptops and have the ability to conduct a good demonstration of the capabilities of the application. The Web 2.0 Expo organizers charge you for carpet for your 8 x 10 booth. I like the industrial look of the sealed cement floor in our booth.

Candidly I’m not sure if the return on investment will be positive or negative on our trade show booth. I’ll let you know in a few months after we’ve logged some mileage out of it. There are a few companies here at Web 2.0 Expo which have apparently spent hundreds of thousands of dollars on their booths. I’m pretty up to date and know what many companies, including startups, are up to. But some of these are companies I have never heard of. Last night there were a number of over-the-top parties hosted by other equally unknown startups.

I hope this indulgence is experimental – companies just trying to find their way in the marketing world, learning what works and what doesn’t. I’m hopeful the lavish spending on booths and parties doesn’t reflect a trend reminiscent of 7 or 8 years ago.

What does it mean when blist says that we want to democratize working with data, breaking our dependence on DBAs? Do I think the DBA profession is going away? No, not entirely, but their numbers will be fewer and their challenges will be greater. Complex systems will still require a DBA – either to model a 75 or 100 table schema or to keep a large database running. The democratization we’re talking about is empowering mainstream people to organize data models comprised of 1, 2 or 3 tables.

For example, an applicant tracking system can be simplified to two primary tables – applicants (people) and interview results. The two fundamental entities in a recipe blist are recipes and ingredients. Why shouldn’t a mainstream person be able to design data structure for these? Of course, they should.

One parallel way to think about this is to think about the demise of professional sportswriters. Decades ago we relied on sportswriters to tell us the basic facts – the outcomes of the games. As a youth I was a voracious consumer of baseball box scores in the newspaper. The next morning was the earliest I could get the details of the prior days games. Obviously today access to the outcomes and details of games is pervasive and ubiquitous. There are sites that have realtime boxscores – I can “watch” a game play by play if I want to. There are hundreds of bloggers who “live blog” key plays throughout the duration of games. One casualty of the ubiquitousness of this information is the ordinary sportswriter. We no longer rely on sportswriters to inform us of the basics. Sports writing has been democratized. Are sportswriters extinct? No, but their numbers are fewer and the ones who are able to survive do so by offering much more than the facts. Frank Deford thrives as a sportswriter because he analyzes, evokes, provokes and entertains. There will always be a need for the Frank Defords because very few of us can as eloquently tell a yarn around the subject of sports.

DBAs will still be needed for those things mere mortals can’t do with a database. But for your average, ordinary tasks involved with organizing data, I’m convinced we’ll all do that for ourselves.

We will be demonstrating blist, the world’s easiest database, in the exhibition hall next week at web 2.0 EXPO, at the Moscone Center in San Francisco. We’re really looking forward to it. If you’ll be attending or exhibiting, drop by and say hello and check out all the new features we’ve been adding.

Never. I’m serious. I know the customer is always right. Well not this time. blist is delivered as a service because that’s where it makes sense to run it – for you – not just for us.

A number of people have asked about our plans to let you install blist and run it locally. That’s not going to happen. Data wants to be shared. It wants to be accessible from wherever you are. It wants to be accessible from a multitude of devices. It wants to be accessible programmatically. For those things to happen, data needs to be “in the cloud” as they say.

Obviously there isn’t really a cloud. The Internet isn’t a network of arteries and veins in which data builds up like plaque. Companies like blist choose to offer their services via the Internet.

We offer blist as a service in part because it helps us too. It lowers our support costs by ensuring that everyone is using the most current version of our software. It lowers our development costs because we develop for exactly one platform – the one we run on our servers. It lowers our operating costs in a multitude of ways.

But more importantly we offer blist as a service for a major philosophical reason. blist wants to democratize working with data by empowering mainstream users – ordinary people – to organize data without relying on a database administrator (DBA).

Think about how mainstream users now draw diagrams with Visio and make presentations with PowerPoint. Those functions used to be performed centrally by specialists, much like data is still organized by a specialist – a DBA.

If blist is going to succeed at democratizing working with data, we have to eliminate the two dependencies that keep you beholden to the DBA. First, we have to dramatically improve the user experience of working with data so that you can organize it yourself. Second, we have to relieve you of the operational burden of keeping the database running.

In addition to designing schemas, DBA’s fix block corruption. They install software patches. They perform backups and restorations. DBAs are constantly monitoring, tuning and tweaking the database to keep it running optimally. I call it the “muck” of running a database.

By moving the database to the cloud, there’s no local database that you need to keep running. There’s no muck.

We believe breakthrough innovations in usability and freeing you of the operational burden of running a database will pave the way to democratizing working with data. It’s our belief. It’s our mission.

We launched the blist service in beta in late January of this year. Since then we’ve been managing what I think of as the five tensions competing for our limited software development resources. They are allocating development budget between:

1) fixing bugs thereby making the application more stable

2) improving performance

3) adding new features

4) instrumenting the application

5) automating operations

You can’t ignore any one category for too long. Focus only on new features and users grow impatient waiting for bugs to be fixed and performance to be improved. Ignore instrumentation and it’s harder to know what areas of the application need more work and it takes more effort pulling together metrics to run the business. Ignore automating ops and your valuable software engineers end up spending too much time performing manual system administration tasks.

The right solution is to invest in each category. The difficulty is in figuring out the right ratio. Candidly, we haven’t figured it out either, otherwise I’d tell you. What’s most important is to constantly reevaluate the service and asking what area needs the most investment and have a development methodology that allows you to be nimble and change priorities often. Analyze the data. Ask your users. Read the entries in the community forums. Adjust. Apply. Measure. Adjust. Apply. Measure.

We’d love to hear from you. What must-have features are missing? What’s working? What’s not? What’s too slow. How can we make blist better for you?

Matt and Adam have been hard at work developing quick, how-to videos for key features in blist. We’ll add more videos over time, but here’s the initial video library:

Starting your first blist

Saving data in CSV format from Excel for import into blist

Filtering data using the lens builder

Creating a custom pick list

Creating a blist in a blist

Adding a list in a cell

Creating a new blist via discovery

This morning I had an informal discussion with a candidate who’s thinking about leaving Microsoft and joining a startup. He asked the question “How do you avoid adopting a Microsoft culture?” In hindsight, the basis for his question makes a lot of sense. I left Microsoft to start blist. Our website and many of my introductory emails to prospective candidates includes a statement that says something to the effect that “our engineers are mostly ex-Microsoft and ex-Amazon.” He also recognized that one of our board members is from Microsoft. So it’s understandable that he would think we’d have a Microsoft culture.

In that he has that question, maybe others do too. So here’s my answer, for the benefit of anyone and everyone who reads this post.

blist doesn’t feel anything like Microsoft. I only spent a year there and one of the reasons I was anxious to leave was so that Microsoft didn’t change me too much. We are conscientious about not introducing unnecessary layers of management or bureaucracy. Our first employee, a software engineer, celebrated his first year anniversary with blist recently and commented that it was the best year of his career, in large part because of the pace, energy and lack of meetings and bureaucracy. We have no program managers (yet). We have no SDETs (yet). Those roles won’t be vacant forever, but now is the wrong time for them at blist. Soon we’ll add a couple more engineers, and at that point one single, solitary program manager makes sense. I’m not opposed to program managers or SDETs, but the ratio needs to be something like 6:1:1 not 3:2:2 like at Microsoft.

At Microsoft, teams are built top down. I prefer bottoms up.

Unfortunately, the power of political persuasion is necessary to succeed at Microsoft. At blist we value ideas, not politics. A good idea will get done. A bad idea won’t. If someone suggests a bad idea and we discover that in discussion, there’s no animosity or negativity. If someone suggests a good idea, he or she didn’t win – the idea did. We’re democratic, but it’s not a democracy. By that I mean we discuss big ideas but not the little ones. One of the benefits of having smart people is they usually figure out the right thing to do, including knocking down the the little issues and surfacing the big ones.

We don’t have very many meetings at blist. The only recurring ones are our sprint kickoffs and recaps. Other than that, meetings are usually spontaneous and don’t usually take place in a conference room. We usually just talk through an issue in real time. If you need help with something, wouldn’t you rather have immediate help instead of scheduling it for next Wednesday at 3:00? By the way, we never schedule meetings around people’s schedules. If you’re here when we meet, feel free to join, but if not, that’s OK too. We’ve never had a mandatory meeting. If the topic interests you, attend. If it doesn’t or you can’t add value, don’t attend. The result of this is that meetings tend to be quick and engaging. No one checks email on their iPhone. People don’t bring their laptops. It’s a discussion. Almost always something gets decided and you leave the meeting feeling like something was accomplished.

Our development approach is a blend of what you’d find in a startup and what you’d see at Microsoft. We do week long scrum sprints that are very agile, nimble and quick paced. We apply some self imposed rigor and discipline around our engineering practices. For example, you can’t check code into subversion without a formal code review. Those reviews aren’t cursory. They’re in depth. Good questions are asked. Algorithms are scrutinized. Teamwork emerges. I walk through the front door of our office 3 or 4 times a day and almost always I see a code review taking place, with two engineers sitting side by side, one pointing at the monitor, walking the other through the code. It’s refreshing to see. Physically our environment is communal. Sorry Joel (on Software), we prefer to work in an open area where we can communicate and collaborate freely; we don’t want enclosed offices at this stage in our life cycle.

Finally, two words are entrenched in our culture differentiate us substantially from Microsoft: proximity and diversity. The former – proximity – has to do with how close we want to be to our users. We want that proximity – to hear directly from people using our software about what’s working and what isn’t. The latter – diversity – is about how we define our roles. We like broad diversity in what we work on. Everyone wears a lot of hats. We’re all entrepreneurs. We aren’t constrained by the title on our business cards.

So if any of you have shied away from blist for fear its culture would feel like a mini-Microsoft, fear not.

This evening Google announced its much anticipated web services initiative dubbed Google App Engine. While I’m thrilled to see more of the building blocks of Internet scale, utility computing moving to the cloud, I wanted to quickly write what I think might not be such an obvious side effect. That is, I believe this announcement is going to drive python adoption in a big way. Currently the only way to interface with Google App Engine is by writing python code that runs on Google’s server farms. Those sitting on the fence about python now have a huge motivation to jump into the python side of the yard.

Python doesn’t get the notoriety or attention of Ruby on Rails or java for sure and isn’t as widely used as perl or PHP, but python has quietly become the language of choice of the professional systems engineer. Like ruby and perl, python is a dynamic, interpreted, scripting language. Like ruby and java, it’s fully object oriented. Python enforces some stylistic and syntax conventions that make it more readable and therefore easier to maintain than other languages.

A systems engineer is someone who writes software to automate the deployment, management and monitoring of servers. They are programmers who spend part of their time writing persistent code that sticks around for years and part of their time writing single use utility programs. Python works great for both. While python isn’t a household variety programming language, it has become the standard for systems programming at two of the biggest Internet scale software companies – Yahoo and Google.

We’ll have to see over the upcoming months how Google compares and differs from Amazon Web Services but I for one am thrilled to see that adoption of python is going to go way up.