3 ms·

TL;DR — Process bad, automation good. I agree with half of that. The problem in the article is that the example team didn't "pop the why stack" enough. "Engin

TL;DR — Process bad, automation good. I agree with half of that. The problem in the article is that the example team didn't "pop the why stack" enough. "Engineer screws up a deploy. Why? <insert wrong command, lazy practice, knowledge gap, etc here> Ok, let's automate all the things!" Automation is great—its not an incorrect response to reduce the surface area for what can result in an error. but automation in turn depends on another process. Continuous deployment? Great idea—but it depends on your tests. How do we know your tests are good? Code review! Another great idea—but also its a process. Process isn't bad. Being a slave to process is bad. So is being a slave to automation. What happens to your continuous deployment when the new guy throws up a server to spike something (creating a snowflake) and it accidentally gets put into rotation for deployment as an app server, which now fails on it? process is fine. it allows automation. use both intelligently.

greenyoda 13y ago
Also, this article is limited to web-deployed applications - "deployment happens with the latest good build every so often" - which is the simplest possible deployment scenario. When you're not in the web-based world, your customers decide when and if to upgrade on their own schedules; there are beta test cycles; there are maintenance releases and hotfixes, each with its own branch in version control. Management is involved in deciding whether Release 23.07 should be delayed because big customer X found a bug. If you don't have a process to keep this stuff flowing smoothly, it just doesn't work. Sure, large parts of it can be automated, but the rest relies on lots of big and little decisions made by people.
- dclusin 13y ago
  I agree that the author has a webcentric view or experience gained primarily from web development. For most web apps the cost of an individual failure is essentially zero. In that sort of scenario tolerance of bugs is much higher so you can get away with playing fast and loose with process. If you look at industries where the result of a software failure is someone getting killed[1] then you will find lots of process. This process isn't there just for the sake of having process. It saves lives. 1. http://en.wikipedia.org/wiki/Therac-25 http://en.wikipedia.org/wiki/Therac-25
  - greenyoda 13y ago
    You don't even need to go as far as software that can kill people to find examples where bugs can be very expensive. A failure (wrong data, system down, etc.) in any software that a company depends on to operate its business can be very expensive to the company (e.g., a hotel can't take reservations for an extended period of time during a busy week, or a supplier sends a million-dollar piece of equipment to the wrong country). And it can also be very expensive for the software provider if their customer ditches them for a competitor's product.

greenyoda 13y ago

Also, this article is limited to web-deployed applications - "deployment happens with the latest good build every so often" - which is the simplest possible deployment scenario. When you're not in the web-based world, your customers decide when and if to upgrade on their own schedules; there are beta test cycles; there are maintenance releases and hotfixes, each with its own branch in version control. Management is involved in deciding whether Release 23.07 should be delayed because big customer X found a bug. If you don't have a process to keep this stuff flowing smoothly, it just doesn't work. Sure, large parts of it can be automated, but the rest relies on lots of big and little decisions made by people.

dclusin 13y ago
I agree that the author has a webcentric view or experience gained primarily from web development. For most web apps the cost of an individual failure is essentially zero. In that sort of scenario tolerance of bugs is much higher so you can get away with playing fast and loose with process. If you look at industries where the result of a software failure is someone getting killed[1] then you will find lots of process. This process isn't there just for the sake of having process. It saves lives. 1. http://en.wikipedia.org/wiki/Therac-25 http://en.wikipedia.org/wiki/Therac-25
- greenyoda 13y ago
  You don't even need to go as far as software that can kill people to find examples where bugs can be very expensive. A failure (wrong data, system down, etc.) in any software that a company depends on to operate its business can be very expensive to the company (e.g., a hotel can't take reservations for an extended period of time during a busy week, or a supplier sends a million-dollar piece of equipment to the wrong country). And it can also be very expensive for the software provider if their customer ditches them for a competitor's product.