[gprasanth]

It's fun the first 2 times you do it as you like. Then you start thinking about doing it right.

Then you start thinking about building stuff right from the beginning which is basically intelligence you've gathered.

It takes finesse to craft things quickly but with quality.

Bias to do stuff quickly is very hard to let go off. Doing things in an organised way has its value. Basically if you're not going to rewrite something in the next year, do it right now. Otherwise you're just borrowing time from future.

Short term hacks vs long term meaning.

[marcosdumay]

After you learn some lessons, it's tempting to check any action against all of them. But that slows you down, the more experience you have, the slower you will be. You don't want to do that either.

Anyway, it is very hard to stay away from both extrema. It requires constant self awareness, and even more learning, of the hardest kind where you are required to feel stupid all the time.

[gfodor]

There are path dependencies. If the short term hack accelerates your ability to get enough traction to increase runway, you may survive to see the “right” solution implemented. whereas if you pursued the “right” solution more directly from the beginning, the additional delays would have killed you. Good technical leadership embraces the short hack and guides the project through righting it when the opportunity is there. (To fail to do either is an equal failure, and both are hard.)

Anyone claiming there is a clear answer to these questions is deluding themselves. Tactically, the best weapon is to recognize your own weaknesses, and it seems to me that engineers often have more of a bias towards performing tool and technology analysis and research in the name of avoiding the hard and often humiliating task of shipping software that users will almost certainly hate in its earliest versions.