4 ms·

That's exactly the point. Sure you have "control" but what good is all that control if it takes you 4 hours to track down the source of a problem and fix it (fo

That's exactly the point. Sure you have "control" but what good is all that control if it takes you 4 hours to track down the source of a problem and fix it (for example). Github has 100s of engineers (with heavily specialized knowledge that you don't have btw) working to fix any problems, I'd bet on them over myself and (maybe a handful of engineers) everytime ... and I've run my own subversion/git servers before. Some folks just hate the feeling of not knowing what's happening and how long its going to take to fix, vs having direct access to work on problems themselves even though its not necessarily "better" in any sense of the word ... hence the illusion

vbernat 9y ago
100s of engineers working on an outage is a mess. It is more likely you have a handful of them on a given outage.
amelius 9y ago
Yes, but problems are more likely to occur when engineers alter the system in some way. Now if you are in control, you can decide about windows of time in which you don't want something bad to happen (which is of course a reduced probability, not an absolute guarantee, but still the point stands).
onikolas 9y ago
Bad analogy time: Its like flying. You don't have control but your are better off without it (unless you are a pilot of course).
forgottenpass 9y ago
Your post gets to the false tradeoff that turned "devops" from a push for better interdisciplinary collaboration into a "2 jobs, 1 paycheck" role. Software teams are often pathologically unable to create a deliverable that is scrutable and manageable by an operations audience. Building a product that can stand on it's own two feat without constant minding is work. For all the testing dogma that files around, constant delivery has resulted in systems that are more brittle than ever. If someone with all the institutional knowledge is always there to catch the system when it fails, why bother making it easy to investigate failures? Why bother with analysis and building in fault tolerance when someone can worry about a long term solution for that failure mode when it causes them to get paged at 3 am? So it becomes easy to say minders are necessary, and they must be developers. Business incentives mean that answer isn't always scrutinized as heavily as it should be, because it means spreading maintenance costs over time instead of an upfront investment in resilience and maintainability. Refusing to provide a toolset and manual for maintenance means some nobody with access to google can't fix 99% of the problems that could occur. That way the magic black box creators can ensure they're the ones getting paid to do it. We don't have or need Windows engineers, kernel engineers, or Cisco engineers on call. Nor do we have nginx, postgres, cpython, exim, apache, php, mysql, Active Directory, Exchange or Office engineers on call. We use weird enterprise software from companies that have gone out of business, we don't have high-priority support contracts with many of the rest. Software that needs minding from the developers is just bad software. That's technical debt they took on to get the product out the door.

vbernat 9y ago

100s of engineers working on an outage is a mess. It is more likely you have a handful of them on a given outage.

amelius 9y ago

Yes, but problems are more likely to occur when engineers alter the system in some way. Now if you are in control, you can decide about windows of time in which you don't want something bad to happen (which is of course a reduced probability, not an absolute guarantee, but still the point stands).

onikolas 9y ago

Bad analogy time: Its like flying. You don't have control but your are better off without it (unless you are a pilot of course).

forgottenpass 9y ago

Your post gets to the false tradeoff that turned "devops" from a push for better interdisciplinary collaboration into a "2 jobs, 1 paycheck" role. Software teams are often pathologically unable to create a deliverable that is scrutable and manageable by an operations audience. Building a product that can stand on it's own two feat without constant minding is work. For all the testing dogma that files around, constant delivery has resulted in systems that are more brittle than ever. If someone with all the institutional knowledge is always there to catch the system when it fails, why bother making it easy to investigate failures? Why bother with analysis and building in fault tolerance when someone can worry about a long term solution for that failure mode when it causes them to get paged at 3 am? So it becomes easy to say minders are necessary, and they must be developers. Business incentives mean that answer isn't always scrutinized as heavily as it should be, because it means spreading maintenance costs over time instead of an upfront investment in resilience and maintainability. Refusing to provide a toolset and manual for maintenance means some nobody with access to google can't fix 99% of the problems that could occur. That way the magic black box creators can ensure they're the ones getting paid to do it. We don't have or need Windows engineers, kernel engineers, or Cisco engineers on call. Nor do we have nginx, postgres, cpython, exim, apache, php, mysql, Active Directory, Exchange or Office engineers on call. We use weird enterprise software from companies that have gone out of business, we don't have high-priority support contracts with many of the rest. Software that needs minding from the developers is just bad software. That's technical debt they took on to get the product out the door.