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:
ttttttttttttttttttttttttttttttdddddddd
If you want to do something right the first time, thinking about it almost always takes longer. But actually doing it can take less time, often much less time.
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."
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)
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.
You're thinking about it from a business development standpoint in addition to a technical stand point.
I'm just talking about the technical approach. You've gained no new insight into what your business is supposed to be, you've just learned a hella wrong way of solving a technical problem. Now your thoughts are cluttered with the effort and you had to spend time unlearning the previous approach.
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.
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":
If you want to do something right the first time, thinking about it almost always takes longer. But actually doing it can take less time, often much less time.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."