The conceptual setting and "world building" framework makes for a very compelling space opera. Far-flung, disconnected civilizations in star systems separated by vast oceans of time and distances are brought back together after millenia with wildly disparate cultures & tech. Unfortunately, the author's story telling, characters, motivations, and the background tech are not great. 3/5 Stars.
Friday, July 22, 2022
Monday, July 4, 2022
Vanity and other Metrics that measure the wrong thing
John Cutter has a new piece out about vanity metrics that's worth skimming. It's a reminder that our cognitive biases and need to boast, brag, and make ourselves look great to "management" can be destructive to our mission and purpose as an enterprise. I have encountered more subtle cognitive biases where our metrics and goals in a business-to-business setting are focused on the use of our free software service instead of the purpose for which our free service is intended. Folks are using our software, yes. But are they getting our joint mission and purpose done better and more efficiently? Software is our means to an end. Customer success is literally our success. Therefore, even if our customers love our software and love using it, if alternatives to our software are better or more efficient, both our customers and we have failed. Focus on what matters.
Labels:
management
InfoSec map is not the Info-Threat territory
We have many recent reminders of the growing, irrational gap between real information security threats and the solutions, regulations, practices, mitigations, and technologies we can and should bring to bear to mitigate these threats. The recent successes and growth of ransomware is one indicator that malware threat mitigation is obviously failing. Personally, I would like to enlist everyone to protect themselves and "crowdsource" aspects of the problem.
Within the Information Security attack / defend landscape, attackers have all possible advantages, including "asymmetric warfare," where a single attacker can easily harm billions of people. Attackers have enormous wealth and resources to create attacks as they are funded and resourced by nation states, wealthy organized criminals, and professionals. For decades, governing entities, regulators, & consortia have written standards, regulations and policies that chase after emerging "cyber" threats, and the trillion-dollar tech giants have tried to protect their own customers by developing anti-malware prevention, defenses, as well as mitigation hardware and software.
#
A wise mentor once told me "Policy is hard. Technology is easy." This wisdom is broadly applicable in many areas of software development and IT: Naming Policy, Data Governance Policies, Algorithm Selection, Object Factoring, and even Design Policy.
One recurring problem I have encountered is the ubiquitous confusion in Information Technology of an abstract requirement, problem, threat, or need versus one or more technological solutions (software products) that try to meet the requirement or solve the problem. IT professionals get caught up in the solution and see their own problems through the lens of some product or product family. It is nearly impossible for me to convince them to separate clearly the probability of a successful attack, the true severity of such an attack, and the resultant risk for our organization. Instead they see our problem through the lens of some specific IT technology that is designed for some other customer in some other situation to mitigate that other organization's risk. This issue is much worse in an organization where estimates of probability multiplied by the severity (risk) varies enormously among the organization's stakeholders and decision makers. After my repeated attempts to help InfoSec folks write artifacts that separate threats from technologies, they always inject some product and some mitigation to risks we do not have and I never prevent it.
So, I plan to "democratize" and crowd source threat mitigation wherever I can.
I shall enlist and empower everyone to help mitigate cyber threats. One method is illustrated by the entire lifecycle of the Russian military's attack on Space-X Starlink consumer internet service in Ukraine. The approach Space-X's took to reacting to the problem is instructional and generalizable. They created, and shipped a mitigation very quickly. But most-importantly the shift in attitude from the USA's department of defense on the attack / defend methods will eventually broaden how nation states and large companies help defend us. When Starlink was jammed in Ukraine, Space-X reacted by calling the issue a "free QA department" that found a bug for Starlink to fix. All of us can take this idea to heart. We should all consider email spam, phishing, ransomware, click bait, and cyber attacks we encounter as training to make us "antifragile" and resistant to more-dangerous and better attacks we shall encounter in the future. The US DoD said that our current checklist-driven approaches are flawed and we must be much more proactive in formulating defense. Education, training, and constant vigilance among everyone is a step in that direction.
Labels:
management
The 5 Dysfunctions of an engineering team
Management concepts like this one deserve frequent reminders. Thank you, Michael, for blogging the link and sharing your own thoughts. Organizations in which I have been a member fall into these patterns of failure from time to time, so recording a reminder here will be useful. The original book when it came out was great and the sequel, "overcoming the 5 dysfunctions of a team" was a great refresher.
#
On a somewhat related note, another set of authors and books worthy of frequent reminders are the Crucial Conversations team who also wrote Influencer. Don't fall into the "serenity trap."
Labels:
management
Sunday, July 3, 2022
Systems Administration & Ops IT is not DevOps
I love rants like this one. All of the points the author makes are well-taken. Just as we re-labeled manual testing "software test engineering" or "quality assurance," so too are we now calling systems administration and data center operations "DevOps," as though the label itself will reap the benefits of true software development and maintenance for better operability.
Labels:
devops
Breaking News von Frank Schätzing
Ich bin sehr enttäuscht, weil Schätzing gut schreibt. Die Handlungsstränge und die Story sind gut ausgearbeitet. Das Buch hat mehrere fatale Mängel: Es gibt keine arabischen Schriftzeichen. Alle berühmten Persönlichkeiten haben deutsche Werte, Kultur und Politik. Das Buch ist historisch ungenau. 1/5 Sterne.
Sunday, June 26, 2022
InfoQ on DevOps Trends 2022
There is not much actionable information in this new publication on InfoQ and the odd fashion trend in 2022 to confuse concepts such as Observability with unrelated technologies (WASM, really?) continues to accelerate. This trend reminds me of the tech venture capitalists' use of buzzwords in 1997. My favorite was "Java Compliant."
Labels:
devops
Saturday, June 25, 2022
reminders about importance, urgency, mindful focus
Michael reminds us that those simple "ringing telephone" urgent-not-important examples from pithy self-help sources are not nearly as useful as thoughtful considerations of "flow," unplanned interruptions, shifting priorities, unknown unknowns, and false precision. The source to which he links covers aspects of urgency we don't normally consider and is also worth reading.
Labels:
management
Thursday, June 23, 2022
Sunday, June 19, 2022
Subscribe to:
Posts (Atom)