3 ms·

"I didn't need it so you don't either. Look at how easy it is to claim everyone else is over complicating things because I didn't have a need for it!" Is essen

"I didn't need it so you don't either. Look at how easy it is to claim everyone else is over complicating things because I didn't have a need for it!" Is essentially the TL;DR of that article. Being dismissive while not really substantially expounding on the faults of other processes is just bland contrarianism. Bald assertions need only be met with bald assertions. Allow me to write a retort: You do need all of that infrastructure and you should spend even more time making sure your pipelines are a well oiled machine to reduce deployment fears and establish confidence in your infrastructure. Make it nice to use. That new tool that came out? It was written for a reason, and is probably tackling a problem you weren't even aware you'd be facing. So stick it in and call it a day with the knowledge that you've avoided spending time on a problem someone else has already solved. Your turn, cynical blog person.

coleca 8y ago
This ^^ I've seen / worked with a number of startups that used the author's advice and just had a simple setup "that worked". Until it didn't. Here's how it typically plays out: Our "dev" setup "the server" for us at <AWS/GCP/DO/Linode/etc> and everything worked fine until the provider restarted the server, or an OS upgrade happened, or we fired the dev we found on Upwork and he shut down the server. Now X doesn't work. We don't know how to reproduce what he did. Now you are left with trying to go through someone else's bash history and decipher what steps they used to build the server. Did they forget to tell a service to autorun? Who knows. I agree with OP that it's possible to over-engineer a fancy CI / CD pipeline and matching infrastructure for a founder that just has an idea and zero users when you should be getting product/market fit, esp. when you just have one developer working on the system. However, the opposite is also true. It's possible to under-engineer the infrastructure where developer productivity is dramatically slowed when you're spending a significant amount of your dev's time doing deploys and blocking other work from happening at the same time. This can happen fast when you hire dev #2 and #3. This isn't even getting into the perils around security and scaling when you play fast and loose with the infrastructure side of the house.
danellis 8y ago
I've seen three articles just like this in the past week. I don't know why people dignify them by posting them here. It seems like being deliberately contrarian as a substitute for actual nuanced reasoning based on experience is a good way to get exposure.

coleca 8y ago

This ^^ I've seen / worked with a number of startups that used the author's advice and just had a simple setup "that worked". Until it didn't. Here's how it typically plays out: Our "dev" setup "the server" for us at <AWS/GCP/DO/Linode/etc> and everything worked fine until the provider restarted the server, or an OS upgrade happened, or we fired the dev we found on Upwork and he shut down the server. Now X doesn't work. We don't know how to reproduce what he did. Now you are left with trying to go through someone else's bash history and decipher what steps they used to build the server. Did they forget to tell a service to autorun? Who knows. I agree with OP that it's possible to over-engineer a fancy CI / CD pipeline and matching infrastructure for a founder that just has an idea and zero users when you should be getting product/market fit, esp. when you just have one developer working on the system. However, the opposite is also true. It's possible to under-engineer the infrastructure where developer productivity is dramatically slowed when you're spending a significant amount of your dev's time doing deploys and blocking other work from happening at the same time. This can happen fast when you hire dev #2 and #3. This isn't even getting into the perils around security and scaling when you play fast and loose with the infrastructure side of the house.

danellis 8y ago

I've seen three articles just like this in the past week. I don't know why people dignify them by posting them here. It seems like being deliberately contrarian as a substitute for actual nuanced reasoning based on experience is a good way to get exposure.