Tag: software engineering

move fast & break nothing

An interesting talk by GitHubber Zach Holman on code, teams and process – “move fast & break nothing“.  It covers everything from DO’s and DONT’s, tools, and even Blue Angels jet fighter flying squad.   (Check the link above for slides and transcript, if video is not your thing).

https://www.youtube.com/watch?v=l288f7oMCEU

 

Flexible Feature Control at Instagram

Instagram

“Flexible Feature Control at Instagram” article describes how Instagram controls the release of new features to groups of users.

I’ve implemented a very simple feature control mechanism before, but nothing to the sounds of this one.  Rolling out to groups of users, conditional control, geo-tagging, and more.  On top of it, non-technical users seem to be able to use for tuning the groups.  This sounds quite impressive, especially when you think of the Instagram’s user base (400,000,000+ users).

How Complex Systems Fail

How Complex Systems Fail – a very concise, yet complete paper on how complex systems fail.  It’s not system or industry specific.  Here are just the bullet points:

  1. Complex systems are intrinsically hazardous systems.
  2. Complex systems are heavily and successfully defended against failure.
  3. Catastrophe requires multiple failures – single point failures are not enough…
  4. Complex systems contain changing mixtures of failures latent within them.
  5. Complex systems run in degraded mode.
  6. Catastrophe is always just around the corner.
  7. Post-accident attribution accident to a ‘root cause’ is fundamentally wrong.
  8. Hindsight biases post-accident assessments of human performance.
  9. Human operators have dual roles: as producers & as defenders against failure.
  10. All practitioner actions are gambles.
  11. Actions at the sharp end resolve all ambiguity.
  12. Human practitioners are the adaptable element of complex systems.
  13. Human expertise in complex systems is constantly changing.
  14. Change introduces new forms of failure.
  15. Views of ’cause’ limit the effectiveness of defenses against future events.
  16. Safety is a characteristic of systems and not of their components.
  17. People continuously create safety.
  18. Failure free operations require experience with failure.

 

Alex Stamos : AppSec is Eating Security

I’m throwing this into the pile of arguments for “security and privacy are little but myths” discussions.  If top of the top companies, with multi-million budgets and hundreds or thousands of top security professionals get compromised, how realistic is it for the average Joe to protect his business?  I say – not very.

I think 80% of problems can be prevented with the 20% time and effort investment: minimize attack surface by removing and disabling everything you don’t need or use and limiting access to everything else, use layered defense where possible, use encryption where possible and strong passwords if you have to, don’t rely on security through obscurity, have log analyzers and/or intrusion detection system installed, etc.  But most importantly, make peace with the fact that being compromised is not the question of “if”, but “when”.  Prepare yourself.  Have an offsite backup and know how to restore your services in a completely new environment, if necessary.

And as far as your privacy goes, if you put anything private on the Internet, as well, prepare for it to be stolen and leaked.  If it never happens, consider yourself lucky.  Otherwise, just learn to deal with it.  It’s very unpleasant in a variety of ways, but seldom deadly.

Via EtherealMind.