3 ms·

Because the latter barely ever happens in 'twice the time' right from the start. Even assuming the flat 2x, that's a lot for a project that takes 6 months the '

Because the latter barely ever happens in 'twice the time' right from the start. Even assuming the flat 2x, that's a lot for a project that takes 6 months the 'dumb way' for any company nowadays. The pay-off for 'smart way', is unlikely to be there before 2 years from project start. You're lucky to have a company look ahead more than 2 quarters, let alone 2 years. That's not to mention all the other problems as commenters on a different article about speed pointed out yesterday. Dumb way at least gives you something. 'Smart' way goes in and makes a hundred assumptions only to realize they forgot something a prototype would've pointed out to them. Not the dev's fault management doesn't listen to "this is a throwaway prototype".

toss1 3y ago
This is why you should apply the Dumb&Fast approach for a first ~MVP version, plan to throw it away, then apply the smart & careful approach for the more durable versions. The first version should get out there quickly and validate, adjust, and/or destroy your assumptions about your customers, systems, usage & load patterns, etc., then that deeper knowledge and more careful approach goes into the next 'real' version. Prevents premature scaling & optimization, and you never have to pay the tech debt from the 1st version. Source: been there, done that, works great.
angarg12 3y ago
I guess using ambiguous terms like "smart" and "dumb" is the downfall of this article. You could replace them with "good developer" and "bad developer" for whichever definition of good and bad you choose (which will vary for person). From your description, I don't consider smart to do some big upfront design and release a system in 2 years; in fact I'd consider that very dumb instead. In that context dumb would be to go ahead with the first solution that comes to your mind rather than looking at 2-3 solutions, compare them, possibly PoC and measure them (if possible) and then make an informed choice including other's input (depending on the scale of the project).

toss1 3y ago

This is why you should apply the Dumb&Fast approach for a first ~MVP version, plan to throw it away, then apply the smart & careful approach for the more durable versions. The first version should get out there quickly and validate, adjust, and/or destroy your assumptions about your customers, systems, usage & load patterns, etc., then that deeper knowledge and more careful approach goes into the next 'real' version. Prevents premature scaling & optimization, and you never have to pay the tech debt from the 1st version. Source: been there, done that, works great.

angarg12 3y ago

I guess using ambiguous terms like "smart" and "dumb" is the downfall of this article. You could replace them with "good developer" and "bad developer" for whichever definition of good and bad you choose (which will vary for person). From your description, I don't consider smart to do some big upfront design and release a system in 2 years; in fact I'd consider that very dumb instead. In that context dumb would be to go ahead with the first solution that comes to your mind rather than looking at 2-3 solutions, compare them, possibly PoC and measure them (if possible) and then make an informed choice including other's input (depending on the scale of the project).