How Experienced Developers Can Handicap a Lean Startup
kevindewalt.com
How Experienced Developers Can Handicap a Lean Startup
1–10 of 55 posts
Re: How Experienced Developers Can Handicap a Lean Startup
#2I 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...
Re: How Experienced Developers Can Handicap a Lean Startup
#3Solving 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:
ttttttttttttttttttttttttttttttdddddddd
When trying to convince my customers to do things the right way, I often tell them, "It's not how soon we get started, it's how soon we finish."
Re: How Experienced Developers Can Handicap a Lean Startup
#4I 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...
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.
Re: How Experienced Developers Can Handicap a Lean Startup
#5In my past life as an "enterprise" programmer, most people at best paid lip service to doing the "Right Thing." Most code I saw was incredibly bad, written by programmers who knew they would switch groups or companies, or go into management, before they had to seriously maintain it. Programmers I met who worked in an "enterprise" were not into their work. Few of them knew of anything outside of their prescribed Java or sometimes C++, or followed anything new or interesting in their field. I could mention something like The Mythical Man-Month, or talk about looking up an answer in Knuth, and get blank stares. Explaining closures to all but a couple was like talking to a wall. This was at a top-tier company, in one of the most prestigious groups in its IT organization.
I think real experience and talent as a programmer shines in the ability to find a solution which is both correct and takes the same amount of time to write as garbage. This is not always possible, of course, but I would caution against coding without thinking about this trade-off.
In the case of the original article, the author cites the foreign key debate. Truth is, because reasonable and good programmers disagree on which is better, this is not even a good example of quick-and-dirty versus the-right-thing. If anything, it's an example of difficulties in storing data in traditional relational databases.
Re: How Experienced Developers Can Handicap a Lean Startup
#6I 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...
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.
Re: How Experienced Developers Can Handicap a Lean Startup
#7Solving 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 understand the problem, do a good job)Re: How Experienced Developers Can Handicap a Lean Startup
#8Solving 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…
Don't forget that some of those final t's are because you already invested a lot of other t's and d's into doing it the wrong way.
Re: How Experienced Developers Can Handicap a Lean Startup
#9Solving 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…
Agreed - I understand the point of the article and that my post does not directly address that point. But it does challenge OP's statement (which I italicized) that he uses as a basis for his conclusions.
I fully agree that iterative analysis and development is usually quicker than the waterfall method. I'm just adding that a little thought each step of the process can make everything quicker. If you think things through enough (which more experienced people often do better), you can have your cake and eat it too.
Re: How Experienced Developers Can Handicap a Lean Startup
#10Earlier quoted context omitted.
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…
Don't forget that some of those final t's are because you already invested a lot of other t's and d's into doing it the wrong way.
I'm not sure what you mean -- that if you hadn't done the first three steps, you wouldn't have needed so many t's in the last?
you already invested a lot of other t's and d's into doing it the wrong way
But the first three steps were an incredibly valuable investment -- now you know the right problem to solve!
(Maybe you mean something like this, just not sure from your comment.)