Launch first, audit later

Some time ago my boss told me that two of his colleagues are building their top secret, Next-Big-Thing site in Rails. They asked him if we (the company) could audit their code. This struck me as a really strange thing to do, given they are nowhere near launching their site. I told my boss: “Sure, we can audit their code, but do they really want to waste their money on this right now?”

Don’t get me wrong, I do care about code quality more than most programmers. I’m all for automated unit testing, high test coverage, using code metrics, profiling, automating builds with continuous integration and so on. We practice most of these things here at Jarorcon. And I would be more than happy to examine someone’s code and point the problems in it (and get paid for it).

Cost-benefit analysis

But still, when you do these things (like maintaining 100% test coverage) you have to take both costs and benefits into account. You can’t get fanatic about it. If it’s easy and enjoyable for you, great. But if you spend several hours struggling to get that one last line of your code tested, you’re probably overdoing it. Ask yourself what is the cost of those hours of your work (in terms of your employer’s money or in terms of lost opportunities if working for yourself)? Is having 100% test coverage going to benefit you more that it costs?

The definition of success

How do you define the success of the site you’re building? Is it great code quality? Is it 100% test coverage? I think it’s rather having many users that like the site or, even better, having many paying users. Do you think your users will appreciate the perfect quality of your code? I hate to say it but most of them couldn’t care less about it, as long as your site works reasonably fast and is reasonably stable. And if you’re motivated and competent enough, you’re going to make it.

Launch first, worry later

Launch first. Worry later. Make your code work. Make sure somebody is going to use it. Check if people like your idea. See whether you can get profitable from it. Then worry about auditing the quality of your code, optimizing its performance, beautifying the design, adding more features and so on. Why waste money on audits if you know that most startups fail? This is the same as premature optimization. First make it work, then optimize (for performance or quality).

Of course, if you’re a beginner, there are many things that you could (or even should) do. Learn as much as you can. Read documentation, blogs, forums, books. Experiment. Ask for advice. Try to solve real problems (like: your site comes to a grinding halt with five concurrent users). Fix errors and bugs. Look for security vulnerabilities. Practice TDD or BDD if you feel like it. Set up continuous integration and measure test coverage if you care about it. But don’t overdo it. Don’t prematurely optimize for quality. Remember: your success will not depend on the quality of your code alone.

And just one thing: audit sounds very enterprisey. It’s extremely funny when a two-person startup asks for an audit.


One response to “Launch first, audit later

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: