3 ms·

This. I once had a conversation with someone who started an open source project about the "10K meter" view. I strongly encouraged secure defaults. He asserted

by __jal 10y ago

This. I once had a conversation with someone who started an open source project about the "10K meter" view. I strongly encouraged secure defaults. He asserted that when getting started, grabbing mindshare requires insecure-out-of-the-box. They could fix that later. Later never came; the project died (Not due to security). But I'm pretty sure something like this would have happened if it had taken off, because later doesn't come until something like this happens. I don't know how wide-spread this thinking is, but it slots in well with a lot of the decisions I see made by other startup types. There seems to be a lot of conventional wisdom about the slimy-ish shortcuts and deceptions, bad design decisions, and so on that are "OK" to make to get off the ground. I'm not going to comment on the necessity of that sort of bad behavior from a business context; I think the answer is complex, and kind of appalling. But on the engineering side, it seems to usually lead to nasty things coming back to bite you, and it is notable that it does so after you've gotten attention and people depend on you.

hinkley 10y ago
I still think the XP guys had this figured out. You scale with your customers and stop trying to write it perfect the first time. I'm a huge proponent of never making the same mistake twice but there is just not enough time in the day for perfect. Instead you write it in a way that it has the potential to be great. Customers that have been using your software for a year will have different problems when they have been using it for four. On one project we essentially had a goal of doubling our data capacity of our (on premises) software every year to stay ahead of our customers' data collection rate. So my goal was 10% per month. We kept on that treadmill for over two years. Yes a couple of those months involves some pretty deep changes to get to a better info architecture. But most of it was constant application of the campsite rule. That said, in that same project we added security and permissions after the fact, and it was one of the most frustrating things I've ever done. A constant and unending stream of bad news from QA about some other spot we missed.
- aclsid 10y ago
  Sounds a lot like translating a web app after it was released. In a company I was working on, we made a commitment to call out strings without gettext as a bug, regardless if it was really was going to be used for a single country/language. It really takes no effort to do it the first time, but adding that stuff later on is major bs.
  - hinkley 10y ago
    Oh, we did that too (and somehow I ended up being in charge of both. Whoopie!) But I decided to cut myself off at two sob stories :) Security, concurrency, and localization are three things you can't just tack on later. Anyone 'test infected' would add automated testing to that list too. They all involve a long game of whack-a-mole and they're IME bad for morale and productivity.
  - hinkley 10y ago
    I've found that you can grease the wheels a lot by explaining to management that using the localization features of the language means that stories don't get held up by arguments about terminology. That's been sufficient to get them to agree to localization on three products, two of which almost immediately got surprise customers (or new owners) for our "always english only" application that suddenly wanted it in 3 languages in 3 months. :/ But for now, if I use this technique in the code, and you business guys want to start calling files 'assets', or clients 'customers' (or vice versa), then you guys can go fight it out in a room and just tell me what you want afterward.
  - Pxtl 10y ago
    The reason it's hard to bolt-on after the fact is that languages conflate the concept of "string" and "user-facing text". If "user-facing text" had a different type or method or whatever, it would be trivial to find all references in your codebase and consolidate them into gettext stuff. But instead, every inline dynamic sql, every dictionary key, every http parsing looks like user-facing text.
Bluestrike2 10y ago
It's really, really easy to pass things off for later and then lose track of them. What's worse is that, once some task is "lost," it's even easier to assume that it's already been completed. And when that happens, we can completely block it off from thought as we concentrate on other tasks unless some external stimulus causes us to think about it again. It's not a perfect comparison, but there are some similarities to the tragic cases of children being left in hot cars in the summer. Dozens each year, largely by parents who aren't abusive, neglectful, or what most would consider to be "bad parents."[0] Instead, it's what's called a prospective memory failure: habitual memory processes override prospective memory, which by its very nature involves additional cognitive mechanisms. There are a couple of PM theories, but the multi-process model suggests that PM cues can trigger a prospective intention even without an active monitoring process. Miss or interrupt the cue, and the intention isn't retrieved and followed through on. Failures such as airplane crashes when pre-flight tasks are interrupted and tasks are missed,[2] fatal anesthesia incidents,[3], fires because gas appliances were left on, etc. A number of industries have been putting more effort into hedging against PM failures over the past few years through better checklists and other aids and precautions precisely because the consequences can be so tragic. Getting back to the topic at hand, the issue with dumb shortcuts like insecure defaults isn't that they're bad on their own but that the way our brains work makes it less likely that we'll go back and fix all aspects of those shortcuts later before a problem arises. Documenting your shortcuts, setting reminders, and other actions can help minimize that likelihood, but how likely is it that you'll do so when you're in the middle of taking an ill-advised shortcut in the first place? At that point, you might as well spend the time to do it right. It's the same danger that comes with hotfixes. Even when you have no other choice, you've put yourself in a position that could have unseen danger later on. Having a policy in place (checklists?) for dealing with something like that can help you avoid PM failures by forcing you to go back and retroactively apply your normal procedures to the patch in question. Style guides and other guidelines help as well in everyday circumstances, even though they can be a bit annoying at times. Because no matter how you look at it, mistakes will be made. Insecure defaults and stupid shortcuts make it more likely by stacking the deck against the people working on a project. 0. http://www.cnn.com/2016/07/25/health/hot-car-deaths-explained/ http://www.cnn.com/2016/07/25/health/hot-car-deaths-explaine... 1. http://www.psych.wustl.edu/learning/McDaniel_Lab/Prospective_Memory.html http://www.psych.wustl.edu/learning/McDaniel_Lab/Prospective... 2. http://www.psychologicalscience.org/news/releases/when-we-forget-to-remember-failures-in-prospective-memory-range-from-annoying-to-lethal.html http://www.psychologicalscience.org/news/releases/when-we-fo... 3. http://anesthesiology.duke.edu/?page_id=826043 http://anesthesiology.duke.edu/?page_id=826043

by __jal 10y ago

hinkley 10y ago

I still think the XP guys had this figured out. You scale with your customers and stop trying to write it perfect the first time. I'm a huge proponent of never making the same mistake twice but there is just not enough time in the day for perfect. Instead you write it in a way that it has the potential to be great. Customers that have been using your software for a year will have different problems when they have been using it for four. On one project we essentially had a goal of doubling our data capacity of our (on premises) software every year to stay ahead of our customers' data collection rate. So my goal was 10% per month. We kept on that treadmill for over two years. Yes a couple of those months involves some pretty deep changes to get to a better info architecture. But most of it was constant application of the campsite rule. That said, in that same project we added security and permissions after the fact, and it was one of the most frustrating things I've ever done. A constant and unending stream of bad news from QA about some other spot we missed.

aclsid 10y ago
Sounds a lot like translating a web app after it was released. In a company I was working on, we made a commitment to call out strings without gettext as a bug, regardless if it was really was going to be used for a single country/language. It really takes no effort to do it the first time, but adding that stuff later on is major bs.
- hinkley 10y ago
  Oh, we did that too (and somehow I ended up being in charge of both. Whoopie!) But I decided to cut myself off at two sob stories :) Security, concurrency, and localization are three things you can't just tack on later. Anyone 'test infected' would add automated testing to that list too. They all involve a long game of whack-a-mole and they're IME bad for morale and productivity.
- hinkley 10y ago
  I've found that you can grease the wheels a lot by explaining to management that using the localization features of the language means that stories don't get held up by arguments about terminology. That's been sufficient to get them to agree to localization on three products, two of which almost immediately got surprise customers (or new owners) for our "always english only" application that suddenly wanted it in 3 languages in 3 months. :/ But for now, if I use this technique in the code, and you business guys want to start calling files 'assets', or clients 'customers' (or vice versa), then you guys can go fight it out in a room and just tell me what you want afterward.
- Pxtl 10y ago
  The reason it's hard to bolt-on after the fact is that languages conflate the concept of "string" and "user-facing text". If "user-facing text" had a different type or method or whatever, it would be trivial to find all references in your codebase and consolidate them into gettext stuff. But instead, every inline dynamic sql, every dictionary key, every http parsing looks like user-facing text.

Bluestrike2 10y ago

It's really, really easy to pass things off for later and then lose track of them. What's worse is that, once some task is "lost," it's even easier to assume that it's already been completed. And when that happens, we can completely block it off from thought as we concentrate on other tasks unless some external stimulus causes us to think about it again. It's not a perfect comparison, but there are some similarities to the tragic cases of children being left in hot cars in the summer. Dozens each year, largely by parents who aren't abusive, neglectful, or what most would consider to be "bad parents."[0] Instead, it's what's called a prospective memory failure: habitual memory processes override prospective memory, which by its very nature involves additional cognitive mechanisms. There are a couple of PM theories, but the multi-process model suggests that PM cues can trigger a prospective intention even without an active monitoring process. Miss or interrupt the cue, and the intention isn't retrieved and followed through on. Failures such as airplane crashes when pre-flight tasks are interrupted and tasks are missed,[2] fatal anesthesia incidents,[3], fires because gas appliances were left on, etc. A number of industries have been putting more effort into hedging against PM failures over the past few years through better checklists and other aids and precautions precisely because the consequences can be so tragic. Getting back to the topic at hand, the issue with dumb shortcuts like insecure defaults isn't that they're bad on their own but that the way our brains work makes it less likely that we'll go back and fix all aspects of those shortcuts later before a problem arises. Documenting your shortcuts, setting reminders, and other actions can help minimize that likelihood, but how likely is it that you'll do so when you're in the middle of taking an ill-advised shortcut in the first place? At that point, you might as well spend the time to do it right. It's the same danger that comes with hotfixes. Even when you have no other choice, you've put yourself in a position that could have unseen danger later on. Having a policy in place (checklists?) for dealing with something like that can help you avoid PM failures by forcing you to go back and retroactively apply your normal procedures to the patch in question. Style guides and other guidelines help as well in everyday circumstances, even though they can be a bit annoying at times. Because no matter how you look at it, mistakes will be made. Insecure defaults and stupid shortcuts make it more likely by stacking the deck against the people working on a project. 0. http://www.cnn.com/2016/07/25/health/hot-car-deaths-explained/ http://www.cnn.com/2016/07/25/health/hot-car-deaths-explaine... 1. http://www.psych.wustl.edu/learning/McDaniel_Lab/Prospective_Memory.html http://www.psych.wustl.edu/learning/McDaniel_Lab/Prospective... 2. http://www.psychologicalscience.org/news/releases/when-we-forget-to-remember-failures-in-prospective-memory-range-from-annoying-to-lethal.html http://www.psychologicalscience.org/news/releases/when-we-fo... 3. http://anesthesiology.duke.edu/?page_id=826043 http://anesthesiology.duke.edu/?page_id=826043