On Going Fast Because You're A Start-up

Today, for some reason, I was thinking about a start-up I worked on few years ago and how we could go really fast because (almost) no one used the darn thing.

When you're working on a small budget you need to get that code out into the wild as soon as possible so you can figure out if this idea of yours has any legs. So maybe you test a bit less then you would with a big application and you don't pair program that often and workflow is managed through IM and email and you take shortcuts because if you didn't the code would never see the light of day. That's the way it has to be and everyone accepts that.

However, there will come a reckoning -- and it's not fun from the owner's point of view.

The site's popular -- it's making some money but your development team is slowing down and asking for expensive things. They've brought on a new guy, but in addition to costing more money the team (which has now ballooned to two people!) is going slower for some reason. Things that used to take an hour take 1.5 -- and through the miracle of pair billing they cost 3 hours!

The team used to deploy to production whenever they felt like it, but because of some recent costly screw ups the devs are throwing around ideas like: staging servers, regression suites, a DBA review of the SQL queries, and refactoring of complex code. Expensive ideas.

Work flow used go like this: Entrepreneur gets idea >> He emails/IMs developer >> developer codes and deploys. Now the team wants you start using some weird IM like thing (say Campfire) and a project management tool (say Lighthouse). And they cost money!


All this really sucks. The money that's coming in just seems to get gobbled up by all these problems. And the thing the owner has a hard time seeing is that a long time ago everyone on the team made an assumption: This thing's not a freaking bank so we don't have to treat it like one.

A bank application has to work ALL the time and the cost of bugs can be EXPENSIVE. So there's very good reason to spend some money being cautious. What has happened to the entrepreneur is that his tiny app has become his bank. He's got years of time and tons of money invested in this website now. Failures 2 years ago didn't have near the importance they do today. All the technical debt accrued along the way needs to be payed down. Now, most of these costs are one time hits with a much smaller continuing maintenance fee and they save way more money then not doing them -- long term. But the transition from small to big has serious mental and physical hurdles to overcome. Mental in that everyone has to stop treating the app like it isn't a big deal if it goes down. Physical because it's going to need more people, servers, and products to keep it running. Those are some tough hurdles to jump.

Comments

Anonymous said…
The "experiment" should not be longer than 4-6 months and after that the enterpreneur should know if it's worthwhile. From the technical standpoint that should be also the time to plan based on the user feedback. The problem is that once lower quality is estabilished and there is a public release it's too late to educate the customer about the need for quality. So my suggestion is never trade quality for speed, it's a false speed impression. Yes the eneterpeneur will probably go finding someone else for a 4th of the price but we (the craftsmen) have the responsiblity to tell the customer what to expect. And this post is a good example. Thanks for sharing.
Fred Lee said…
Great observations. Thanks for sharing. I am currently working at a company that is experiencing exactly what you described . . . even down to the point of the application becoming a "bank". The application I work is quite literally a bank. As someone who is not one of the "original" coders, I think I see the application in a more objective manner. The "owners" can get emotional. I often hear things like, "This is how we used to do it." The problem is that "used to" is 4 years ago and 20 people less.

Popular posts from this blog

What's a Good Flog Score?

Point Inside a Polygon in Ruby

SICP Wasn’t Written for You