Business of Software 2010

BoS alternates between San Franscisco and Boston; this year it was in Boston. There are plenty of excellent summaries online (here, here, here, here), and an especially nice set of photos here.

The conference was packed full of great speakers, mostly well known. I am sure the most “expensive” person in the lineup was Seth Godin; he is an excellent speaker and had interesting content, but wasn’t as relevant to me as some of the others.

The high point of BoS was Joel Spolsky’s closing talk. Unlike everyone else, he used no slides, and simply sat at a table to tell us the story of his last year or so. I was a bit surprised at his public airing of partner grievances, but that was probably necessary to tell the (very worthwhile) story of his transition over the last year from the “small, profitable company” model to the “go big” model. The former can make good money; but only the latter can make a broad impact to build a (perhaps slightly) better world.

I also especially enjoyed Erik Sink and Derek Sivers telling the stories of their company sales. My own company sale experience was more like Erik Sink’s.

In the past, Business of Software has posted the videos for year N during the marketing runup for year N+1; I suspect the same will happen this time. When those videos appear, watch them. Especially keep an eye out for Joel’s criticism of Craigslist, with which I agree.

Strange Loop 2010

Strange Loop is held in, and named after, the Delmar Loop area which spans University City and a bit of St. Louis. The 2010 event was much larger than the 2009 event; I don’t know whether it will be possile to accomodate 2011′s crowd in the Loop area or not; I’ll certainly attend either way.

Again there are plenty of summaries online, including here and here.

The highlight of this event for me was Guy Steele’s talk on parallelism. Unlike some commenters, I greatly enjoyed both the first half of the talk (a stroll through some ancient IBM assembly code) and the second half (including the Fortress example code). I’ve been inspired by this talk and criticism about it to put together my own upcoming code-centric talks, in which I’ll touch on the key parallelism ideas briefly, then step through several code examples in various languages.

I also spoke at Strange Loop, in a 20 minute slot, on Lua (video). Most of the feedback on my talk was positive, particularly of the “why, not how” approach I used to make the best use of 20 minutes. A few people would have preferred a longer talk with more “how”; I might put together such a presentation at a later date.

Disclosure: Oasis Digital sponsored Strange Loop.

(first clojure-conj)

At Clojure Conj I had the strong impression of being at the start of something big. I believe that Clojure, in spite of the needlessly-feared parentheses, has more “legs” than any other of the current crop of ascendant languages: getting state right (and thus making it possible to get parallelism right) is more important than syntax. Based on the folks I met at the Conj, I’d say Clojure has exactly the right early adopters on board.

As usual plenty of others have posted detailed notes (here, here, here, here, here).

The talk that stands out most to me was not exactly about Clojure. Rich Hickey’s keynote was about the importance and process of thinking deeply about problems to create a solution. In a sense this is the counterpoint to agile, rapid-iteration development, suitable to a different class of problems. Clojure exudes a sense of having been thought about in depth, and Rich is obviously the #1 deep thinker. When this arrives on video, watch it. Twice.

I also enjoyed Rich’s impromptu Go clinic at the pre-conference speaker (and sponsor) dinner. Note that Go has totally different rules from the similarly named Go-Moku, and is not to be confused with Google’s Go language.

Disclosure: Oasis Digital sponsored Clojure Conj.

Back to Work

I’ve had very little time for my own projects this month; between the events, most of my available hours were occupied with Oasis Digital customers. My mind is bursting with worthwhile ideas to pursue.

The Strange Loop crew only recorded video in the two largest venues (out of six), so I made a “bootleg” video of my talk, for your viewing pleasure:

The video/audio sync starts out OK, but drifts off by a second or so by the end. The drift is minor, so it is reasonably viewable all the way through. If you don’t have Flash installed (and thus don’t see the video above), you can download the video (x264); it plays well on most platforms (including an iPad).

The slides are online below, and are also available for PDF download.

Video Hackery

This video recording was an experiment: instead of hiring a video crew (with professional equipment), or using my DV camcorder, I instead used the video recording capability of my family’s consumer-grade Canon digicam. This device has three advantages over my DV camcorder:

1. No tape machinery; no motors; thus no motor noise in the audio.
2. Smaller size, easier to carry in and out.
3. Directly produces a video file, easily copied off its SD card.

As you can see from the results, the video quality is adequate but not great. Still, I learned that if I want to increase the quality of recording, the first step is not to use a better camera or lens! Rather, it is to bring (or persuade the venue to provide) better light. For good video results, the key is light the speaker well, without shining any extra light on the projector screen. With that in place, a better camera make sense.

The audio was a different story. Like nearly all consumer video cameras (and digicams with video), mine doesn’t have an external audio input, so the audio (from ~12 feet away) was awful. As a backup I had used a $75 audio recorder and a $30 lapel microphone, and that audio is very good, certainly worth using instead of the video recording audio track.

To combine the video in file A with the audio in file B, I used the ffmpeg invocation below. I reached the time adjustments below in just a few iterations of trial and error, by watching the drafts in VLC, using “f” and “g” to experiment with the audio/video time sync. I also trimmed off a bit of the bottom of the video, and used “mp4creator.exe -optimize”, which I had handy on a Windows machine, to prepare the file for progressive download viewing.

ffmpeg -y -ss 34.0 -i WS_10001.WMA -ss 34.0 -itsoffset -12.05 -i MVI_4285.AVI -shortest -t 8000 -vcodec libx264 -vpre normal -cropbottom 120 -b 400k -threads 2 -async 200 Cordes-2010-StrangeLoop-Lua.m4v

The remaining bits of technology are FlowPlayer, a WordPress FlowPlayer plugin, and Amazon’s CloudFront CDN.

I finally have the right opportunity to do so; later this month at the St. Louis Innovation Camp mini-conference I’ll give an updated talk on the same topic, on Friday, Feb 26, in a time-slot to-be-determined. The talk:

The Software as a Service Business Model

In this talk, I will share some “lessons learned” from five years operating a Software as a Service business. Topics will include:

• What is SaaS?
• Starting a SaaS business
• SaaS Product Management
• Cash Flow
• Customer Retention
• Infrastructure and Operations

• Geoffrey Moore’s opening talk was an early highlight of the conference; I’ve often been disappointed when a well-known person from somewhat outside a conference’s focus is invited to talk, but it turned out that Geoff had ample highly relevant content. Most notably, his 9-point recommendation for small software firms is dead on.
• It is highly likely that my next project will be in one of the 20-something categories that Paul Graham thinks will grow. I’m not sure if this is saying much, though, because his points were so numerous and broad.
• Mat Clayton had strong points about A/B testing, but I felt a bit dirty merely being in the room for his list of “dirty tactics” for social networking promotion. I heard similar feedback from other attendees.
• Don Norman’s talk was excellent, but would have been more excellent if it was a bit shorter and thus tighter.
• My favorite talk of the conference was Ryan Carson’s. In conversations about his talk, I heard the idea of several directions that the essence of Ryan’s message was to trade off, to give up profits in order to do various good things instead. I strongly suspect, though, that Ryan is doing the best he can, i.e. the strategy he proclaims is also how he maximizes profits (for a company like his).
• Paul Kenny talked about telling stories. You must do this. I can’t explain just how important this talk was, so I won’t.
• Pecha Kucha was this conference’s name for lightning talks. As elsewhere, these talks are usually very dense and very good, because the format forces the speaker to discard all the slow parts, all the boring parts, all the exposition, and instead go directly for their key points. It works.
• I noticed a large number of people using TweetDeck, and adopted it myself. It is a higher-mental-bandwidth way to consume Twitter and Facebook data streams, and is well suited to the a sane Twitter usage pattern of one short intense sessions per day.

I have only a few criticisms:

• A few of the speakers went long. Though it would annoy the speaker, it would be much better for the conference if all sessions were promptly stopped on time.
• Luke Hohmann’s talk on “Innovation Games” felt like a sales pitch for his company, even though he tried hard to talk mostly in general terms.
• The schedule was a bit too dense. We needed more slack between / before / after, to discuss and absorb the information.
• It would have been nice to have a talk address the business of custom software development.
• The swag, in the form of a slanket / snuggie, is much too physically large for an event attended mostly via air travel. Of course I could have discarded it (and some attendees did), this would have felt like waste. I would have preferred if Neil had simply scrapped it and kept that money as profit.

How do you attract top developers to work on something that sounds rather dull, like a bug tracking application? It mostly shuffles data back and forth between screens and reports and database tables – far too boring for top developers.

Of course that’s an exaggeration, but a relevant one: at Oasis Digital much of our work is on enterprise business process automation, database-centric applications, and could likewise be described casually (though not accurately) as “just” shuffling data between screens and tables. I worry that our work will not sound interesting to prospective hires.

This week at the Business of Software conference I got a chance to ask (confront?) Joel about this. He offered a great, four-part answer, which I present here with my own additions mixed in. I don’t have careful notes about which bits came from Joel, so you are welcome to give him all the credit and me all the blame.

1) There is Interesting Technology Inside

Even in an application which, at first glance, just shuffles data around, there can turn out to be a lot of very interesting work inside. This is true of FogBugz and it is true of our work at Oasis Digital as well. Here are some examples of interesting work here, all of it inside dull-sounding applications:

• Process metadata and generate code and GUI elements. Top developers certainly are those who solve a family of problems with generic code and metadata, rather than tediously one at a time.
• Process large hierarchies efficiently using Celko’s nested sets representation technique. Top developers are all about using better data structures.
• Custom GUI components to provide a drag-drop, direct manipulation approach to visualize and modifying data. The results has both a high “wow” factor, and is genuinely useful – a willing combination for top developers.
• Integrate a Prolog-based rules mechanism to provide a vital algorithm in one page of code, that would have required countless pages of code and hundreds-to-thousands of hours of work to do otherwise. Using a radically different language to solve a problem with a small fraction of the effort… exactly the sort of thing a top developer wants to do.
• Generic data replication mechanism: building our own was certainly more interesting work than adoptions one off the shelf.
• Learn how OLAP works, implement an OLAP ETL process.
• … I could list many more examples

2) One Level Down the Stack

Fog Creek aims to make compellingly good software because that is how you outcompete established competitors in a commercial shrinkwrap market. Oasis Digital likewise has this aim for a different reason: it is our intended niche. We aim to differentiate ourselves from “yet another outsourced dev company” by building unexpectedly good software. We don’t want customers who will be happy with the results available from the typical development firm; we want customers who are playing to win.

To meet either goal, it is sometimes necessary to work at one level of abstraction lower than would otherwise be necessarily. Joel’s examples were their own data grid and their own AJAX library. Some of our examples are listed above.

This kind of work, further in to the details, is generally more compelling to top developers.

Caveat: Don’t do this very often. If you want to ship software anytime soon, you need to mostly use off the shelf libraries that already work. Don’t build a data-grid, for example, unless you really need something that you can’t find in any off the shelf products. We don’t have our own data-grid; we use (among other things) the excellent grid products from Developer Express.

3) Problem Domain is less important than other factors

Joel has observed that developers aren’t as picky about the problem domain of their project as one might think; rather, other factors are more important: great co-workers, nice working environment, working for a boss who is a developers, etc. Top developers want to work on a high quality end product worthy of taking pride in.

4) All Projects need a lot of Grunt Work

To build a high quality product, in any problem domain, will require spending a great amount of your time on grunt work: tracking down bugs and fixing them, filling in feature “holes”, cleaning up design problems, improving GUI layouts, and the like. This is true for any problem domain. Top developers know this, and just get on with doing that work when needed.

Conclusion

My worry was unjustified. Our work at Oasis Digital is interesting and worthwhile, both for our customers and for our developers. To grow our team, we must focus on making it an increasingly good place to work.

A final anecdote: Joel mentioned that FogBugz 6 was feature-complete in the summer of 2006 – that means they spent around a year polishing it, fixing bugs, filling in holes, etc. That shows a phenomenal amount of dedication and discipline to create quality software.

This is the first year for this conference, so I have no idea how popular it might or might not be. At “worst” case, it’s a small crowd, which usually results in great conversations.

Update: Brian Button pointed me to this interview with Tim Lister, which includes hints about the salacious topics he’ll talk about at the conference (Tim, co-author of Peopleware, is a headline speaker at the BOS conference).

It appears to be “A-list” event, meaning that I’m not likely to make the cut anytime soon.

Fortunately, many TED sessions are available to the rest of us online: TEDTalks. Here are some that I bookmarked to watch again; the download links are for QuickTime videos. Many of these are also on Google Video or elsewhere.

Burt Rutan

Barry Schwartz

Malcom Gladwell

Steven Levitt

Nicholas Negroponte

Hans Rosling (One word summary: Wow.)

Ken Robinson – Do schools today kill creativity?

Dan Gilbert – The (misguided) pursuit of happiness

The Secret of Happiness, according to Dan Gilbert:

1. Accrue wealth, power, and prestige. Then lose it.
2. Spend as much of your life in prison as you possibly can.
3. Make someone else really, really rich.
4. Never ever join the Beatles.

(watch the video for the story behind this)

The 1 hour audio recording (Olympus WS-100 digital voice recorder, Audacity cleanup) is available here: SAASTalk.mp3

A transcript of the talk is available. In the talk I mentioned Paul Graham’s The Other Road Ahead, which is shorter and easier to read the my talk transcript.

A couple of people at Code Camp asked if I could come give a similar talk in-house at their firms. Yes – please contact me with the contact form to arrange a date.

The handout contents follow.

Selling your Software as a Service

Kyle Cordes
May 5, 2007

An Encouraging Idea

When you open up an IDE/editor at home, on your own time, you have a remarkable power in your hands: you can create something that you own (modulo some employment agreements). It is yours to sell, to give away, or to decline to do either, on your own terms. Likewise a company has this on a larger scale.

For the last few years my firm has been selling access to an application we wrote (and continue to write) as a service, charging a monthly fee for use, hosting, and support. I won’t name names or describe our product in detail (this talk is not spam), but I will share some things we’ve learned along the way.

What is SAAS?

Delivering a software product (especially a complex “enterprise” system, less so with consumer products) involves more than just bits in a file / on a CD-ROM:

1. Delivery of the deployable code

2. License (legal right to use it)

3. Hosting: hardware, deployment, and management thereof

4. Support for the server(s) / software on the servers

5. Support for the end users / software on their PCs or other devices

In a consulting or in-house project, the most common type of project for the audience here at Code Camp, you sell hours of labor to do the things above.

In a commercial software product company, you bundle #1 and #2 for a price, then perhaps sell a service contract for #4 and possibly #5.

With Software as a Service (SAAS) you bundle #1, #2, #3, #4, and possibly #5, then sell the result for a yearly / monthly fee times some measure of volume (per computer, per user, per transaction, per site, etc.). A company selling their software in this way is sometimes called an Application Service Provider.

The Business Model

From a business perspective, SAAS offers a recurring revenue stream rather than “spiky” up front sales. In the short term this can make higher investment demands (since the revenue arrives more slowly). In the long term, though, recurring revenues are very amenable to a sustainable ongoing business.

On the downside, as a SAAS vendor you are at greater risk of ongoing payments stopping, vs. up-front payments in full when the sale is made.

Collections are typically much less of a problem with SAAS: you will generally be paid by customers in a timely way (as they would pay for electricity, bandwidth, and other ongoing utility services).

This gradual arrive of revenues will shape your company’s financial decisions: you need to meter expenses to match.

Hosting

With SAAS, your customer stays out of the “hosting business”, but you get in to it. One way to offer reliable hosting is to put your servers in a colo facility; you can typically get a full rack (with power and bandwidth) for less than $1000 per month. This will provide redundancy in the power, air conditioning, and connectivity, which would be much more costly to provide in-house.

You will become experts in hosting, by experience. You will host more instances of your software than any one customer would, so you are in a better position to do a good job doing so.

Another route, for a smaller operation, is to rent a single dedicated server or even a “virtual” dedicated server. Or, go utterly virtual and use Amazon EC2 and S3 as your infrastructure.

Support / Operations

As an SAAS firm you can offer much more hands-on support than a traditional software vendor, because you have direct and immediate access to the production systems serving your customers.

At the same time, this access will expose your team to the customer’s pain points, making it more likely those problems are fixed soon.

With SAAS you can readily deploy updates regularly (weekly / monthly) at low cost, enable end-to-end agility. Paul Graham wrote about this in “The Other Road Ahead”.

What do customers like about SAAS?

Customer love not paying for unproven software up front, even if they have abundant cash and even if the software is in use elsewhere. They avoid making an unrecoverable investment in case their needs change or the software turns out to be inadequate.

Customers generally like not running a hosting operation: not operating a data center, not hiring employees for it, etc.

Customers benefit with SAAS’s easy scaling up or down as their needs grow and shrink. Financial decision makers often prefer costs that scale smoothly with business volume.

What do customers not like about SAAS?

Customer may be concerned that they have less direct control over an application supplied SAAS, than one hosted in-house, with less ability to persuade an operator/developer to drop everything and fix it now.

Eventually a customer may spend more with SAAS (at least in terms of the checks written to the software vendor, though perhaps not in total cost) than they would have spent buying a license up-front; thus they are prone to regret that they didn’t buy an up front license.

A customer may want to customize the software in a way the vendor does not offer.

Start Fast

SAAS provides considerable flexibility in delaying software work past the product launch; “admin” features can be less complete and more rough, if they are used primarily by the vendor’s staff instead of by the customer, and can require deeper system knowledge.

There is also a risk that the ability to get by with rough edges will too easily allow you to never truly finish the product.

What’s it like to sell software this way?

The biggest difference in selling SAAS is a more substantial long term relationship with the customer, both operationally and financially. This can be a great advantage – with a close customer relationship you will be in a position to understand their needs more fully, and innovate in your software to meet those needs better.

Customizations

The purest SAAS way to offer customizations is to not charge hourly / project fees for the changes, but rather to invest in the desired enhancements then charge a higher ongoing price for the enhanced system. Hybrid customization payments are also possible, combinations of customization fees and monthly costs. Be sure your customer understands that paying for a customization, does not grant ownership of the underlying system.

Intellectual Property

While an SAAS firm usually owns (or licenses) its software, customers should own their data (and have access to a copy of the raw data, if they ask for it). Hire a lawyer to work out the details.

Go to great lengths to keep customer data separate: you must make sure to never, even briefly or accidentally, give one customer access to another customer’s data. For small, cheap services, WHERE clauses are OK for this, but for large expensive services, use (at minimum) separate databases and server code instances, and perhaps even separate hardware.

I’m in for two sessions this year, assuming enough slots are available for both:

Flying Boxes

It’s surprisingly easy, with Java and Swing, to build animated drag-and-drop “direct manipulation” user interfaces. I covered the overall topic in a talk at the Java User Group, and found that my “flying boxes” demo and code walk-through were by far the most interesting part. I’ll repeat that demo and explanation here, with more careful (and thus helpful) coverage of the issues involved in getting good results. As “filthy rich” GUIs become more popular, the ability to build such interfaces has become important in commercial business applications, not only in demos and games. The code can be downloaded from my web site.

Selling your Software as a Hosted Service

For the last few years my (other) firm has been selling an application as an Application Service Provider, charging a monthly fee for use of software that we develop, host, and support. (This is sometimes called the “Salesforce.com” model, but it predates them by decades.) Of course we have much still to learn, but in this talk I’ll share some experiences, tips, and advice on how (and whether) to use this business model for your own ventures. The last portion of the session will be a roundtable discussion, I’d like to learn from you too.

Here are just a few that’s I’ve enjoyed recently, there are many more worth watching.

How Debian (Ubuntu) packages work

Seth Godin (marketing guru)

Mary Poppendieck (“Lean Software Development” author) – Competing on the basis of speed

A new Way to look at Networking – Fascinating

The Mercurial distributed source control system

Added later:

Fission is the New Fire

Jessica Livingston, talking about “Founders at Work”

Still later:

Subscribe to this feed to find out about each talk

There is an ongoing flow of incoming data in our online lives. Hundreds of emails per day. Hundreds of RSS feed items. Dozens of IM contacts. Phone calls. Voice mail. The “water cooler”, physical or virtual. The disconnection idea is simple: Go offline, physically and network-wise. Leave your office and go somewhere away from your normal environment, away from email, RSS, instant messaging, the web, etc. Reduce your inputs, to make room for more output.

My implementation is to go to restaurant or cafe, in the mid-morning or mid-afternoon (out of politeness, to avoid disrupting their business by using up a table during peak times); preferable one without “WiFi” to remove that temptation. Then I sit, sip, and Just Work on something important. I write code; I write text; I review documents; I brainstorm. I use my notebook PC with a 12” screen, a stark contrast to my 2560×1024 resolution desktop configuration. The latter is wonderful for many kinds of work; but it is also more distraction-prone.

If you find yourself struggling to task on large important tasks, instead distracted by a thousand smaller things, give disconnection a try.

If you work in software development and haven’t read Jerry’s books (The Secrets of Consulting, Becoming a Technical Leader, The Psychology of Computer Programming, etc.), I heartily recommend doing so.

Dave talked about 3 key areas where Rails should improve. The one I want to focus on is deployment. Rails has Capistrano, a slick tools for deployment automation. Capistrano is great, but it misses the boat in one key way: it is push-based. It assumes a world where the developer sets up, controls, and performs deployment to production servers. That is of course the case at the start of a small operation, but it doesn’t scale; in large organization, or even in small growing ones, sooner or later there is staff dedicated to production deployment and monitoring, separate from development.

One way, to me right way, to handle deployment is push / pull:

For the “push”, a developer uploads a new version to a storage site somewhere. It travels in the form of an archive file (ZIP, tgz, whatever) which contains all of the needed artifacts, as well as metadata about the required libraries, pre- and post-install steps, etc. for the new version. It has a unique name; it lands at a URL. Normal, off the shelf technology (FTP, web servers, etc.) can be used to serve and secure this storage, implement policies about who can upload new versions, etc. This upload happens with some simple one-line command (or as part of an auto-build); it does not actually put a new version in production, but only makes it available for pulling.

Then, on a production machine, someone with software installation rights on that machine (administrated by the normal tools – not by any special feature of the deployment mechanism) runs a command (something like “deploy staging http://ourserver/project1/project1-build-3453.tgz”) which downloads the new build, runs various sanity checks, deploys it to a staging area, and makes it available to try out. Once the staging is verified, a similar command brings it in to live production. These builds refer as needed to configuration data on the deployment machines (such as production DB access credentials); the build archives are generic, not specific to any particular production machine.

The main idea behind this is that each person has the rights they need for the work they need to do, and these rights don’t need any special help or support from the deployment mechanism. Developers don’t need any special rights on deployment machines, nor to deployers need any special rights on development machine

I wrote this in the context of a Rails / Ruby talk, but it’s at least as relevant in Java and Delphi world; in fact at Oasis Digital we need something like this on a Java project and a Delphi project right now.

]]> http://kylecordes.com/2006/deployment/feed 0