Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Experienced Developers Can Handicap a Lean Startup

kevindewalt.com

Post reply on HN
Print view View original

41–50 of 55 posts

Re: How Experienced Developers Can Handicap a Lean Startup

#41

Post by kscaldef »

bayareaguy wrote: post #20
ulf wrote: post #2

I guess an even more experienced developer knows when to use his best practices, and when to leave them be for the sake of the project...

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. While I agree with Mr. Dewalt's basic message, identifying integrity constraints as something a "lean startup" shouldn't worry about…

What really baffled me about that anecdote is that I wonder what he was "learning about his customers" by migrating hosting providers and database systems. And yet, somehow, foreign keys get all the blame.

Re: How Experienced Developers Can Handicap a Lean Startup

#42

Post by moron4hire »

davi wrote: post #6
shin_lao wrote: post #4

Earlier quoted context omitted.

I agree. Good developers work fast and well. They produce less bugs and better code. That's just why you pay them more. If your experienced developer is slower at doing better, he just doesn't have the proper amount of seniority.

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.

Re: How Experienced Developers Can Handicap a Lean Startup

#43

Post by DanielBMarkham »

omouse wrote: post #30
DanielBMarkham wrote: post #22

The problem here is that the devils are in the details. Should you use small variable and function names because they are easier to type? Throw away all error-checking because without customers errors don't matter? Or as this article says, perhaps toss out FKs because they might be difficult to refactor? Trying to make the argument that it's one way or the other is really taking a very complex decision and boiling it…

It's not that complicated. Quality takes time. As Greenspun said once, if we want software engineers to be treated with respect, we need to force employers to respect a certain minimum standard of quality. Regarding your example...by releasing something badly designed/programmed into the wild and taking money from customers, you are committing fraud. It needs to be seen this way otherwise we will never be forced to t…

So if I wrote a really buggy program but you could still use it to make a million bucks in the next week, I would be committing fraud?

Could somebody please defraud me like that? Please?

Re: How Experienced Developers Can Handicap a Lean Startup

#44

Post by omouse »

DanielBMarkham wrote: post #43
omouse wrote: post #30

Earlier quoted context omitted.

It's not that complicated. Quality takes time. As Greenspun said once, if we want software engineers to be treated with respect, we need to force employers to respect a certain minimum standard of quality. Regarding your example...by releasing something badly designed/programmed into the wild and taking money from customers, you are committing fraud. It needs to be seen this way otherwise we will never be forced to t…

So if I wrote a really buggy program but you could still use it to make a million bucks in the next week, I would be committing fraud? Could somebody please defraud me like that? Please?

You're being too literal. What I'm saying is that, at the moment, there is no harmful consequence for buggy programs. Buggy programs that people buy means $$ from the initial sale of the product and your company continues to live and you get paid in $$ to maintain and fix the buggy program.

As long as the software can run, we're rewarded for creating it, no matter its quality.

In our own minds, we have to treat that as fraud and need to feel awful about it.

Re: How Experienced Developers Can Handicap a Lean Startup

#45

Post by DanielBMarkham »

omouse wrote: post #44
DanielBMarkham wrote: post #43

Earlier quoted context omitted.

So if I wrote a really buggy program but you could still use it to make a million bucks in the next week, I would be committing fraud? Could somebody please defraud me like that? Please?

You're being too literal. What I'm saying is that, at the moment, there is no harmful consequence for buggy programs. Buggy programs that people buy means $$ from the initial sale of the product and your company continues to live and you get paid in $$ to maintain and fix the buggy program. As long as the software can run, we're rewarded for creating it, no matter its quality. In our own minds, we have to treat that…

What I'm saying is that people judge the value of the program on just that -- it's value to them. The quality of construction can certainly affect perceived value but a perfectly-constructed program which provides no value is useless. No, it's worse than useless, because it's an example of craftsmanship-over-function.

All the quality in the world isn't going to make a pointless program worth anything. But a crappily-written program that provides lots of value is a great thing no matter how horribly it was hacked together.

Re: How Experienced Developers Can Handicap a Lean Startup

#46

Post by KevBurnsJr »

"The problem with efficiency is that it has nothing to do with whether or not what you are currently doing is the right thing to do."

http://blogrium.wordpress.com/2009/11/05/why-efficiency-is-n...

Hacking together a solution may be more efficient in the short term, but it may also distract you from discovering an effective solution. Diving into a solution before understanding the problem is often a recipe for wasted time. Regardless of whether your solution is a hack or a gem, you're committed to seeing it through. Take time to frame the problem before you commit to taking a stab at it.

Measure twice, cut once. Teak or balsa.

Re: How Experienced Developers Can Handicap a Lean Startup

#47

Post by synnik »

wglb wrote: post #13

I think the title should be "How Enterprise Experienced developers can Handicap a Lean Startup". This is really just limited experience. I once saw a very simple project list used by 20 people turn into an enterprise nightmare with 29 tables and a 3-month development cycle. Wouldn't it seem to be a mismatch from the very beginning?

In most enterprises, 29 tables and a 3-month development cycle ARE quick hacks.

Re: How Experienced Developers Can Handicap a Lean Startup

#49

Post by joe_the_user »

bayareaguy wrote: post #20
ulf wrote: post #2

I guess an even more experienced developer knows when to use his best practices, and when to leave them be for the sake of the project...

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. While I agree with Mr. Dewalt's basic message, identifying integrity constraints as something a "lean startup" shouldn't worry about…

It seems like there are two kinds of experience.

One is learning to do the same thing over-and-over again, getting somewhat better at it. This often results in being more rigid.

The other is learning the purpose and strategy behind what you do and being able to alter your behavior accordingly. The often results in being more flexible.

An experienced developer probably has a combination of these two ingredients. Thus there's no guarantee that an old timer will be more flexible or less flexible than a beginner. It's more a question of whether a developer has kept their learning and understanding to be at a high level.

I mean, it's important to realize that the purpose of a full ACID database is to maintain the integrity of enterprise data - key data that is used and re-used by multiple departments. Of course, in a start-up, the ACID requirement can be modified depending on whatever decreased need there is for the properties of ACID. An experienced developer looking from a high level doesn't just recite ACID requirement or glibly toss them out the window but looks at the actual requirements and modifies things accordingly.

Re: How Experienced Developers Can Handicap a Lean Startup

#50

Post by dstorrs »

btilly wrote: post #39
bayareaguy wrote: post #20

Earlier quoted context omitted.

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. While I agree with Mr. Dewalt's basic message, identifying integrity constraints as something a "lean startup" shouldn't worry about…

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 small it was almost possible to visit every site. Site designers, site developers, and customers were all trying new things constantly and learning what worked. There weren't many expectations because everything was so new.

Today, my guess is that people have a much higher standard for e-commerce. But that's just a guess.

Post reply on HN