3 ms·

A common response on this thread has been that if you take away SSH, you can't log into individual machines to debug. But you know the other situation where you

A common response on this thread has been that if you take away SSH, you can't log into individual machines to debug. But you know the other situation where you can't do that? When your software is running on your users' machines rather than yours, i.e. mobile and desktop apps. I agree with the position of the OP, that it's better to make the software robust by design and through testing.

icebraining 11y ago
it's better to make the software robust by design and through testing. But that's a false dichotomy; having SSH in no way prevents you from designing and testing your software just as well.
- juliangregorian 11y ago
  I don't know, I think there's a legitimate argument to be made that some tools can become a crutch and a detriment. At one of my consults all the developers lean heavily on IDE debugging at the expense of developing well-defined contracts and interfaces. Nobody blinks twice at having a ton of threads mutating global variables because they have all these great debugging and tracing tools.
breischl 11y ago
If you're unable to debug due to the nature of your software then that sucks but it's life. And notice that lot of devs in that situation try to fix it with various remote debugging tools. The article seems to advocate putting yourself into that situation when you don't have to, which is silly.
- mwcampbell 11y ago
  The hard reality of no remote debugging in software deployed to end-user machines leads a wise developer to make potentially inconvenient trade-offs to compensate, e.g. reducing the chance of failure by minimizing dynamism. I believe, and I think the OP would agree, that applying the same discipline to server-side software leads to more robust applications, whereas if you know you have the crutch of remote debugging (via SSH or otherwise) when something goes wrong, you may well be more lax about preventing failures in the first place.
  - breischl 11y ago
    So the idea is to force yourself to make completely unnecessary and "potentially inconvenient trade-offs"? A wise developer should use an appropriate level of robustness without tying one hand behind his own back. And when something unexpected goes wrong anyway it's going to be great when a problem that might've taken an hour to diagnose instead takes two weeks, because SSH is a crutch.
ebiester 11y ago
And if you are well funded, that may not be an issue. However, many people don't live in a world where they can afford to build the tools needed before they determine the viability of their product.

icebraining 11y ago

it's better to make the software robust by design and through testing. But that's a false dichotomy; having SSH in no way prevents you from designing and testing your software just as well.

juliangregorian 11y ago
I don't know, I think there's a legitimate argument to be made that some tools can become a crutch and a detriment. At one of my consults all the developers lean heavily on IDE debugging at the expense of developing well-defined contracts and interfaces. Nobody blinks twice at having a ton of threads mutating global variables because they have all these great debugging and tracing tools.

breischl 11y ago

If you're unable to debug due to the nature of your software then that sucks but it's life. And notice that lot of devs in that situation try to fix it with various remote debugging tools. The article seems to advocate putting yourself into that situation when you don't have to, which is silly.

mwcampbell 11y ago
The hard reality of no remote debugging in software deployed to end-user machines leads a wise developer to make potentially inconvenient trade-offs to compensate, e.g. reducing the chance of failure by minimizing dynamism. I believe, and I think the OP would agree, that applying the same discipline to server-side software leads to more robust applications, whereas if you know you have the crutch of remote debugging (via SSH or otherwise) when something goes wrong, you may well be more lax about preventing failures in the first place.
- breischl 11y ago
  So the idea is to force yourself to make completely unnecessary and "potentially inconvenient trade-offs"? A wise developer should use an appropriate level of robustness without tying one hand behind his own back. And when something unexpected goes wrong anyway it's going to be great when a problem that might've taken an hour to diagnose instead takes two weeks, because SSH is a crutch.

ebiester 11y ago

And if you are well funded, that may not be an issue. However, many people don't live in a world where they can afford to build the tools needed before they determine the viability of their product.