4 ms·

I think your sort of thinking requires a certain level of maturity and experience. I see the opposite with with some engineers who always have this illusion tha

I think your sort of thinking requires a certain level of maturity and experience. I see the opposite with with some engineers who always have this illusion that the first or even second version of their project will be the final one for all times so they build it to scale (which actually doesn't even really scale because they don't know where the real bottlenecks are) and highly configurable. I've seen way, way more projects bite the dust because of poor product design or product market fit than the inability to scale. I've definitely seen projects that can't scale but at least from an engineering point of view, those problems are way more tractable than people not wanting or needing what you've created. As I've gotten more experienced, I've realized one of the great skills a good engineer has is the ability to change/fix/scale a project once it is up and running and while people are using it.

bob1029 6y ago
> I've realized one of the great skills a good engineer has is the ability to change/fix/scale a project once it is up and running and while people are using it. This is by far the most important lesson I have learned this decade. Anyone can pull the rug out on iteration 1 and start a completely new attempt in a 2nd iteration bucket. It takes determined engineering efforts and talent to iterate on top of the existing code base while not impacting the ability to deliver ongoing feature support to production. We have historically tried to do complete rewrites with bombastic claims like "We can do it right this time". Well, we did it "right" 3 times until we decided that restarting from zero every time is a bad way to make forward progress. I will advocate for a clean restart if you are just beginning or it is clear you have totally missed the domain model target. If you have been in production for 3 years, maybe consider a more conservative iteration approach. The best analogy I can come up with is the Ship of Theseus thought experiment. Rebuilding the ship from the inside while you are sailing it to the new world will get you there much faster than if you have to restart in Spain every time someone is in a bad mood or doesn't like how the sails on the boat are arranged.

bob1029 6y ago

> I've realized one of the great skills a good engineer has is the ability to change/fix/scale a project once it is up and running and while people are using it. This is by far the most important lesson I have learned this decade. Anyone can pull the rug out on iteration 1 and start a completely new attempt in a 2nd iteration bucket. It takes determined engineering efforts and talent to iterate on top of the existing code base while not impacting the ability to deliver ongoing feature support to production. We have historically tried to do complete rewrites with bombastic claims like "We can do it right this time". Well, we did it "right" 3 times until we decided that restarting from zero every time is a bad way to make forward progress. I will advocate for a clean restart if you are just beginning or it is clear you have totally missed the domain model target. If you have been in production for 3 years, maybe consider a more conservative iteration approach. The best analogy I can come up with is the Ship of Theseus thought experiment. Rebuilding the ship from the inside while you are sailing it to the new world will get you there much faster than if you have to restart in Spain every time someone is in a bad mood or doesn't like how the sails on the boat are arranged.