Inexperienced developers have one big advantage: they haven’t been programmed to work for perfection and they’re not afriad to make mistakes.
–Neil Callanan, Founder of FitFeud
Start-up success depends on rapidly figuring out what customers will actually buy, a process that often requires quickly hacking solutions and other bad software practices for the enterprise. Unfortunately most of us get our tech skills from the enterprise – an environment where cutting corners usually causes more long-term problems than benefits. As a profession we need better practices for lean startups
Life as an Enterprise Software Engineer
I learned most of my technical skills in established (i.e. non start-up) companies doing what most engineers do every day: I solved problems. Problems like “figure out a way to speed up the data processing”, or “get the next customer feature into the release.”
I also learned that there are wrong ways to solve problems, that cutting corners on scalability, security, etc. ultimately lead to even bigger problems later.
For example, anyone who has worked in enterprise software has struggled with poorly designed databases that didn’t scale as the application grows. “Why didn’t they solve this problem the right way (TRW) the first time?”, we mutter, wasting money and time cleaning up others’ shortcuts.
Problems, problems, and more problems. A day in the life of 99% of the world’s software engineers is spent coming up with better ways to solve problems.
Life as a Startup Hacker
Actually some engineers do work in such an world – lean startups. In startups both the solution and the problem are unknown. Startups don’t know if they have sufficiently defined the problem and the solution until customers vote with their wallets. Eric Ries gave a great presentation on this topic at Web 2.0 Expo 2009.
Solving problems TRW (the right way) almost always takes longer than quickly hacking together a solution. Since real startup progress is measured in increments of customer learning, TRW is often the wrong choice when you can learn faster with a hack.
When developing software for a startup, you have to forget all the lessons you’ve learned when building enterprise software for large companies or the government: architecture, design, test plans, security scans, performance testing — all that goes out the window.
And therein lies the dilemma: Much of our engineering training in established companies can handicap us in a startup. I’ll give a recent example from my own experience.
My Experience Handicap
Applications built with Ruby on Rails can maintain relational integrity at the application layer – in other words, you don’t need foreign keys in the database. Many experienced developers argue that this is terrible software development practice.
The link above has some great comments:
We had the same argument here at work. We decided to go down the not using foreign key path in hind sight it’s caused us problems
Bugs in the application resulted in garbage in the database that wasn’t discovered until a couple years and terabytes later. One of my colleagues had the joy of spending 6 months as “data garbageman” cleaning up the database. Trust me, you don’t want to go there. Ever.
So how did I design the database for my most recent startup? Having been in situations where poorly managed database relationships resulted in months of rework, I used foreign keys. That was my experience, and I’m guessing the experience of the developers who made the comments above.
Unfortunately I found that foreign keys in my Rails migrations were a constant source of headaches. Moreover, I decided to migrate to Heroku during the project and had to re-write the foreign keys for Postgres instead of MySQL. What did I learn about customers in this process? Nothing.
In retrospect, I believe I followed bad practice for lean startups building working prototypes. Database integrity is an important issue when you have achieved some measure of success.
May I be so blessed to have these type of problems in my next startup.
Lean Startups are Different
Unfortunately I didn’t find great guidelines for dealing with these software development tradeoffs in the Rails community. The voices of experience advocated TRW to design databases for an established company where the problem is known. And in 99% of cases, I believe they right – just not when you don’t know if you’re solving the right problem.
Arguments like “You do/don’t need foreign keys” miss the real point:
Lean Startups need different best practices from enterprise software development
Am I advocating that we ship buggy code and hire high school students for the engineering team? Of course not. What I am suggesting is that we need new best practices like investing in agility and recognizing that the biggest risk is shipping products nobody wants.
Does test coverage allow a company to iterate faster or does the investment in test code just slow down the learning process? And if you decide to write tests, what parts of an application should be tested? Should you even bother to test the View or can you catch 90% of the problems with simple controller tests? Is Selenium really worth the hassle? (it wasn’t for me) RSPEC?
Do you even need design and color? Or can you learn faster by using a minimalist front-end that supports mobile and desktop customers like 43 Actions.
Resources for the Lean Startup Developer
I predict that this essay will be obsolete in a year. Developers are rapidly learning these lessons and beginning to share best practices. Some resources:
The Google Group Lean Startup Circle
The Lean Startup Wiki case studies.
And of course, Eric’s blog, the single best source IMHO. At least until he writes a book, something I hope he is considering.