How Experienced Developers Can Handicap a Lean Startup • Hacker News Board

Re: How Experienced Developers Can Handicap a Lean Startup

#51

Post by dstorrs » Fri, Nov 06, 2009, 9:09 PM UTC

moron4hire wrote: post #42

davi wrote: post #6

Earlier quoted context omitted.

You seem to be missing the point of the article: producing less bugs and better code can be wrong if writing that code slows down finding out what the problem is. Speed-of-writing-good-code is an orthogonal parameter, here.

Why is writing good code slower than writing bad code? I'd rather write good code once, now, rather than bad code now and good code later.

According to my definitions, good code must perform correctly or else fail gracefully. It must also be robust, debuggable, and maintainable. Those extra conditions mean thinking more, and writing more code. That takes extra time over hacking out the quick-and-dirty version.

For example, right now I'm helping a friend out with a project to send email. In about 10 minutes I could whip something out that does this using backticks (i.e., shell escapes), no error checking, no logging, etc. It would be in front of the customer and suitable for feedback very quickly. It would also be short, easy to understand, and would do its job correctly 99% of the time. All of these are good things, but it would still be bad code, because the other 1% of the time it's going to break horribly and someone is going to have to come in and fix it.

Re: How Experienced Developers Can Handicap a Lean Startup

#52

Post by btilly » Fri, Nov 06, 2009, 9:18 PM UTC

dstorrs wrote: post #50

btilly wrote: post #39

Earlier quoted context omitted.

The initial success of MySQL is evidence against your assertion. When MySQL came out it was the first widely used database that explicitly said that speed of development and operation matters more than correctness. Experienced DBAs were shocked and horrified. Over time the database has matured, however its initial success stands as a testament to the principle that there are a lot of problems (particularly in the web…

When MySQL came out it [...] said that speed of development and operation matters more than correctness. [...I]ts initial success stands as a testament to the principle that there are a lot of problems (particularly in the web area) where people [...] are tolerant of occasional problems. I wonder if this would still be true today? Things are very different from 1994, when MySQL was born. Back then, the Web was so sma…

People want to believe that their money is safe. But people are still pretty tolerant if something like twitter has an outage.

Re: How Experienced Developers Can Handicap a Lean Startup

#53

Post by scotty79 » Sat, Nov 07, 2009, 7:21 AM UTC

> 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.

Cleaning up should be faster.

It's strange that thing A is optional but without doing thing A up front you can get yourself in a mess such hard to clean up. If thing A is optional cleaning up the mess resulting in not doing thing A and having bad luck should be much easier. Db guys tend to overlook interesting problem how to get out of the mess. They just have pie in the sky rules and if you don't use them all and get yourself into trouble then it's your fault so suffer!

Re: How Experienced Developers Can Handicap a Lean Startup

#54

Post by adw » Sat, Nov 07, 2009, 10:22 AM UTC

hello_moto wrote: post #21

It's always the developer's fault eh? Marketing: We need these features now to close $1 mill deal Dev: but... but... we can't implement them in 2 days... we need more time Marketing: Go figure out something... Marketing: Remember that Y features we asked last month? well, sorry, the customers decided to go with X... Dev: Uh... Uh... Perhaps once in a while we should switch side: hey management/marketing/sales/CEO, do…

And believe me, if your sales and marketing team are any good they'll be sweating blood trying to do that. But it may not be possible. In fact, pounds to pennies it isn't.

(Won't it be a founder selling anyway? I reckon it's a tremendous advantage if your biz dev person/people know one end of Textmate from the other and can do prototype-building spadework, too. It's hard to really get how a job feels if you've never done it. Marketers gotta code and coders gotta market...)

Big, slow thinking sessions ignore this: in an early stage startup you don't know what you're selling. You don't know until you sell it. So you need to find out by showing people endless variations on your core theme, and an iota of effort put into making one which doesn't sell is wasted effort, and wasted effort is death.

You are going to kill nearly all your features. That's code which gets discarded, but it's served it's purpose - working out what the business really is.

Re: How Experienced Developers Can Handicap a Lean Startup

#55

Post by evilbit » Sat, Nov 07, 2009, 1:51 PM UTC

If Ruby on Rails causes nothing but headaches for those who insist on silly frilly things like data integrity, I will theorize that perhaps the problem lies with RoR, not foreign keys.

You probably don't actually need a database at all , given that the integrity of data stored is not paramount. You don't get any points for "We have this data. We have no way of assuring it's correct or is what we want it to be - but we have it!"

On the other hand, given that most start-ups don't bother with things like a business plan (at least one which doesn't end with "Step 3. ????? Step 4. Get bought by Google"), perhaps it's only appropriate that such start-ups do away with other fundamentals of reality, such as data integrity.