How Experienced Developers Can Handicap a Lean Startup

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.

Problem Solving in the Enterprise

Problem Solving in the Enterprise

But almost all of the engineering problems in established companies have a common thread – the problem is known, only the solution is unknown. In fact, many people reading this post can’t imagine a world where you’re trying to solve an unknown problem. After all, what do you build without requirements?

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.

From Eric's Presentation at Web Expo 2009

From Eric's Presentation at Web 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.

–Chris Bucchere, Founder of Crowd Campaign and The Social Collective

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.
    Lean Startup Meetups are happening in DC, San Francisco, Chicago, Boston, Berkeley, New York

And of course, Eric’s blog, the single best source IMHO. At least until he writes a book, something I hope he is considering.


  1. Andrew Lawson November 6, 2009 at 10:18 am #

    I’ve got to disagree with you on this one. There are good developers and bad developers. For the case of argument lets remove bad developers from the equation because if you are a startup you want to avoid them whether they are a novice bad developer or an experienced bad developer.

    So taking good developers, developers with experience should beat developers that are lacking experience hands down. Your example maybe showed where you experience was a handicap, but I bet your experience outweighed not having enough experience in 100 other areas of the development lifecycle.

    There are two other areas where being a truely experienced developer would also make a big difference. Firstly it would be highly unusual not to have had some business analysis experience once you are more experienced. Business analysis combined with development is taking poorly defined problems and turning them into solutions – exactly what startups need and something less experience developers are ususally lacking in. Secondly as you get older (and hopefully wiser) you are less inclined to jump on the latest thing. Do you really need that new beta framework, do you need to do this or that. A good example would be knowing when or when not to use TDD or unit testing. The technical blogosphere is awash with unit testing at the moment, but if you are aiming for MVP and currently know if you are even going to get any clients I think you can forget about unit testing and just get it out. Less experienced developers may find that decision harder to make, especially when they have to justify it to someone else or defend their decision in 3 months time when something actually goes wrong (which falls into what I call the “name problem to have” realm).

    But for most startups I would say the hardest part is finding a good developer, there are few about, worry about experience after that.

  2. Ron Leisti November 6, 2009 at 11:02 am #

    On foreign keys, I’ve actually seen the opposite effect as far as programming experience goes. For better or worse, what I’ve seen is a pro-foreign key attitude coming from freshly minted programmers (because they teach that stuff in school), followed by the gradual disenfranchising in older developers. I’m not saying that foreign keys are bad necessarily, but experience does tell programmers when they can be a pain in the arse.

  3. Rudolf O. November 6, 2009 at 11:06 am #

    This article is dangerous and poisonous to the computing industry.

    A working prototype usually becomes THE PRODUCT! it mutates into the final buggy product that is shipped or if it doesn’t, why the fuck are you wasting time building a prototype at all?

    If you have the time to build a prototype, and then the type to create a properly designed product, then you have the time to do things right in both cases. On the other hand, if you don’t have the time, well you’re going to fail as a computing scientist or a software engineer (whichever you see yourself) because you will be shipping a buggy product that was initially a prototype.

    I understand that a business wants to cut costs, but when that comes at the expense of quality, then you’re doing society a disservice by shipping the product.

  4. Ben November 6, 2009 at 11:08 am #

    Great Article, I keep running into this dichotomy.

    IMO, this is what differentiates Good developers from Rockstars. A Rockstar knows how to ride the line between the “right” way and the fast way.

  5. Brian November 6, 2009 at 12:40 pm #

    Great post. This is a tricky problem. It can be incredibly frustrating for a developer who is coming from a more structured coding environment to move to a start-up environment. The answer is certainly not to throw out all those good coding practices and go completely cowboy (no tests, no plan, etc…). The key is knowing what are the critical paths in the software, the core features, and testing those at the right level (unit, integration, story, etc…) so that the moving target of what-the-product-will-be doesn’t invalidate all your work. As the product matures and the company figures out what features sell then more tests need to be added and the code re-factored. Rinse and repeat. Oh, and the code should do as little as possible to get the job done. Coders (myself included) often have the habit of trying to predict features, these predictions are often wrong and add needless complexity.

  6. David November 6, 2009 at 12:48 pm #

    How odd that you equate “experience” with “enterprise experience”.

    There are plenty of experienced engineers who have spent their lives hacking and/or working in startups.

  7. Gabe da Silveira November 6, 2009 at 1:31 pm #

    There is definitely some truth here, but on balance I tend to agree with some of the other commenters–this article is likely to encourage young developers to dismiss their older counterparts as over-careful and out-of-touch.

    It doesn’t matter whether you’re working in the enterprise or for a seed-stage startup, there is both throw-away code, and long-term production code. In both cases, code written today is going to be more painful to modify tomorrow, often by several orders of magnitude.

    I agree that in a startup you need to cut corners in order to even figure out what you should be building, but you still need to know which corners to cut, because 3 months from now those corners you cut are going to be divided between the things you threw away (good) and the things that are calcifying into the backbone of your application (bad).

    As always, the real (and largely unmeasurable!) talent is the clairvoyance to determine which is which far in advance. Experienced developers have an edge here. And obviously this is much much harder in a startup here the product is still in massive flux.

    The “experienced” developer who rigidly does things a certain way based on past experience is a red herring. This person is simply not cut out for a startup either way. If they were a younger version of themselves sure they might move faster, but how soon before their ignorant mistakes bring them past the point of diminishing returns? What happens once the agility of the lean startup is squandered on unmaintainable legacy code?

  8. Augustine Koshy November 6, 2009 at 1:47 pm #

    I am not sure Rudolf O. really understood the message here. The author is not promoting anything dangerous or poisonous here. He is talking about how experienced enterprise developers can go in the wrong way to cause a startup burst. Quality itself is an attitude and perception. However Rudolf O lacks on both. Rudolf O’s tunneled thoughts are the real dangerous and poisonous one. May god help your brain to think straight and right 🙂

  9. kevindewalt November 6, 2009 at 2:49 pm #

    Looks like I touched a few nerves today. 🙂… and on Hacker News:… Interesting debates

  10. TKL November 6, 2009 at 4:06 pm #

    I agree. Having worked in both a 2 man shop and a 9,000 person development organization there comes a point when you need to match your development approach with your purpose.
    If you are trying to build an critical enterprise app then by all means use a full SDLC. But I’ve seen many cases when the app concept is not yet proven or that it is even disposible… ie: will be used one time and then never again. In those cases you need to just make it happen.
    There are cases when a better/smarter method is not more time consuming and provides more flexibility down the road. In this case experience is key.
    Advanced error detection for example is something that I often come back to. No need to spend hours coding around ever conceivable way a user could skrew it up if it doesn’t do what the user wants in the first place….. Get it working first… then refine as you go.

    Again this is for non-critical apps…

    just my 2 cents


  11. Rob November 6, 2009 at 4:56 pm #

    What’s missing here is the question that doing things TRW begs:

    When you were taking the time to do things TRW, did you not have to (or wish you could) throw everything away as soon as you released version 1?

    Many assume that heavily front-loaded architecture/plumbing/etc. design processes (e.g. “you start an agile project with 3-4 architecture sprints, right?”) consistently yields better results and by results I mean “increases the chances you won’t have or want to just throw it all away for v2.”

    When in your experience have you ever really gotten it right during this period? You’ve spend loads of time up front except you’re spending time solving problems you haven’t run into yet, which you may never run in to.

    By the time you hit v2, you’ll wish your product was scaling in ways you couldn’t have anticipated, being deployed into environments you never considered, etc.

    If our experience tells us that’s the case, why do we continue to front-load engineering initiatives with activities that mostly do not pay off?

  12. Christoffer Du Rietz November 6, 2009 at 7:16 pm #

    Great article. I’m not a developer but a designer and I can totally relate to this. I’d say that in most companies the exact same thing goes for designers. On the web today were time-to-market is the difference between success and failiure, experienced designers (including myself) tend to want to spend way to much time perfecting the product before getting it out the door. I hate to say it, but for most businesses online, design isn’t more important than time-to-market. So all you designers out there, get over yourselves!

    I must say though, that there of course are exceptions. But mostly only in the premium market and when design is mean to be your main competetive advantage in a very crowded marketplace.

  13. Tom Zinter November 6, 2009 at 7:42 pm #

    “Inexperienced developers have one big advantage: they haven’t been programmed to work for perfection and they’re not afriad to make mistakes.”

    Yeah, because we all know this is by no means any sort of generalization or anything. Its unequivocally true. Experienced developers only want perfection and are deathly afraid of mistakes. Definitely don’t get one of them.

  14. CHagner November 6, 2009 at 10:54 pm #

    It comes down to figuring out what’s the biggest risk that you’re facing?

    1. Not being able to solve the problem at all
    (or put another way: not bringing a compelling enough solution to market)
    2. Not implementing the solution TRW.

    If you’re scared to death of #1, then #2 shouldn’t be driving how you spend your time and energy.

    Put another way, if you suffer #1 because you spent too much time solving #2, then you missed Kevin’s point completely. 🙂

  15. Jason Huggins November 7, 2009 at 3:12 pm #

    I was with you until the “is Selenium really worth the hassle” part. 😉 Before Selenium existed, let me assure you, verifying javascript-heavy web apps in IE and Firefox was an even bigger hassle. 😉

  16. Spencer Tipping October 2, 2010 at 5:11 pm #

    I think this post is more about development dogma than experience. All of the failures you mentioned involve a developer choosing dogma over situational judgment, which in my mind is an inexperienced thing to do. It takes experience and expertise to know when it’s safe to go against the grain and take a risk in your setup to achieve greater productivity.


  1. Cogblog » Blog Archive » Is Minimum Viable Product Your Excuse For Shoddy Work? - January 28, 2010

    […] I see a blog post like this one.  And my reaction is, “sounds like you are working with the wrong engineers”, not that […]

I read EVERY comment and want to hear from you