Estimating software is hard, but most of us have to do it – whether we’re estimating an entire project for a client, or a new feature for a boss, or a change to one of our own projects.

I’ve found the following rule helpful when estimating software. This comes from about four years of estimating Rails projects to consulting clients, and moving from bad – dramatically underestimating fixed-bid projects – to pretty good – usually overestimating time & materials projects slightly. (And more importantly, knowing when I can’t estimate, because the scope is too vague or too large.)

Jon’s Law of Estimates

Software difficulty is primarily determined by volume, logic, and integration.

Jon’s Law of Estimates, explained

1. Volume is easy to understand. If you’re building software that does more, it will require more work. So if you’re estimating a project that stores recipes, and you’re estimating another project that stores recipes AND shopping lists, you can expect that the second one will take more work (if everything else is equal).

2. Logic refers to the rules or business logic behind a feature. The more rules there are, the more work there is. Imagine that our recipe system requires that recipes from some users are manually approved by an administrator, and checks to see that each ingredient in the recipe is present in the step-by-step instructions, and only allows a user to post 3 recipes per hour, and lets users propose alternative versions of a recipe, and lets an alternative version replace the regular version if it achieves a certain rating, etc. That’s more work than a recipe system that just lets users create and rate recipes, even though the volume of features may not be any larger.

Interestingly, a technology can make some logic trivial and some logic hard. Nested forms are a great example of this. Before Rails 2.3, Rails made it trivial to do CRUD on a single table at a time, but difficult handle multiple tables. Now it is (almost) trivial to do CRUD on multiple tables at a time.

3. Integration points are usually deserving of special consideration in an estimate. This includes talking to a web services API, another local software system, a data feed, a complex library, etc. Not only do integration points often take time to get right, but they can become sinkholes of time when the documentation is inadequate or incorrect, the other system doesn’t play nice, or you can’t easily test the integration. And your estimate depends on something out of your control: the other system.

External factors

These rules only apply to the difficulty of the software. Several external factors are important as well. These include, most notably, the client and the team. The client can make a project easy, or they can make a project difficult. Similarly, the right team might be able to blaze through a project quickly, while the wrong team may never finish at all.

The other side of estimating

Here’s the thing about these rules: they’re relative, not absolute. There is no rule that says “Features take 5 days, and integration points take 10”. So estimating requires comparisons. This means that if you’ve never built a Rails app before, you’ll have trouble estimating a Rails project. But once you’ve built a few, you can compare the volume, logic, and integration points of a new project to volume, logic, and integration points of the previous ones.

So estimating requires intuition and experience as well as analysis (e.g. Jon’s Law of Estimates). The key to estimating is to combine analysis and intuition, and to let each side refine the other.

I’ve used just about every defect tracking system there is. That includes Trac, Fogbugz, Lighthouse, a Rails-based Trac clone that I forget the name of, spreadsheets, note cards, and even Bugzilla. I haven’t tried Mingle, and I only used Jira for a few days, but I’ve got most of the other bases covered. Last year at Tumblon, we settled on Fogbugz as less painful than the other options. It’s a pretty good defect tracking system, with most of the right features, and it’s reasonably easy to use.

A month ago, I tried Pivotal Tracker for a new project. It blew everything else away.

I think there are two reasons for this.

First, it’s a story tracker, not a defect tracker. And when I’m building software, I need to track stories more than defects. Of course, Pivotal Tracker handles both, and so do most bug trackers. But bug trackers usually seem natural when I’m using them to track bugs, and unnatural when I’m trying to map out new development. Pivotal Tracker feels natural for both.

Second, it prevents sabotage. This is the real key. Software development projects are hard to get right. It’s really easy to unintentionally sabotage a software development project, and everyone on the team can do it. That’s why there’s a huge publishing and training industry around project management, and why most of us are interested in the software development process. (Things like Agile, XP, and Scrum) are probably interesting to you and I, while CMM and CMMI are interesting to other people.)

Basically, Pivotal Tracker enforces a lightweight agile process, and makes this painless. If you use Tracker properly, you’ll write relatively atomic stories, estimate their difficulty, prioritize them, step each one through a simple workflow from new to accept/reject, track weekly or bi-weekly iterations, and see where you’ve come from and where you’re going. You can do this with most bug trackers, but most of them are missing one important thing.

Constrained velocity.

Pivotal Tracker requires that every feature get an estimate on a simple scale – 0-3 is the default. These are relative velocity points, not hours, and they give you an idea of how much you can accomplish in an iteration. After your first iteration, Tracker uses the average velocity of the previous few weeks as the predictor of your velocity for the current iteration. So if you did 17, 15, and 20 points over the last three weeks, Tracker thinks you can do 17 points next week. Chances are, this is a decent guess.

The Current Iteration and the Backlog are a continuous list in Tracker, and the line between them is based on velocity. If you only have 12 points of work on an iteration, you can’t add stories to the next iteration – you still have capacity on the current iteration, so the stories will show up there. If you have 17 points scheduled for this week, and you try to add 2 more, something has to give. And this is the key.

By managing velocity in this way:

• The product owner can’t shove an extra 5 points of work on an iteration just because he wants it to get done, at least not without recognizing that it will take more resources (i.e. more programmers).

• The product owner can’t make every new feature the top priority just because it is new, at least without clearly seeing that other features will be delayed.

• Developers are forced to estimate everything. You can’t start/finish/deliver a story until it has been estimated first. As long as estimates are optional, they won’t be done consistently.

• Everyone has a decent idea of how much can be done over time. The velocity estimates aren’t perfect, of course, and that’s just fine. They don’t have to be perfect – they just have to be Good Enough. (For what it’s worth, our velocity over the last 4 weeks was 20, 15, 16, 17 – good enough that we can expect to do around 15-20 points/week.)

There are also some smart touches. For example, you can set the team strength for a given iteration – if half your team is going to be pulled off onto another project next week, or out of town at a conference, set the iteration strength to 50%. Tracker will halve the expected velocity. Or if you have another developer you can pull onto the project, increase the strength to 125%.

Of course, Tracker isn’t perfect. It isn’t particularly client (Product Owner) friendly; I’d love to see a dumbed-down interface that is less intimidating to non-technical clients, but still has all of the features that they need (prioritization, Accept/Reject). And I’m not exactly sure where the QA role fits into the process – there is no “Verified by QA” state, so QA either needs to usurp the Accept/Reject role, or needs to be responsible for Delivery (deployment).

I’m also not sure how well it will work on large/long projects. After 4 weeks of work, we’ve added a total of 250 stories to the system, and 100 are still active (unfinished). It’s working fine now. But if we had 6 months of work mapped out in the Icebox, it might be a little hard to find things.

But Pivotal is actively working on improving Tracker, and even if they weren’t, it’s already better than most bug trackers.

Most companies see competition as a threat. If someone’s products could substitute for mine, they’re a competitor; and if a potential customer chooses another product instead of mine, that’s a bad thing.

Lightweight startups take this even further. If you see a need, but another startup has already started addressing the need, then you came at it too late. You’re lightweight, and so your only real advantage is speed. But someone beat you to market. Makes sense, right?

Except it doesn’t work that way.

Going it alone

The typical, but wrong, paradigm goes like this:

• Competition is bad

• Competitors are enemies

• Fewer competitors are better than more competitors

• An opportunity addressed by a few people already is “taken”

• An opportunity with zero competitors looks attractive

There is some truth to these things. Growing in the web search market today is pretty difficult. So is the operating system industry. So are dozens of other industries, and in these spaces, competitors may be be enemies.

But these are mature, settled industries. If you want to create a new search engine, or a new operating system, more power to you – but Google and Microsoft ARE going to be threats. Of course, most startups don’t try to dislodge Microsoft. If you’re working in an emerging market, on a disruptive or innovative technology, you might want to consider a different approach to competition.

Running in packs

This alternative model was described by Andrew Van de Ven of the University of Minnesota in an article called Running in Packs Versus Going It Alone. Andrew and his team found that in emerging, information-based technologies, competition often does not occur between individual startups, but between groups of startups. So as an alternative to trying to go it alone, startups may be better off running in packs: coordinating their efforts by simultaneously cooperating and competing.

This means that when a disruptive technology appears on the scene, its success is dependent upon the whole field of companies working on the technology, not on a single company.

So startups who run in packs should seek the growth of the entire market, in addition to trying to grow their own market share. Better to have a good slice of a growing market, than total domination of a dead market.

Actors seek both to maximize their total surplus and their respective shares in the surplus. ... This draws actors together and drives them to cooperate because no one actor has sufficient resources, competence, or legitimacy to do it alone.

Running in packs works for at least two reasons. First, competitors may help speed adoption of the emerging technology. Second, strong competition may improve and sharpen the quality of the technology.

This also means that politics is important when running in packs, as startups both compete and coordinate.

Actors with political savvy – an ability to recognize the interests of key actors and enroll them to one’s viewpoint – will be more successful in effecting institutional change and realizing their goals than actors without political savvy.

Van de Ven also found that the (disputed) first-mover advantage only really materializes with technologies with strong IP protection, and which can’t easily be reverse engineered, imitated, or substituted. Most web startups these days fall squarely in the “easily imitated” category – including giants like Facebook, Digg, Flickr, and Twitter. And even with a head start and strong patents, first movers may be better off seeking a pack to run with rather than going alone.

Of course, the advantage of running in packs probably only works up to a point. Settled, mature, and (worse) shrinking industries are far more competitive than emerging industries. This means that they’ll have a harder time working together to grow the whole industry, that adoption is less of a problem, and that technological improvement is slower.

This perhaps is why population ecology studies have found that having more competitors in a new organizational niche increases the survival probability of its members until a threshold level is reached where resource scarcity limits the growth of all members of a population.

A retail example

For a low-tech example of running in packs, look at clothing retailers. If going it alone worked in the retail industry, stores wouldn’t pay huge sums for space at the Mall of America – they would avoid it like the plague. After all, clothing stores are highly competitive – one can be substituted for another quite easily, and innovation happens slowly, with the basics (pants, shirts, socks) having been around for quite some time. So you would think that these stores would want to destroy their nearby competitors and be the only place to buy clothes for miles.

But in reality, the opposite is true. Retailers like to locate near other retailers, because going it alone as a retailer apparently doesn’t work very well. When someone needs a new pair of pants, their first thought is to go to a place where lots of people are selling pants. A shopping mall acts as a center of gravity to pull in buyers, and a lone clothing store without competition gets forgotten. So the stores simultaneously coordinate (bringing in lots of buyers to a single area) and compete with each other (for individual buyers). And as a pack, they compete with other packs of stores.

Consulting and Rails

Running in packs works for some location-based businesses, and it often works in emerging industries (the internet, mobile devices, etc.). But it also works with non-commercial technologies, like programming languages.

I’m a co-founder of Slantwise Design, a Ruby on Rails consulting shop. We mostly build web applications for startups. And while there are lots of companies trying to build web applications for startups, a majority of the time, our clients didn’t solicit bids from other competing shops. And as far as I’m aware, after 30+ projects and twice as many proposals, we’ve only competed directly with other Ruby on Rails shops twice.

(There are a few reasons for this, and I won’t go into them in much detail. The most important one is that by the time we give a proposal to a client, they’ve already made up their minds. They don’t want to decide between 10 consulting firms; they’re trying to confirm that we’ll do a good job.)

Ruby on Rails is still a growing technology, and adoption is still increasing. If you want to provide Rails consulting services, there is far more room to grow by taking business from Java or PHP shops than by taking business from other Rails shops. And the technology is still improving, so the growth of the Rails industry is fueled by knowledge sharing between Rails shops. Hence, not only is competition rare between Rails shops, but competitors should be seen as friends, not enemies.

So running in packs works for both Rails consulting firms, and for the proliferation of the Ruby on Rails technology itself.

What about you?

Every startup is different. But a lot of us need to start running in packs. Which model is best for your startup: running in packs or going it alone?

	Run in packs	Go it alone
Market size	Lots of growth potential	Level or shrinking
Degree of innovation	High – you spend time educating your customers	Low – everyone already understands
IP protection	Low – your startup could be imitated or substituted	High – given time and money, someone could do what you’re doing
Industry concentration	There is room for lots of companies to profit	The industry will only support 1-2 companies

And of course, this leads into a second question: which sort of industry would you like to be a part of?

---

Further reading

This post is based on “Running in packs to develop knowledge-intensive technologies,” by Andrew Van de Ven. MIS Quarterly, June 1, 2005. You can buy this article at Amazon as a downloadable PDF for $3.95

For other thoughts on startups in emerging markets, check out Steve Blank’s Four Steps to the Epiphany.

Luke and I have been working on Tumblon for quite a while now, along with Graham Scharf. We’ve built a prototype, raised investment, partnered with content sources, changed requirements (unfortunately), and worked with Livefront to get a fantastic design.

We deployed the new design, along with dozens of other changes, on Friday, and we’re gearing up for launch. In the meantime, the site is free and open, so take a look at http://tumblon.com.

So what is Tumblon, and why does it exist? More than 90% of a person’s brain growth occurs between birth and age 5. Neural connections made during this time are exceedingly important. And parents are best poised to help a child develop during this time.

Enter Tumblon. Tumblon provides an interactive snapshot of a child’s development, to help parents understand and nurture their child’s growth. Sign up for Tumblon, and within 5 minutes you can learn where your child is developmentally, what’s coming next, and what you can do to help.

Tumblon also lets parents record memories, photos, and stories, and lets them share this with family and friends via a private blog. For an example, take a look at my Tumblon blog.

Finally, we have great public content, from resources for parents to featured blogs, including one by Gladys Hunt, author of the classic book Honey for a Child’s Heart.

Many more changes are coming, from new content to new features to better usability. But if you’re a parent of a young child, take a look and let us know what you think!

Slantwise Design is hiring one Ruby on Rails Dark Lord of the Sith. Candidate will lead Rails projects in a fast-paced, show-no-mercy environment. Our ideal applicant will have 1-3 years of Rails experience, a strong programming background, and be open to the power of the dark side.

Desired skills:

• Ruby on Rails
• Ruby programming (non-Rails)
• Web deployment experience (Linux/Unix, mongrel, etc.)
• Java background a plus (and JRuby experience great), but not necessary
• The force, esp. mind trick
• Database knowledge (i.e. deeper than just ActiveRecord)

You will also be responsible for enforcing order within our projects. We practice rigorous waterfall project management, with heavy emphasis on meetings and documentation, so experience with the FAHS system (Fear -> Anger -> Hate -> Suffering) a plus.

We currently have two Rails Sith Lords on staff but are interested in bringing in some fresh talent. To apply, please send your resume to darklord@slantwisedesign.com and vanquish one of our current developers in single combat.

Edit: Happy April 1

Sadly, we aren’t actually hiring Rails developers at the moment, but special thanks to Darth Rubious, who put Eric in the hospital.

Over the last nine months, Slantwise has been busy with three of its own projects (in addition to our client work). FanChatter is a mobile sports chat hub, where you can talk sports via mobile phone, email, or web. Zencoder is a distributed video transcoding system. This spring, we’ll be launching our third product: Tumblon.

Tumblon is a website that allows parents to track their children’s growth, and share this with friends and family via a online blog/baby book. To do this, we’ve partnered with respected pediatricians, developmental psychologists, and authors to get clinically-tested information about child development.

Want to hear more when Tumblon launches? Want to beta test the site? Sign up with your email address, and we’ll keep you posted.

So, what does Tumblon do?

Learn about your child’s development

Add your children to Tumblon, and based on your child’s birthdate, Tumblon gives you developmental information geared directly to your child’s age. You can dig in for more info, record milestones as they happen, and discuss your children’s development with other parents.

Journal about about your kids

Write stories about specific developmental milestones, about parenting in general, or about anything you want. You can choose to keep your stories private, let your friends and family see them at your Tumblon blog, or publish them so anyone can see them.

Photos (of course)

Not surprisingly, you can upload photos to Tumblon.

Sharing – the most important part?

Finally, Tumblon makes it easy to invite friends, family, and well-wishers to stay informed of your children’s growth through email updates, a public blog, etc. If you’re a new parent, you know what this means: keeping the grandparents happy. :)

So, when can I try it?

Soon. We’re closing in on our beta site, and will be up and running for real this spring or summer. If you want to take a look for yourself, sign up for early access at http://tumblon.com.

It’s been 2 months since I’ve posted about Zencoder. You may be glad to know that the project is still alive and is nearing completion. It has moved a little slower than we initially expected (we had hoped to finish in Nov/Dec), but the end is in sight. So if you are interested in a complete video transcoding solution for your web application, request more info at zencoder.com. And if you’ve inquired in the past, and you are interested in a demo, let us know: we’re starting our online demos this week.

But on to the sneak peak.

Scaling

Zencoder scales both horizontally and vertically to a nearly arbitrary limit. You can scale vertically (obviously) by increasing the speed of your machines: the faster the CPUs, the faster the transcoding, and any Linux or OS X machine should work. And you can scale horizontally by increasing your number of servers, as high as your licensing allows.

You can scale the same way on EC2, by moving from small instances to large instances, or by increasing your number of instances.

What’s important is that Zencoder works the same whether you run it with 2 servers or with 200 (or more). The system will happily distribute your jobs across however many servers you have. (Note that it will do this by distributing each job to a different server, not one job across many servers – the latter approach can finish each individual job more quickly, but the Zencoder approach should have a somewhat higher overall throughput, since it is a bit more efficient. And it is significantly simpler, of course.)

This means that Zencoder can grow with your application. If you underestimate your traffic, or your site grows exponentially, just add another server or fire up a new EC2 instance.

Finally, you don’t even need to restart Zencoder to add additional servers, so expansion is almost completely seamless. If you’re running on dedicated hardware, just configure Zencoder on a new server and start it up: it will begin working immediately. On EC2, things are even easier: click the big green “Launch new worker” button, and you’ll have a new server up and running in about 3 minutes.

Reliability

On the reliability front, Zencoder is built with three goals in mind.

First, errors should be few and far between. This goal is obvious, and is shared with most software (except for some software coming out of Redmond, WA). And Zencoder is a reliable system in this respect. The code is reasonably compact, and it is well tested (both by unit tests and by humans).

Second, if any (or all) pieces become unavailable, your website should continue to work. In other words, if a user uploads a video at your site, and Zencoder is unavailable for some reason, your website should continue functioning as-is. Similarly, if your site is down, and Zencoder finishes a job, your website should receive the job as soon as it comes back up. As a result, we have designed the system such that you can pull the plug on any piece – or multiple pieces – and as soon as everything is back online, the system picks up right where it left off.

Third, no job should ever get lost in the system. This is accomplished through integrity checks – between the queue and each transcoding node, and between the Zencoder system and your application. You can even wipe the Zencoder queue, and if your application is still waiting on any jobs, they will be automatically recreated.

The result is that Zencoder is almost a self-healing system. It isn’t perfect (yet), but it is robust, reliable, and scalable.

MinneDemo is a quarterly event in the Twin Cities where local startups and technologists demo their products.

Zencoder is distributed video transcoding software, built by Slantwise, that is scalable, reliable, and flexible.

The next MinneDemo event will be held December 6th at O’Gara’s Garage in St. Paul, and I’ll be presenting Zencoder there. This will be the first public showing of Zencoder, and I’m excited to be demoing the system after four months of development.

Whether or not you’re interested in video processing, if you’re reading this blog and you live within a 100 mile radius (or even 270), you should come. MinneDemo and MinneBar are the most worthwhile tech events going on in Minnesota.

MinneDemo works like this.

• Show up at 6:30 for a free beer/wine/soda or two.

• Meet interesting people: developers, designers, venture capitalists, tech lawyers, startup gurus, information architects, enterprise software providers, ISPs, and more. About 300 people typically show up.

• Have another beer/wine/soda.

• Watch five or six software demos, including Zencoder. The demos each last 15 minutes or less, and PowerPoint is not allowed, so you actually see working software, not marketing-speak.

• Continue to meet people, get ideas, land projects, and find partners. We met our attorneys, one business partner, two clients, and several friends at MinneDemo and MinneBar.

The event starts at 6:30pm on Thursday, December 6th (drinks and food), and the demos will start at 7:30pm. The demos will finish around 9pm, but some people will stick around for hours after that.

Many thanks to Dan Grigsby and our own Luke Francl for organizing MinneDemo, and Ben Edwards for starting MinneBar!

So how does Zencoder do its video transcoding? What codecs and formats does it support? And what about the critical issue of codec licensing?

Licensing

Let’s start with the question of licensing. Codecs are licensed in three main ways.

1. Commercial software (On2, Nellymoser)
2. Patents and standards requiring licenses (MPEG-2, AAC, MP3)
3. Free or unenforced formats and codecs (Ogg, Matroska, AVI)

If you’re going to transcode and distribute video, category 3 is easy. Category 1 is straightforward, and these commercial codecs work just fine with Zencoder.

Category 2 poses the real problem. In my estimation, three of the most important video codecs – MPEG-4, H.264, and MPEG-2 – and three of the most important audio codecs – AAC, MP3, and AMR – all require licensing direct from their patent holders and/or licensing authorities. Those six invaluable codecs are represented by four separate licensing bodies (representing hundreds of patent holders), each of which has separate terms, prices, minimum fees, etc. And when you move to the second tier of codecs, things get even more complicated.

Zencoder takes care of this for you. With Zencoder, you receive licenses to these and other critical codecs. We’re still working out the specifics, but when Zencoder launches, we plan on including licenses to 10-20 patented codecs and formats, covering all of the major ones and several in the second or third tier.

Compatibility

Zencoder can handle every major video codec, audio codec, and container format. And we do this legally, taking care of most licensing issues for you.

Here is a partial list of formats and codecs that we support.

• H.264
• FLV
• MP4
• 3GP
• VP6 (with commercial license)
• MP3
• AAC
• MPEG-4 Video, XviD
• MPEG-2
• AVI
• Ogg, Theora, Vorbis
• Nellymoser (with commercial license)
• And 100+ more

The goal is to decode everything that you can throw at Zencoder, and to encode everything that you have a good reason to encode.

Slantwise has been working on a video processing product called Zencoder for the last several months. Zencoder is a distributed multimedia processing system, written in Ruby, that is powerful, flexible, and scalable. It also integrates easily with any application that needs video transcoding. The product itself is in its final stages of testing, and will launch soon, so head over to http://zencoder.tv and fill out the contact form if you want more info.

In this first “sneak peek” post, we’ll look at Zencoder from a high level. Where does it run? How does it integrate with your application?

Two Hosting Options

Zencoder is a server, or collection of servers, that you host. The first server is the “mind” of Zencoder, which queues jobs and handles all communication with your application. The other servers are “workers” that do the actual video transcoding.

You can host Zencoder on your dedicated hardware or on Amazon EC2. Both work equally well, but we think that the EC2 approach is especially interesting, and Zencoder does some cool things with EC2. (More on that in a few weeks.) But you can mix-and-match EC2 instances and dedicated servers, so you don’t have to choose. You could use dedicated hardware for most of the transcoding work, and use EC2 for overflow work. Or use EC2 for most of your work, but one ultra-fast dedicated machine for high-priority jobs.

Easy Integration

Zencoder integrates via REST web services, so it is completely technology-agnostic. Your application can be written in Java, Ruby, PHP, .NET, Python, Erlang, Ada, or Assembly, as long as it can communicate via HTTP. It can be a web application, server software, or anything else that can send and receive HTTP requests.

To submit a job to Zencoder, you just need to send a POST request to your Zencoder server with the basic details of the job: input file, job id, and task/recipe. Zencoder will then do its work and send a request back to your application with the results of the job: status, output file attributes, output file location.

So your application only needs to do two things to integrate with Zencoder:

• Send a HTTP request to your Zencoder server when you want to trigger a new transcoding job
• Handle a HTTP request from Zencoder with the results of a job

We also provide a Ruby on Rails plugin that handles these things for you; so if you’re running Rails, this work is done for you. You just have to install the plugin and configure a few things, and your application is ready to go. Eventually, we plan on providing similar integration classes for Java and PHP. But even if you aren’t using one of these technologies, the integration work is pretty simple on your end, and we’ll help you through it.

A week and a half ago we tested FanChatter at the Metrodome during the Gopher-Bison game.

The response was really great and so we’re going to be back at this Saturday’s Gophers game against the Illini as well as at the Vikings game on Sunday. So if you’re going to either of those games, look for our promos and send in photos from your phone to get up on the big screen!

One of the cool things about working on FanChatter is getting to see behind the scenes at a major sports stadium. Here Marty shows off his phone down on the field.

Slantwise is proud to annouce the launch of FanChatter.com: the first fully mobile sports chat network. FanChatter is a micro-blogging site targeted at sports fans.

FanChatter allows sports fans to create groups and chat on the web or via their mobile phones. Fans can also use their camera phone to send in photos. If you like to talk about sports, give it a try.

On Saturday, October 20, FanChatter will be on the big screen at the University of Minnesota-NDSU football game. So if you’re there (or following along at home), send your photos to gophers@fanchatter.com (or ndsu@fanchatter.com). We’ll pick the best photos from fans to put up on the big screen!

FanChatter is a partnership between Slantwise and Marty Wetherall, producer of The Show To Be Named Later. Marty and Jon met at the second MinneBar back in April, and the site is a product of that meeting. Completing the circle, it was officially be launched at last week’s MinneDemo.

Like what you see? Need mobile development? Contact us.

Guy Kawasaki has a new article called How to Get a Job on Craigslist. He recently posted a job listing there and got 37 good candidates. This is a great reminder of the power of Craigslist.

At Slantwise, we’ve hired four full-time employees in the last few years, and we found two of those on Craigslist. We’ve also worked with about 6 key contractors over the last three years four of those came through Craigslist.

Guy lists a few job application tips in his article. Here are my tips.

1. Build trust. Since any job hiring is based on limited information – a few conversations, not months of actual work – we’re going to hire the person we trust the most. This is a matter of skill (do we trust that you know what you’re doing, and that you can excel in your role?) and personality (do we trust that you’ll work hard, take your job seriously, and work well with others?).

2. Be specific. “Good communicator” doesn’t mean a thing to me. Everyone says that. “Spoke at three conferences” or “blogged weekly for two years” is meaningful. The same goes for project/development skills. Let us know what projects you’ve worked on and what your role has been. Go deeper if possible – “Built a SOAP adapter for (foo)” is better than “experience with web services.”

3. Avoid jargon. If your email looks like it was taken from a “how to write a cover letter” book, or some sort of Dilbert job-application-generator, I won’t take you as seriously as someone else. The right job application will sound professional, but professional in a one-developer-to-another way. If you were out for a drink with a peer from another company, how would you explain what you do?

4. Apply for the right job. Don’t copy-and-paste. Explain why you’d be good for this job, not just any designer/developer/manager job. When I’ve posted to Craigslist, I’ve typically gotten about one generic job inquiry for every personal one, and not surprisingly, the generic ones don’t get much of my time.

5. Worry about the email, not the resume. Sure, send me your resume too, but it doesn’t matter that much. A good email (what used to be the cover letter) should tell me everything I want to know. Namely: what relevant skills do you have? Where have you used them? Have you worked on any open-source or hobby projects? What do you do to further your skills, apart from work? And what do you do in your spare time? It will also set the tone for your application.

6. That said, don’t worry about your application too much. We are not going to hire someone based on the quality and composition of their cover letter or resume, or based on how smoothly a phone interview goes. We’re going to hire someone because of their skills and personality. If don’t interview very well, but you’re a kick-ass developer, guess which part is more important to us?

Next time we need to hire someone, I’m going to use two resources: Craigslist and the local developer community (RUM and MinneBar, mostly). Whether you’re looking to hire, or looking for a job, I highly recommend using these two tools.

During the dot-com era, a new set of heros were discovered: startups. Rejecting the suit-and-tie of their former lives, brave men and women wore jeans and baseball caps to work and demanded comfortable chairs. They shed the shackles of their soul-stifling 9-5 jobs in Corporate America and worked long hours for smaller companies. Fortunes were made and lost in a matter of weeks. Porsche Boxters littered the California highway, the People’s Car of this revolution.

The story ended in tragedy, but we were all taken on a wild ride, and we enjoyed it. We are chastened now; investment money is harder to come by, and companies are often forced to figure out their product before they figure out their IPO. And yet the idol of the startup founder remains with us, working long hours in jeans and sneakers, drinking too much coffee, negotiating eight-figure venture funding deals. Dreaming of a 12-month concept-to-funding-to-sale cycle (or is it funding-to-concept-to-sale)?

This idol is back, in an upgraded 2.0 form. The names have changed (Digg instead of Lycos); they are often smaller and more frugal; and many of them will succeed.

But the idol needs to be dispelled.

Meebo is a startup in Silicon Valley that provides an in-browser, cross-protocol IM program. Think iChat or Trillian in a browser.

Business Week recently published an article on Meebo. It’s a typical dot-com profile. Meebo has 10 engineers, 7 business types, and is hiring. Their product is fairly complex and cool, with an Ajax front-end, a C++ backend, and a made-up name. Its developers work 14- to 16-hour days to keep the site running and to add new features like Meebo Rooms (kind of like chat rooms, but with 100% more Meebo). The environment is fun and informal, with ethnic take-out, games, toys, inside jokes, and Simpsons posters. Meebo also has serious VC funding from Sequoia Capital and Draper Fisher Jurvetson.

This makes for an exciting Business Week article: our eHeros are back! But two things give me pause.

First, 15 hour days are not a good thing. Long days at a startup sound sexy, like Aeron chairs and razor scooters. There are plenty of people out there that those kind of hours are ubiquitous for tech startups, like a company can’t succeed on 40-hour weeks. But death marches typically end with, um, death. Those hours can ruin a company and its employees. And more importantly, working long hours isn’t good for software. Software development is hard, and 40 good hours are better than 80 tired hours. I know developers who have burned out, gotten physically sick, and divorced because of this kind of thing. It isn’t healthy, sustainable, or profitable.

Second, Meebo won’t be a success unless it sells for $500 million, according to Business Week, and that just isn’t a good business plan. Paul Graham explains this well:

Venture investors like companies that could go public. That’s where the big returns are. They know the odds of any individual startup going public are small, but they want to invest in those that at least have a chance of going public.

Currently the way VCs seem to operate is to invest in a bunch of companies, most of which fail, and one of which is Google. Those few big wins compensate for losses on their other investments. What this means is that most VCs will only invest in you if you’re a potential Google. They don’t care about companies that are a safe bet to be acquired for $20 million. There needs to be a chance, however small, of the company becoming really big.

In other words, if VCs put $10m into Meebo in exchange for 40% of the company, then they’ve valued the company at $25m ($10m / .4 = $25m). So if they want a 20x return, then Meebo isn’t worth selling for less than $500m ($25m * 20 = $500m). In practice, they might be interested in cashing out at $100m if things look “bad” (for a 4x return), but they certainly wouldn’t want to sell for $20m, since that would actually represent a loss.

Maybe Business Week is exaggerating – I hope they are. I have no inside information on Meebo, and so maybe Business Week (or I) have the details wrong. But really, how many web startups sell for half a billion dollars? Maybe one a year? Off the top of my head, we’ve got MySpace, YouTube, and Skype (if Skype counts) over the last few years. Does Meebo provide anything as wide-reaching or revolutionary as these?

Venture capital may be great for biotech, aerospace, semiconductors, &c. But $10m isn’t needed for most web startups. There is another approach to startups, which understands the inefficiencies of large teams and the value of constraints. Throwing $200,000 at a programming problem often produces better results than throwing $2,000,000 at it. Not always, but often. If you have enough money to bootstrap a small team (3-5 developers) for a year, and if you (ahem) have a revenue model, you’ve got what it takes to build a business. You probably don’t need venture money.

And really, who wants to start a web business that isn’t a success at $30m?

The Rails contract labor market has gone through four phases thus far:

Phase One – Boutique Shops

During the first phase, boutique web-development shops used Rails to win “competitive bid” contracts over other firms by over-delivering on features at the same bid-price as the alternatives.

Typically these contracts were “soup to nuts” (or, in MBA speak, vertically integrated) projects involving design and development for companies whose web-presence was to supplement/support an existing business. The customers didn’t much care about platform, had light-to-non-existent integration needs, and certainly didn’t ask for Rails by name.

Hourly/project rates were upper-middle-class, solid and defensible thanks to over-delivering on features. Ultimately most companies have a project budget, not an hourly target rate, so moving deeper into the nice-to-have features for the same dollar cut back on the cheaper cheeper squabbling.

Phase Two – Late-to-Market Web2/Social Networks

The second phase of the Rails contract labor market arrived with the late-to-market Web2 sites and social networks.

Backed by investors, but often without their own development teams, these companies selected Rails based on the visible success of Rails during phase-1. Hoping to get into the market quickly/catch-up, these companies offered premium rates to contract devs.

Premium rates attracted (1) “gunslinger” contract coders and (2) traditional brand/interactive agencies to Rails. This forced the boutique shops to professionalize or lose business to the (1) more experienced coders or (2) better pitchmen.

Phase Three – Influx Of Cheap Labor

My hypothesis is that the rate for undifferentiated Rails labor probably peaked six to nine months ago – marking the entrance to the third phase – and has been on a downward slide since then.

The word “undifferentiated” in that last statement is important. For developers, Rails is a double edged sword. Rails extends capabilities that would previously have been inaccessible to designers and junior programmers. These folks are, quite rationally, drawn into the market by the money attached to Rails, bringing the supply up and forcing the price down. This manifest itself most obviously when heavy-hitter developers started failing to renew their contracts based on price pressure. After launch, these sites turned to lower-end labor.

Initially, I wrote the preceding paragraph with a “market confusion” angle, citing proposals for the same project that varied by as much as 300% for the same hourly labor. Ultimately, though, I decided that that I was confused. There’s a back-side to the “get what you pay for” argument that I’d intended to propose. Sometimes good-enough is, well, good-enough.

At drinks after Ruby.mn meetings, we kid about an “acts_as_social_network” plug-in. In a way, junior developer/designer-turned-developer labor /becomes/ the acts_as_social_network plugin. There are tagging plug-ins, comment plug-ins, photo-upload plug-ins, etc. Most of the standard components of social applications are trivial in Rails; a room full of senior contract developers is an expensive way to lash those together.

Phase Four – Mainstream

Undifferentiated labor isn’t normally filled by contract labor. Rails is becoming mainstream, as evidenced by the giant turnout for RailsConf. Combined, these two explain the shift from project-work to full-time positions (including, perhaps, long-term full-time equivalent contracts) that appears to be underway on the job/project boards.

Combatting Downward Price Pressure

As contract developers, we’re entering a market where reputation and specialization have significance in combatting downward price pressure. I’m going to illustrate this point with two companies and two people who’ve been in – and adapted to – the changing Rails contract labor market from the beginning.

Unspace Interactive is Toronto’s premier Rails shop. Launched during the boutique era, Unspace developed an early reputation for productivity and speed-to-market.

Traditionally, developers in a corporate or start-up setting work on a single product/project over the course of many months. At Unspace, they’d turn over project every couple of months. Getting to work on a series of projects, each from the start, compressed into a short period produced a useful side-effect for the Unspace guys: they recognized places in the Rail development process that were un-DRY: they found they were repeating themselves in views, stylesheets and controllers. The widely discussed HAML and SASS projects, and new-to-the-scene make_resourceful project were developed to make these parts of Rails more DRY. Open-sourcing these projects and actively evangelizing them at the worldwide Rails conference circuit cemented Unspace’s reputation.

Slantwise Design, also founded during the boutique era, is developing a reputation as the goto guys for multi-media based Rails apps. Keeping pace with the changing market, the Slantwise team was hired by a late-to-market video startup to build a large scale video transcoding system with a Rails interface. This experience, and the exposure generated by their accompanying RailsConf presentation, has kept them in work and above the rabble of low-rate Rails monkeys.

McClain Looney is a great example of specialized Rails labor. He is the “Rails deployment guy.” When anyone in the Minneapolis/St. Paul area, and increasingly anyone nationwide, wants to go from development to production McClain’s the guy you call. From building a scaleable production environment to database redundancy to optimization, McClain has a set of skills that are rare amongst Rails developers. The concept of a performance/ops engineer isn’t new, but one who works within the Rails framework is. This skill set is high-value, but the work has to be spread over a larger number of clients because projects tend to be episodic and not very long term.

Bruno Bornsztein is the final example of a person adjusting to the changing Rails labor market. Bruno became an expert at building social web applications as a contract coder on a late to market MySpace competitor. Recognizing an opportunity for a specialized social network for home-decorating enthusiasts, Bruno launched Curbly. This is a case of specialization with a twist: his work product becomes an annuity, paying with ad revenue instead of an hourly rate.

Your Input

My observations on the Rails labor market are drawn from examples I’ve seen first hand in Minneapolis, Toronto and San Francisco.

I’d welcome a broader view: has the market played out this way where you work/live? Have some other comment, observation or hypothesis? Add it below in the comments. We’ll all benefit from recognizing changes in the market and positioning ourselves accordingly.

Like this this article? Give it a programming.reddit.com bump:

Thanks!