Learning by Doing / over / wishful thinking

Anneli (Typography in \TeX perhaps)

incident post-mortems are the technical debt of operations

Hamid

Visual Studio supports Application Insights. This provides an mechanism to add monitoring support into a web application. There's also a version for Azure.

Application Insights lets you monitor your live application for: Availability - We'll test your URLs every few minutes from around the world. Performance - Detect and diagnose perf issues and exceptions. * Usage - Find out what users are doing with your app, so that you can make it better for them.

There's no recycling bandwidth

Hamid

How Complex Systems Fail Richard Cook, University of Chicago.

Articulation of the steps that contribute to failure by the nature of complex systems. Focused on systems such as transport, health care, and power generation, with a corresponding implicit view of the hazardous nature of those systems.

When reading for software engineering I transposed bugs for accidents and quality for safety.

Quotes & Takeaways

• By their nature complex systems are broken systems.
• Catastrophic failures occur because of combinations of failures. Individually, those failures are seen as normal and the complex system has developed various mechanisms of mitigating them in normal operation.
• ∴ there is no root cause
• Hindsight bias is a significant hindrance → "hindsight bias remains the primary obstacle to accident investigation
• Safety (quality) "is an emergent property of systems" (not components in systems).
• "More robust system performance is likely to arise in systems where operators can discern the “edge of the envelope”" — i.e. you need experience of what happens on the wrong side of the line to operate effectively on the right side of the line. Given that complex systems are ever changing (including the people and experience within them) this implies that any software engineering organizations effectiveness will be cyclical and that we should ∴ plan for that.

For software development I found Cook's #11 fascinating:

Organizations are ambiguous, often intentionally, about the relationship between production targets, efficient use of resources, economy and costs of operations, and acceptable risks of low and high consequence accidents. All ambiguity is resolved by actions of practitioners at the sharp end of the system. After an accident, practitioner actions may be regarded as ‘errors’ or ‘violations’ but these evaluations are heavily biased by hindsight and ignore the other driving forces, especially production pressure.

In a HN thread on editors (Lighttable and that teams plans to do stuff with Eve) someone mentioned Brackets in the context of installed and haven't looked back since. Right now I'm happy with Sublime...

...but you never know.

I saw a BSOD today, oh boy, first in a while.

1. Grab WinDBG(x64) — install the Windows Software Development Kit (from here for 8.1) and select the debugging tools in the installer.
2. Launch WinDbgx64
3. Set the Symbol Search Path to SRV*C:\Windows\symbol_cache*http://msdl.microsoft.com/download/symbols
4. Save the workspace
5. Load the .dmp file
6. !analyze -v

For a windbg cheat sheet try https://labs.snort.org/awbo/windbg.txt

WinDbg howto and another

For memory related suspicions try memtest for memteat.org — you'll need a bootable something with it on...

For driver relateds suspicions follow the instructions to verify the drivers.

A primer about technical debt, legacy code, big rewrites and ancient wisdom for non-technical managers

PDF of medium post

See also http://blog.ionelmc.ro/2014/08/14/the-three-sins-of-software-development/

Ken Thompson received the ACM Turing Award. It's a BigDeal^TM.

To what extent should one trust a statement that a program is free of Trojan horses? Perhaps it is more important to trust the people who wrote the software

Thompson's paper describes why that is.

Eskimo's (Inuit; ᐃᓄᐃᑦ) have 100s of words for snow. Except they don't. The Eskimo Hoax explains.