4 ms·

> There is a whole lot of time before your first customer where you don't need any of this. No, there really isn't. Customers want features, and they want it u

by rualca 6y ago

> There is a whole lot of time before your first customer where you don't need any of this. No, there really isn't. Customers want features, and they want it unrolled as fast as possible. How do you provide that? By automating your delivery process. You don't treat your infrastructure as a pet, and all you need to do to get a feature to all customers, fully tested and verified it won't break your service, is to push a commit. With modern CICD systems and a basic Kubernetes setup, you get a fully working continuous deployment pipeline from scratch in about 15 minutes. There is no excuse. The blog post is bullshit from someone who has zero insight and no relevant experience.

tpxl 6y ago
(I am not commenting on the article, I am commenting on the comment thread) > Customers want features, and they want it unrolled as fast as possible. I am going to reiterate: There is a whole lot of time _before_ your first customer. Now I agree with you, on my last job we had no CICD, no tests and no procedures when I joined and it is _hell_ to release anything. Writing tests and doing the infra candy improved our velocity, even though technically we were doing more work. But this was _with_ customers. If you don't have customers, they don't care about the features.
- rualca 6y ago
  > I am going to reiterate: There is a whole lot of time _before_ your first customer. So what? Don't you understand that this just renders your point even less defendable? > But this was _with_ customers. So what? Do you expect to get your code to work only in prod? Do you hope that all the bugs you're adding right now should just pile up into a big tangled and unmanageable mess until it becomes a problem? Are you even bothered by the fact that your last commit may or may not have screwed the entire project? There is absolutely zero justification to not automate testing and delivery. Zero. There is not a single usecases where pushing half-baked crashers without any verification should be ok.
  - deleted 6y ago
    [deleted]

by rualca 6y ago

tpxl 6y ago

(I am not commenting on the article, I am commenting on the comment thread) > Customers want features, and they want it unrolled as fast as possible. I am going to reiterate: There is a whole lot of time _before_ your first customer. Now I agree with you, on my last job we had no CICD, no tests and no procedures when I joined and it is _hell_ to release anything. Writing tests and doing the infra candy improved our velocity, even though technically we were doing more work. But this was _with_ customers. If you don't have customers, they don't care about the features.

rualca 6y ago
> I am going to reiterate: There is a whole lot of time _before_ your first customer. So what? Don't you understand that this just renders your point even less defendable? > But this was _with_ customers. So what? Do you expect to get your code to work only in prod? Do you hope that all the bugs you're adding right now should just pile up into a big tangled and unmanageable mess until it becomes a problem? Are you even bothered by the fact that your last commit may or may not have screwed the entire project? There is absolutely zero justification to not automate testing and delivery. Zero. There is not a single usecases where pushing half-baked crashers without any verification should be ok.
- deleted 6y ago
  [deleted]