This post originated from an RSS feed registered with Ruby Buzz
by Jake Scruggs.
Original Post: On Going Fast Because You're A Start-up
Feed Title: Jake Scruggs
Feed URL: http://jakescruggs.blogspot.com/feeds/posts/default
Feed Description: Ruby, Rails, Metrics, Testing, and pursuit of clean code.
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.
Previous Topic
