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

31–40 of 55 posts

Re: How Experienced Developers Can Handicap a Lean Startup

#31

Post by gaius »

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…

Yep. Sure, to survive in the long term, you've got to survive in the short term first. But taking a shortcut that ultimately results in losing a customer's data (or indeed, losing track of their money or their stuff) is a bigger risk than getting your product out of the door a day late(r than you wanted).

Re: How Experienced Developers Can Handicap a Lean Startup

#32

Post by gaius »

fnid wrote: post #23

So basically the author is saying that experience says foreign keys are good, but in practice foreign keys make development and switching data providers harder. Seems like an experienced developer would have written a data access layer that wasn't so concerned about how the underlying data store managed foreign keys. Almost all senior level developers know that foreign keys are a performance inhibitor and plans for e…

If the purpose of your foreign key is to ensure data integrity, then no amount of denormalizing can help. The point of FKs is to enforce business rules in a central location (e.g. don't ship a part to a non-existent customer, if a customer's address changes then there's only one place to update, etc).

The alternative to FKs is to write your own "middleware" or "business rules engine" and guess what, that doesn't get you to market any quicker either.

Re: How Experienced Developers Can Handicap a Lean Startup

#33

Post by nzmsv »

davi wrote: post #7
edw519 wrote: post #3

Solving problems TRW (the right way) almost always takes longer than quickly hacking together a solution. I would rephrase this to: Thinking about solving problems TRW (the right way) almost always takes longer than thinking about quickly hacking together a solution. Or graphically, with "t" as "minutes thinking" and "d" as "minutes doing": The quick way: ttttttdddddddddddddddddddddddddddddddddddddddddd The right way…

Sure -- but I don't think this is the point of the article. Let's say your ratios are correct, and you want the "t" to "d" ratio to be high in most cases, for shorter overall "t+d". The article is saying that you often want to get through each of the following lines as fast as possible: ttd (release) tttdd (release different feature set) td (release totally changed and simplified app) tttttttttttttdddd (now we unders…

This is even more true if you make the d stand for debugging.

Re: How Experienced Developers Can Handicap a Lean Startup

#34

Post by jerf »

zackattack wrote: post #26
jerf wrote: post #15

Earlier quoted context omitted.

No, it's not orthogonal. I can see it in things like the complaints about how foreign keys "caused problems" in the migrations. Generally, that means one of two things: The foreign keys were actually preventing bugs in your migrations (which even in a startup context is a Good Thing(TM), as "buggy migration" is effectively slower than "correct migration" no matter how fast the buggy migration is), or the developer wa…

what does orthogonal mean in this context

Two vectors are orthogonal if the addition of one of them does not affect the "amount" of the other, when using them as basis vectors. In this case, "(1,0)" and "(0,1)" are orthogonal; no matter how far in X you go, the amount of Y-ness doesn't change. (1,1) and (1,-1) are also orthogonal. In the metrics most people learn, this means the vectors are at right angles. (Forgive me this simplification, mathematicians, going further will only obscure things.)

Programmers tend to abuse this term to mean "the two things are totally unrelated", even though the term really only applies to certain mathematical constructs like vectors. Claiming that type-safety is orthogonal to garbage collection would mean the two are entirely separate concerns and that you can freely have none, one, or both, and that the two issues never matter to each other. Now, technically this isn't quite true, which is why I say we "abuse" the term, because the full meaning of "orthogonal" is that you will literally never be considering the effect of one while examining the other, and this is not true; type systems do some impact on GC, for instance. However, in many cases this is "true enough" for someone to say they are "orthogonal".

In this case, I'm not arguing merely that the precise definition is not met, because it pretty much never is, but that the spirit in which programmers use the term is also not applicable here, as the questions of "code quality", "speed", and "developer experience" are indeed tightly interrelated and so answers like "you always have to sacrifice quality for speed" are too simplified.

Re: How Experienced Developers Can Handicap a Lean Startup

#35

Post by fnid »

gaius wrote: post #32
fnid wrote: post #23

So basically the author is saying that experience says foreign keys are good, but in practice foreign keys make development and switching data providers harder. Seems like an experienced developer would have written a data access layer that wasn't so concerned about how the underlying data store managed foreign keys. Almost all senior level developers know that foreign keys are a performance inhibitor and plans for e…

If the purpose of your foreign key is to ensure data integrity, then no amount of denormalizing can help. The point of FKs is to enforce business rules in a central location (e.g. don't ship a part to a non-existent customer, if a customer's address changes then there's only one place to update, etc). The alternative to FKs is to write your own "middleware" or "business rules engine" and guess what, that doesn't get…

My point was only that it seems the author of the post has limited experience with foreign keys.

Re: How Experienced Developers Can Handicap a Lean Startup

#36

Post by jerf »

davi wrote: post #28
jerf wrote: post #15

Earlier quoted context omitted.

No, it's not orthogonal. I can see it in things like the complaints about how foreign keys "caused problems" in the migrations. Generally, that means one of two things: The foreign keys were actually preventing bugs in your migrations (which even in a startup context is a Good Thing(TM), as "buggy migration" is effectively slower than "correct migration" no matter how fast the buggy migration is), or the developer wa…

Let's see if you agree with this restatement of your post: Fast, mediocre coders may be able to iterate really fast in order to get something out in front of users. This means that when you don't know what the problem or the solution is (as discussed in the article), they can be effective at identifying the problem that requires the solution. But if their crummy code gets used as the nucleus of the solution (once the…

Yes. That's actually an important point that I only alluded to. There's a crossover period during which a hackhackhack coder will indeed have "something" out the door faster than me. If your startup fits entirely into that horizon, then, well, don't hire me. Or make it very clear to me that that's what the situation is. Some "startups" do fit into that time period, though as my scare quotes indicate I'm not sure that's really the right word for such an endeavor.

However, I've gotten my crossover period down to about two months on most projects. Some projects even less; a hackhackhack coder who goes for PHP with no frameworks is going to have trouble keeping up with me working in Django. (In this case, I don't intend this as a criticism of PHP, as the sentence indicates.) Of course an experienced developer will reach for some appropriate framework in PHP, but the entire point is that we're comparing experienced v. inexperienced.

(Separately, I don't want to make a separate post for this point, but: There is a tautological element to my argument here, which is that if a putatively experienced developer makes a bad choice on the do-it-right/do-it-fast scale, then by that very fact they have shown they were not an experienced developer. There's a bit of "defining myself the win" there, but I think there's still a point to it. And like I said, I've made that error and am trying not to make it again.)

Re: How Experienced Developers Can Handicap a Lean Startup

#37

Post by btilly »

zackattack wrote: post #26
jerf wrote: post #15

Earlier quoted context omitted.

No, it's not orthogonal. I can see it in things like the complaints about how foreign keys "caused problems" in the migrations. Generally, that means one of two things: The foreign keys were actually preventing bugs in your migrations (which even in a startup context is a Good Thing(TM), as "buggy migration" is effectively slower than "correct migration" no matter how fast the buggy migration is), or the developer wa…

what does orthogonal mean in this context

In simple English, orthogonal means "at right angles". People often say that two things are orthogonal when they mean is that they are different dimensions that are unconnected with each other.

To pick a silly example, the number of coffee cups I have is orthogonal to the number of jars of jelly beans I have.

Re: How Experienced Developers Can Handicap a Lean Startup

#38

Post by willwagner »

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

Yeah, an experienced startup developer can acknowledge and articulate the tradeoffs between time to market and the perfect design, sometimes delaying some of the design (e.g. perhaps deferring scaling tasks until it's needed) to get things done faster, but at a minimum, making it functional and maintainable.

It's like the army corp of engineers. They can make a bridge for the general public, but they also know how to design something quick (and hopefully sturdy) for troops and supplies during a conflict. It may not be pretty, but it gets the job done when it's needed most.

Re: How Experienced Developers Can Handicap a Lean Startup

#39

Post by btilly »

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…

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 area) where people care that the site does what they want and is responsive, but are tolerant of occasional problems.

Yes, I am aware of all of the possible shortcomings. However requiring people with good ideas to understand more theory before they can get things done does not help motivated newcomers to get interesting things done. And lots of newcomers getting interesting things done leads to successful startups. Which is how a crappy but convenient database (MySQL) got traction in the first place.

For a classic essay on the tradeoff between convenience and correctness, see Worse is Better at http://www.jwz.org/doc/worse-is-better.html.

Re: How Experienced Developers Can Handicap a Lean Startup

#40

Post by giblets »

edw519 wrote: post #3

Solving problems TRW (the right way) almost always takes longer than quickly hacking together a solution. I would rephrase this to: Thinking about solving problems TRW (the right way) almost always takes longer than thinking about quickly hacking together a solution. Or graphically, with "t" as "minutes thinking" and "d" as "minutes doing": The quick way: ttttttdddddddddddddddddddddddddddddddddddddddddd The right way…

In my experience, hacking things is only faster because you rarely try to do things the right way and are more familiar with hacking your way out of problems than you are planning for them. Hacking should be a last resort, when timelines are up and it is down to that or shipping nothing.
Post reply on HN