4 ms·

While I think you can definitely get too fancy with all of that sweet infra, I feel this is missing an important point: Once you have a working pipeline in pla

by m90 8y ago

While I think you can definitely get too fancy with all of that sweet infra, I feel this is missing an important point: Once you have a working pipeline in place, you can focus on the features, that's the whole point of the exercise: enabling developers to ship features for users. If I have to SSH into some machine and restart a set of services manually in the correct order, it will keep me from releasing features. I am afraid / lazy / whatever. Spending time on this is not something that will never ever reach the user in any way. The user does not care if something is using Heroku, K8s, or something else, yes, but the user definitely appreciates a product that can reliably iterate on things without major downtime or similar problems. It's kind of like saying, "well unit tests are nice and stuff, but does the user ever notice?". I would strongly argue the user will notice unit tests in the long run as they ensure the software keeps being maintainable.

afarrell 8y ago
When you walk into a restaurant, do you notice if they have an efficiently laid-out kitchen with mise-en-place, good relationships with their suppliers, or a refrigerator at the proper temperature? No. But you do notice when you food is slow to arrive, the food doesn't taste fresh, or the chicken gives you food poisoning.
ctnaxx 8y ago
But many applications were better around 2002-2004 than now. The only thing that's better now for users who don't care about privacy at all is the opaque sign-in-with-X feature. Email web interfaces got worse, login forms got worse, documentation got worse, search got worse (peaked around 2004).
- m90 8y ago
  Which ones? Which feature?
- ox_cable 8y ago
  I've never seen a more biased, unsubstantiated, "back in my day" comment on HN. Well done. Give specifics if you want to be taken seriously instead of just saying "well, back in my day everything was better".
thomaslangston 8y ago
I think it is also important to remember that users are not the only consumers of a software development pipeline. If developers don't want to work for you because they feel held back in creativity or career progression, support staff have to stay up late for downtime deployments, and managers and/or ownership feel blind to the process, then you can still have a miserable company with happy users. Quality of the work is an important part of a compensation plan. Eventually this hits an organization's bottom line in the form of turnover, employee productivity, etc. In software development with high salary, difficult to recruit employees, this can be significant.
collyw 8y ago
> Once you have a working pipeline in place, you can focus on the features Bullshit, its just another layer of complexity to be managed and that may fail. My guess is that it will take more time maintaining it than it will save you in the majority of cases.
- Aeolun 8y ago
  Given how annoying it is to SSH to a server, check out the code, restart all the relevant services, I think there’s a definite plus to having my system do that for me.
- m90 8y ago
  > My guess is that it will take more time maintaining it than it will save you in the majority of cases. From my experience, this has almost never been the case. Exceptions were when there was infrastructure for the sake of infrastructure.
  - afarrell 8y ago
    If a leader is worried about their organization having infra for the sake of infra, then they should also worry that their user-facing product has features for the sake of features—- features that complicate an interface and don’t help a user get their job done. The solution is PMs, UX designers, and engineers who know to ask “why?” when a project is proposed.
    - davidjnelson 8y ago
      That's a good point. Many things can be overengineered/overdone, including UX design.
- scarface74 8y ago
  If my pipeline fails, it’s likely because of a build issue. I have two types of pipelines both based on AWS: 1. Push code to Github -> AWS CodeBuild spins up a prebuilt or custom Docker container (on a server that I don’t have to manage) to build and run unit tests -> Code Deploy agent runs on EC2 instance that runs a script to deploy website. 2. Same as above but Code Deploy runs a CloudFormation template to deploy/update lambdas and other related resources. The only part of either process that requires me to maintain a server at all is the web server. It takes me about an hour to set up a new pipeline at the most. It’s basically modified a bunch of yaml/JSON files. It’s a one time setup that pays dividends through the whole process. I’ve also used hosted builds with Azure Devops before.
btbuildem 8y ago
This reminds me of those ghost cities in China -- they built it, but nobody came.
philwelch 8y ago
> Once you have a working pipeline in place, you can focus on the features, that's the whole point of the exercise: enabling developers to ship features for users. If I have to SSH into some machine and restart a set of services manually in the correct order, it will keep me from releasing features. A "working pipeline" is an abstraction. Your actual pipeline will still sometimes break or misbehave in unpredictable ways, except now it takes a lot more context to debug and resolve those issues. Which is fine if you have dedicated infrastructure teams working behind the scenes to keep all that stuff stable (Heroku is an entire company that does this) but it's no silver bullet. If you have to SSH into some machine and restart services whenever you release a feature, you will learn how to do that. And in that process, you will have a better idea how to fix it if it breaks and how to design features in an operationally stable way. If you just push to master and let the Machine take it from there, you're living in willful ignorance and are helpless when the Machine inevitably breaks down. And, in the long run, that will have a much greater impact on your feature velocity.

by m90 8y ago

afarrell 8y ago

When you walk into a restaurant, do you notice if they have an efficiently laid-out kitchen with mise-en-place, good relationships with their suppliers, or a refrigerator at the proper temperature? No. But you do notice when you food is slow to arrive, the food doesn't taste fresh, or the chicken gives you food poisoning.

ctnaxx 8y ago

But many applications were better around 2002-2004 than now. The only thing that's better now for users who don't care about privacy at all is the opaque sign-in-with-X feature. Email web interfaces got worse, login forms got worse, documentation got worse, search got worse (peaked around 2004).

m90 8y ago
Which ones? Which feature?
ox_cable 8y ago
I've never seen a more biased, unsubstantiated, "back in my day" comment on HN. Well done. Give specifics if you want to be taken seriously instead of just saying "well, back in my day everything was better".

thomaslangston 8y ago

I think it is also important to remember that users are not the only consumers of a software development pipeline. If developers don't want to work for you because they feel held back in creativity or career progression, support staff have to stay up late for downtime deployments, and managers and/or ownership feel blind to the process, then you can still have a miserable company with happy users. Quality of the work is an important part of a compensation plan. Eventually this hits an organization's bottom line in the form of turnover, employee productivity, etc. In software development with high salary, difficult to recruit employees, this can be significant.

collyw 8y ago

> Once you have a working pipeline in place, you can focus on the features Bullshit, its just another layer of complexity to be managed and that may fail. My guess is that it will take more time maintaining it than it will save you in the majority of cases.

Aeolun 8y ago
Given how annoying it is to SSH to a server, check out the code, restart all the relevant services, I think there’s a definite plus to having my system do that for me.
m90 8y ago
> My guess is that it will take more time maintaining it than it will save you in the majority of cases. From my experience, this has almost never been the case. Exceptions were when there was infrastructure for the sake of infrastructure.
- afarrell 8y ago
  If a leader is worried about their organization having infra for the sake of infra, then they should also worry that their user-facing product has features for the sake of features—- features that complicate an interface and don’t help a user get their job done. The solution is PMs, UX designers, and engineers who know to ask “why?” when a project is proposed.
  - davidjnelson 8y ago
    That's a good point. Many things can be overengineered/overdone, including UX design.
scarface74 8y ago
If my pipeline fails, it’s likely because of a build issue. I have two types of pipelines both based on AWS: 1. Push code to Github -> AWS CodeBuild spins up a prebuilt or custom Docker container (on a server that I don’t have to manage) to build and run unit tests -> Code Deploy agent runs on EC2 instance that runs a script to deploy website. 2. Same as above but Code Deploy runs a CloudFormation template to deploy/update lambdas and other related resources. The only part of either process that requires me to maintain a server at all is the web server. It takes me about an hour to set up a new pipeline at the most. It’s basically modified a bunch of yaml/JSON files. It’s a one time setup that pays dividends through the whole process. I’ve also used hosted builds with Azure Devops before.

btbuildem 8y ago

This reminds me of those ghost cities in China -- they built it, but nobody came.

philwelch 8y ago

> Once you have a working pipeline in place, you can focus on the features, that's the whole point of the exercise: enabling developers to ship features for users. If I have to SSH into some machine and restart a set of services manually in the correct order, it will keep me from releasing features. A "working pipeline" is an abstraction. Your actual pipeline will still sometimes break or misbehave in unpredictable ways, except now it takes a lot more context to debug and resolve those issues. Which is fine if you have dedicated infrastructure teams working behind the scenes to keep all that stuff stable (Heroku is an entire company that does this) but it's no silver bullet. If you have to SSH into some machine and restart services whenever you release a feature, you will learn how to do that. And in that process, you will have a better idea how to fix it if it breaks and how to design features in an operationally stable way. If you just push to master and let the Machine take it from there, you're living in willful ignorance and are helpless when the Machine inevitably breaks down. And, in the long run, that will have a much greater impact on your feature velocity.