2024-06-19

2024-06-19 Wednesday - Researching Approaches to Measuring EA Value

[image credit: aleksandra85foto on pixabay.com]

This post is a placeholder for a collection of selected articles, suggested as background reading...(discovery-in-progress...)

Research Papers

Enterprise architecture management value creation mechanisms (2024)

by  Sofia Tiitinen (Enterprise Architect, SOK)

https://jyx.jyu.fi/handle/123456789/93267

https://jyx.jyu.fi/bitstream/handle/123456789/93267/URN%253ANBN%253Afi%253Ajyu-202402061758.pdf

See: 4.1 Perceived EAM Value
"None of the respondents completely agree with being satisfied with their organization’s current EAM practices. About 70% disagree with the claim"

*** Pages 37-39
See: TABLE 8 Perceived EAM Value

Page-40:
"Overall, of the synthesized constructs of EA Product Quality, EA Service Quality, EA Culture/Attitude, EA Product Use, and EA Service Use, presented in chapter 2.4.4, all were present in EAM value creation."

*** Important, Page-46
5.3 Limitations
"The results do not come without limitations to validity. With 47 respondents, the sample size of the primary research was significantly limited. The total methodology of the study was novel, with certain exploratory features. Thus, the results are advised to be interpreted as preliminary. The great majority of respondents worked in large organizations with over a thousand employees, meaning this demographic is best suited when interpreting the results. It may be that EAM value is more likely to be achieved in the complex environment of a large corporation. Additionally, all but one respondent worked in organizations operating in Finland, meaning the results do not in their large part represent the experiences of professionals working in organizations not operating in Finland. Thus, it can be concluded the results may not represent the complete population of EAM stakeholders."

***
"Another notable limiting factor is difficulty in measuring EAM value due to its typically indirect and/or intangible nature (Kluge, Dietzsch and Rosemann, 2006; Tamm et al., 2011)." 


Towards the Definition of Enterprise Architecture Debts (2019)

By Simon Hacks, Hendrik Höfert, Johannes Salentin, Yoon Chow Yeong, Horst Lichter

"In the software development industry, technical debt is regarded as a critical issue in term of the negative consequences such as increased software development cost, low product quality, decreased maintainability, and slowed progress to the long-term success of developing software. However, despite the vast research contributions in technical debt management for software engineering, the idea of technical debt fails to provide a holistic consideration to include both IT and business aspects. Further, implementing an enterprise architecture (EA) project might not always be a success due to uncertainty and unavailability of resources. Therefore, we relate the consequences of EA implementation failure with a new metaphor --Enterprise Architecture Debt (EA Debt). We anticipate that the accumulation of EA Debt will negatively influence EA quality, also expose the business into risk."
 

Industry Analsyst Research & Advisory Publications

Gartner

 

EA Tool Vendors

LeanIX

  1. Value of Enterprise Architecture

 

Other Papers, Blog Posts, Articles

  1. Capturing Value from Enterprise Architecture: Understand your field of play, solve tough challenges and drive transformational change (2022), by Christian Schröder (Enterprise Technology and Financial Services, Bain & Company)

 

Suggested Books

  1. The Practice of Enterprise Architecture: A Modern Approach to Business and IT Alignment, 2nd Edition (2021), by Svyatoslav Kotusev
    • "Due to complex historical reasons, the notion of enterprise architecture was always surrounded by endless speculations, dangerous myths, non-existing best practices, unfulfilled promises, expensive failures and grave disappointments. Traditionally the entire discourse around enterprise architecture was dominated by shallow advice and faddish approaches (e.g. well-known EA frameworks) infinitely distant from the practical realities, but nonetheless aggressively promoted by commercially motivated consultancies and gurus."
  2.  ...
Posted by No comments:
Labels: , , , ,

2024-05-28

2024-05-28 Tuesday - Proposed Definition for Technical Debt

I posted this answer, in response to a question posed by  Sonya Natanzon, on LinkedIn 

Noteworthy: Sam Holiday, PhD, offered a definition which focuses on the strictly monetary/cost aspects

I've created a poll on LinkedIn that may be of interest.

[source: Kelvin Meeks, LinkedIn poll]

 

 

My proposed definition:


Technical Debt (noun):
1. A consequence of the accrual of one or more intentional trade-off decisions - or the unintentional absence/lapse of governance, oversight, and maintenance.

2. Technical Debt may arise from poor design choices, or exigent decisions, that were contrained by available time, skill, or budget.

3. Over time, Technical Debt may exhibit unexpected secondary aspects - such as brittleness, cascading system failures, security vulnerabilities, degraded performance, incompatibilities, failure to meet regulatory and compliance requirements, etc.

4. Technical Debt is usually a symptom of deeper underlying root causes. 

  • For example: 
    • Absence of governance; 
    • Insufficient budgets for long-term maintenance; 
    • Absence of a technology roadmap; 
    • Absence of necessary-and-sufficient Application Portfolio Management protocols; 
    • Absence of End-of-Life (EOL) management; 
    • Absence of Security protocols for technology management (static code analysis, vulnerability monitoring, vulnerability remediation, etc.); 
    • Absence of Principles, Policies, Standards, Specifications; 
    • Absence of appropriate Enteprise Governance mechanisms (e.g., Technology Governance Board, Technology Reference Model, ...);
    • etc.
  • Consider governance in the context of a forcing-function. In the absence of governance functions (at multiple levels, in multiple dimensions) - there's only the willingness and initiative of the individual. Judicious application of governance - can help ensure a minimal consistency in how some safeguards can be established (and enforced) - to minimize/avoid unconstrained levels of Technical Debt from accumulating.

5. Technical Debt may represent a type of decay that requires remediation.

  • When something is no longer supported, constitutes security vulnerabilities, or is no longer compliant - it becomes a type of technical debt. 

  • Consider if a company selected Java 8, or Windows Server 2008 (at some point in the past), but refused to ever upgrade. Over time, that decision - reflects a type of technical debt (e.g., in which there are consequences, such as: it has security vulnerabilities; it is no longer being actively maintained; security patches are no longer supported, etc.). It isn't a strictly monetary expenditure per month consideration. However, upgrading to a newer version (that is supported) is the technical debt remediation that is required. 
  • Not upgrading to the supported version of [x] - which may have negligable productivity impact - but may expose the company to an incalculable level of fines, penalties, monetary losses, and reputational damages - if there is a security breach tied to a known vulnerability that would have been remediated by upgrading. 

6. Technical Debt, by my definition - is not a purely monetary consideration of ongoing costs - but encompasses a more holistic viewpoint of the consequences of failing to remediate some deficiency with respect to the technical aspects of design or implementation - that is a consequence of actions taken, or actions avoided.


Suggestions, discussion contributions, and other perspectives:

I thank the folks that have participated in the public LinkedIn discussion threads, or granted me permission to share these private exchanges, of their thoughts on the definition of Technical Debt:

  • [a suggested addition, with respect to governance] "...a lack of understanding or practice of risk management- acceptance, avoidance, transference, etc. Unless a proper risk assessment is done, it is difficult to make financial decisions." 
    • Jeff Zygmunt
    • 2024-05-30, private LinkedIn message exchange (shared with his permission)
  • "Current technology or lack of technology that, due to age, negligence, or changes in standards represents the risk of a monetary or opportunity cost."

 

Suggested Background Reading:

Standards:

  1. ISO/IEC 25002:2024 Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — Quality model overview and usage

Articles by others:

(articles in order of expected reading value)

  1. https://en.wikipedia.org/wiki/Technical_debt
  2. https://www.sonarsource.com/learn/technical-debt/ 
  3. Holt Hackney:
    1. 2024-06-13: New Research Suggests Architectural Technical Debt Is Most Damaging to Applications Amid $1.52 Trillion Technical Debt Crisis  (Architecture & Governance Magazine)
      1. Rafalin: "Today’s technical debt reduction measures like code quality and performance observability tools and code vulnerability scans don’t focus on architectural technical debt."
      2. "The research study surveyed more than 1,000 U.S.-based architecture, development and engineering leaders, and practitioners at large enterprises as well as smaller digital-first companies."
      3. https://vfunction.com/resources/report-microservices-monoliths-technical-debt/
  4. McKinsey Digital:
    1. 2020-10-06: Tech debt: Reclaiming tech equity
      •  By Vishal Dalal, Krish Krishnakanthan, Björn Münstermann, and Rob Patenge
  5. Ward Cunningham's c2 wiki
    1. https://wiki.c2.com/?TechnicalDebt
    2. YouTube: Debt Metaphor
  6. Martin Fowler:
    1. Posts tagged: "Technical Debt"
    2. 2009-10-14: Technical Debt Quadrant
    3. 2019-05-21: Technical Debt
  7. Henrik Kniberg: [LinkedIn]
    1. 2013-10-11: Good and Bad Technical Debt (and how TDD helps)
  8. Gerben Wierda: [LinkedIn]
    1. 2018-09-08: Agile, Dirt, and Technical Debt
  9. neopragma: Dave Nicolette
    1. 2019-03-30: Technical Debt: The Man, the Metaphor, the Message
  10. appenwarr.com
    1. 2023-06-05: Tech debt metaphor maximalism 
  11.  Adam Tornhill: [LinkedIn]
    1. YouTube, GOTO 2019: Prioritizing Technical Debt as if Time and Money Matters
      1. Expected watching value: low-medium
      2. Primarly focuses on just the software aspects of Technical Debt 
  12. Georgiana Gligor: [LinkedIn]
    1. Today Software Magazine (Issue #47): Paying Technical Debt: a Top-Down Approach 
  13. Steve McConnell: [LinkedIn]
    1. Managing Technical Debt 
  14. Aaron Erickson:
    1. 2009:10-10: Don't "Enron" Your Software Project
  15. Gene Hughson: 
    1. 2013-11-04: Technical Debt - What it is and what to do about it

Books on Amazon.com  (in descending order of publication year)

  1. Unveiling Tech Debt: A Business Leaders Guide to Measuring and Managing Enterprise Tech Debt Leverage (2024)
    1. Estimated reading value: Very Low?
    2. Of possible note, see Chapter-6 Measuring and Managing Tech Debt, starting on page-70: Quantify Your Tech Debt.
    3. Pages: 88
  2.  Technical Debt Management in software projects using Scrum: An Action Research (2023)
    1. Estimated reading value: Low-Medium
    2. This book's value may primarily be as a bibliography to other works - as it has a copious amount of citations.
    3. Pages: 84
    4. Additional links:
      1. https://www.linkedin.com/in/frederico-zenoglio-de-oliveira/
      2. DOI:10.1109/Agile.2015.7
      3. https://www.semanticscholar.org/paper/Managing-Technical-Debt-in-Software-Projects-Using-Oliveira-Goldman/10e8eaf24a5247526a35211e9c0149370bf2f5e6
      4. https://speakerdeck.com/fredericooliveira/managing-technical-debt-in-software-projects-using-scrum-an-action-research
        1. See last slide, where he offers to send the full paper. 
      5. https://ieeexplore.ieee.org/document/7284597
      6. https://www.researchgate.net/publication/305865096_Managing_Technical_Debt_in_Software_Projects_Using_Scrum_An_Action_Research
      7. https://www.agilealliance.org/resources/research-papers/managing-technical-debt-in-software-projects-using-scrum/
        1. "Because of project time constraints and ease of use, we reduced the use of the proposed metrics to two:" 
          1. "Principal"
          2. "Current Amount of Interest"
  3. Technical Debt in Practice: How to Find It and Fix It (2021)
    1. Estimated reading value: Medium
    2. Covers variations of Technical Debt outside of just the software/source code
    3. Pages: 288
  4. Understanding Technical Debt: Your Guide to Navigating in the Age of Digital Disruption (2021)
    1. Estimated reading value: Medium
    2. In particular, see Part-3, for the section on "How to measure it?"
    3. Pages: 168
  5. Sustainable Software Architecture: Analyze and Reduce Technical Debt (2019)
    1. No Preview or Table of Contents available
    2. Primarly focuses on just the software aspects of Technical Debt
    3. Pages: 307
  6. Managing Technical Debt: Reducing Friction in Software Development (SEI Series in Software Engineering)  (2019)
    1. Estimated reading value: High
    2. In particular, see Chapter-8: Costing Technical Debt
    3. Pages: 272 
  7. Software Design X-Rays: Fix Technical Debt with Behavioral Code Analysis, 1st Edition (2018)
    1. Estimated reading value: medium
    2. Primarly focuses on just the software aspects of Technical Debt
    3. Pages: 276
  8. The Mikado Method, First Edition (2014)
    1. In particular, see the discussion in Appendix A: Technical debt
    2. Pages: 240
  9. Refactoring for Software Design Smells: Managing Technical Debt 1st Edition (2014)
    1. Estimated reading value: Low-Medium
    2. Primarly focuses on just the software aspects of Technical Debt
    3. Pages: 258

Research Papers:

  1. Towards the Definition of Enterprise Architecture Debts (2019)
    1. "In the software development industry, technical debt is regarded as a critical issue in term of the negative consequences such as increased software development cost, low product quality, decreased maintainability, and slowed progress to the long-term success of developing software. However, despite the vast research contributions in technical debt management for software engineering, the idea of technical debt fails to provide a holistic consideration to include both IT and business aspects. Further, implementing an enterprise architecture (EA) project might not always be a success due to uncertainty and unavailability of resources. Therefore, we relate the consequences of EA implementation failure with a new metaphor --Enterprise Architecture Debt (EA Debt). We anticipate that the accumulation of EA Debt will negatively influence EA quality, also expose the business into risk."
    2. arXiv:1907.00677
    3. https://doi.org/10.1109/EDOCW.2019.00016
  2. Technical Debt Management in Agile Context: A new framework and case study in a large financial institution
    1. SAC '24: Proceedings of the 39th ACM/SIGAPP Symposium on Applied ComputingApril 2024, Pages 826–833
    2. https://doi.org/10.1145/3605098.3635946
  3. Hidden Technical Debt in Machine Learning Systems
    1. Advances in Neural Information Processing Systems 28 (NIPS 2015)
    2. https://papers.nips.cc/paper_files/paper/2015/hash/86df7dcfd896fcaf2674f757a2463eba-Abstract.html
 

A few possibly useful tools/techiniques (as 2nd/3rd order proxies) for approximating some aspects of potential Technical Debt magnitude:

(work-in-progress, entries to be added/elaborated, when I have time...)
 
Frequency/Cluster Analysis of bugs/defects, per source code file, or per line of code:
  1. (tools to be listed...)
 
Line Counting tools:
  1. cloc 
    1. line counting utility
  2. codescene
  3. ohcount
    1. line counting utility  
  4. sonarqube  
  5. tokei
    1. line counting utility
 

Cyclomatic Complexity Static Code Analysis, Software Measurement tools:

  1. (tools to be listed...)
 

Dependency Analysis tools:

  1. (tools to be listed...)
 

Lifecye Analysis: End-of-Life (EOL), End-of-Support (EOS)

  1. Flexera Technopedia

Addendums: 2024-07-13 Sat


Posted by No comments:
Labels:

2024-05-26

2024-05-26 Sunday - Advice for those at the dawn of their IT Career

[image credit: Pexels on pixabay.com]
 

1. First, do no harm.
2. Don't leave a mess. Cleanup after yourself.
3. Listen, Look, Think, Act.
4. Be a good neighbor. Play nice.
5. Trust, but verify. Inspect what you expect.
6. Don't assume. Ask questions.
7. Help others.
8. Put things back in their proper place.
9. Rest before you get tired. Naps are good for you.
10. Don't rush, you might trip and fall

Posted by No comments:

2024-04-28

2024-04-28 Sunday - rustls ("A modern TLS library in Rust")

My weekend reading, doing a deep dive into the Rust source code for the rustls library, and its support for post-quantum (PQ) key exchange.

A modern TLS library in Rust 

 

NOTE:  "This crate provides experimental support for X25519Kyber768Draft00 post-quantum key exchange."
  • https://github.com/rustls/rustls/tree/main/rustls-post-quantum
  • https://docs.rs/rustls-post-quantum/latest/rustls_post_quantum/ 
    •  Crate rustls_post_quantum
      • "X25519Kyber768Draft00 is pre-standardization, so you should treat this as experimental. You may see unexpected interop failures, and the algorithm implemented here may not be the one that eventually becomes widely deployed."
      • "However, the two components of this key exchange are well regarded: X25519 alone is already used by default by rustls, and tends to have higher quality implementations than other elliptic curves. Kyber768 was recently standardized by NIST as ML-KEM-768."
[image source: https://github.com/rustls/rustls/blob/main/rustls-post-quantum/src/lib.rs]

    • See line #71:  [X25519Kyber768Draft00]:
        • "This memo defines X25519Kyber768Draft00, a hybrid post-quantum key exchange for TLS 1.3."
  • IETF Draft: Hybrid key exchange in TLS 1.3 (version 10)
    • [Note: Expires 2024-10-07]
    • "Hybrid key exchange refers to using multiple key exchange algorithms simultaneously and combining the result with the goal of providing security even if all but one of the component algorithms is broken. It is motivated by transition to post-quantum cryptography. This document provides a construction for hybrid key exchange in the Transport Layer Security (TLS) protocol version 1.3."
    • 3. Construction for hybrid key exchange [selected quotes]
      • 3.1. Negotiation
        • "Each particular combination of algorithms in a hybrid key exchange will be represented as a NamedGroup and sent in the supported_groups extension. No internal structure or grammar is implied or required in the value of the identifier; they are simply opaque identifiers."
        • "Each value representing a hybrid key exchange will correspond to an ordered pair of two or more algorithms. (We note that this is independent from future documents standardizing solely post-quantum key exchange methods, which would have to be assigned their own identifier.)"
      •  3.2. Transmitting public keys and ciphertexts [selected quotes]
        • "Recall that in TLS 1.3 a KEM public key or KEM ciphertext is represented as a KeyShareEntry: ..."
        • "These are transmitted in the extension_data fields of KeyShareClientHello and KeyShareServerHello extensions: ..."
        • "For a hybrid key exchange, the key_exchange field of a KeyShareEntry is the concatenation of the key_exchange field for each of the constituent algorithms. The order of shares in the concatenation MUST be the same as the order of algorithms indicated in the definition of the NamedGroup."
    • 6. Security Considerations [selected quotes]
      • "The shared secrets computed in the hybrid key exchange should be computed in a way that achieves the "hybrid" property: the resulting secret is secure as long as at least one of the component key exchange algorithms is unbroken. See [GIACON] and [BINDEL] for an investigation of these issues. Under the assumption that shared secrets are fixed length once the combination is fixed, the construction from Section 3.3 corresponds to the dual-PRF combiner of [BINDEL] which is shown to preserve security under the assumption that the hash function is a dual-PRF."
      • "As noted in Section 2, KEMs used in the manner described in this document MUST explicitly be designed to be secure in the event that the public key is reused, such as achieving IND-CCA2 security or having a transform like the Fujisaki-Okamoto transform applied. Kyber has such security properties. However, some other post-quantum KEMs are designed to be IND-CPA-secure (i.e., without countermeasures such as the FO transform) are completely insecure under public key reuse; for example, some lattice-based IND-CPA-secure KEMs are vulnerable to attacks that recover the private key after just a few thousand samples [FLUHRER]."
      • "...this specification MUST only be used with algorithms which have fixed-length shared secrets (after the variant has been fixed by the algorithm identifier in the NamedGroup negotiation in Section 3.1)"

 

 

rustls Security Advisories:

 

Additional resources:

https://badssl.com/
"badssl.com is meant for manual testing of security UI in web clients."

https://github.com/chromium/badssl.com
"Memorable site for testing clients against bad SSL configs."


Cloudflare Research: Post-Quantum Key Agreement
https://pq.cloudflareresearch.com/
https://tldr.fail/
"On essentially all domains served (1) through Cloudflare, including this one, we have enabled hybrid post-quantum key agreement."

 

Noteworthy Articles:

  1. 2024-04-28: Google Chrome's new post-quantum cryptography may break TLS connections


References: 

NIST: 

Posted by No comments:
Labels: , , ,

2024-04-20

2024-04-20 Sunday - Suggested High Performance Laptops

 

[image credit: JoshuaWoroniecki on pixabay.com]

As an architect, I frequently need to explore various new/emerging technologies and architecture scenarios. To allow me to setup various configurations on my local machine - I want to have robust computing capabilities.

I'm continuing to research new laptop products, as they become available in 2024 - and will revise this blog post as I find better candidates.

Hopefully this information may be useful to other researchers, consultants, and teams.

Option #1: 

MSI Titan 18H"
(with most of my wish list configuration options (only missing RAID 1, with 2x 4TB SSD)

  • https://www.msi.com/Laptop/Titan-18-HX-A14VX
  • https://www.newegg.com/p/N82E16834156588 
  • https://www.amazon.com/MSI-Titan-Computer-i9-14900HX-Thunderbolt/dp/B0CY9RV1J9
    •  MSI Titan 18 HX 18" 
    • 120Hz 4K 18" UHD mini LED display, 3840 x 2400, HDR 1000, 100% DCI-P3
    • Intel Core i9-14900HX 24-Core (8P+16E, 2.20-5.8 GHz, 14th gen HX-series, "Raptor Lake")
    • NVIDIA GeForce RTX 4090, 16 GB GDDR6
    • 128GB DDR5 RAM (32 GB x 4)
    • 4 TB (2 TB x 2) NVMe Gen4x4 SSD [KM: Would upgrade to 4 TB x 2, RAID 1]
    • WiFi 7
    • LAN: Killer E3100G
    • WLAN: Killer WiFi 7 BE1750
    • Bluetooth 5.4
    • USB: 3 x USB 3.2 Gen 2 Type-A
    • Card Reader: SD7.0
    • Thunderbolt: 2 x Thunderbolt 4 w/ DP (1 also with PD3.1)
    • HDMI: 1 x HDMI 2.1
    • Ethernet: 1 x RJ-45 (2.5Gbps)
    • Audio Ports: 1 x Headphone/Microphone Combo Jack 
    • Speaker: Sound by Dynaudio, 4x2W Speakers 2W x2W Woofer
    • Keyboard: Cherry Mechanical KB SteelSeries per-Key RGB (99 Key)
    • Touchpad: Seamless EGB Haptic Touchpad
    • Webcam: IR FHD w/shutter 
    • Power adapter: 400-watt AC Adapter
    •  Battery: 4 cell (99.9Whr) Li-Ion
    • Windows 11 Pro 64-bit
    • 7.93 pounds 
      • Dimensions: 15.9 x 12.08 x 1.26 inches
      • Strange that it says 15.9

 

 

[image source: Amazon.com]


 

Option #2:

EXCaliberPC [2024] MSI Raider 18 HX

 

Option #3:

 EXCaliberPC [2023] MSI Titan GT77HX 

  • https://www.amazon.com/dp/B0BTM3M282/
    • 13VH-046US (i9-13980HX)
    • 128GB RAM
    •  8TB (2x 4TB) WD Black SN850X NVMe SSD (Seq. Read 7300MB/s, Seq. Write 6600MB/s) 
    • RTX 4080 12GB
    • 17.3" 4K UHD
    • Windows 11 Pro)


 

Posted by No comments:
Labels: , ,

2024-04-17

2024-04-17 Wednesday - Health Effects of Overwork

[image credit: anykeep on pixabay.com]

 

 This blog post is a placeholder for organizing citations of articles and medical research reports on the effects of overwork (e.g., working more than 40+, 50+, 55+ hours per week - on a sustained basis). 

General articles:

  1. https://en.wikipedia.org/wiki/Effects_of_overtime
    • "Employees who work overtime hours experience numerous mental, physical, and social effects. In a landmark study, the World Health Organization and the International Labour Organization estimated that over 745,000 people died from ischemic heart disease or stroke in 2016 as a result of having worked 55 hours or more per week."
    • "... those working long hours (55 hours or more per week) were at 40% higher risk of developing atrial fibrillation compared to those working a standard 35-40 hour-week"
  2. https://en.wikipedia.org/wiki/Karoshi
  3.  

Professional research: 

  1. Long working hours and burnout in health care workers: Non-linear dose-response relationship and the effect mediated by sleeping hours—A cross-sectional study (2021-05-06, Journal of Occupational Health)
  2. Impact of work schedules of senior resident physicians on patient and resident physician safety: nationwide, prospective cohort study (2002-2007, 2014-2017, Division of Sleep and Circadian Disorders, Departments of Medicine and Neurology, Brigham and Women's Hospital, Boston, MA, USA)
    • "...exceeding 48 weekly work hours or working shifts of extended duration endangers even experienced (ie, PGY2+) resident physicians and their patients."
    • "Working more than 48 hours per week was associated with an increased risk of self-reported medical errors, preventable adverse events, and fatal preventable adverse events as well as near miss crashes, occupational exposures, percutaneous injuries, and attentional failures (all P<0.001)."
    • "Working between 60 and 70 hours per week was associated with a more than twice the risk of a medical error (odds ratio 2.36, 95% confidence interval 2.01 to 2.78) and almost three times the risk of preventable adverse events (2.93, 2.04 to 4.23) and fatal preventable adverse events (2.75, 1.23 to 6.12)"
    • "Working one or more shifts of extended duration in a month while averaging no more than 80 weekly work hours was associated with an 84% increased risk of medical errors (1.84, 1.66 to 2.03), a 51% increased risk of preventable adverse events (1.51, 1.20 to 1.90), and an 85% increased risk of fatal preventable adverse events (1.85, 1.05 to 3.26). Similarly, working one or more shifts of extended duration in a month while averaging no more than 80 weekly work hours also increased the risk of near miss crashes (1.47, 1.32 to 1.63) and occupational exposures (1.17, 1.02 to 1.33)."
  3. At-Risk Work Hours Among U.S. Physicians and Other U.S. Workers (American Journal of Preventive Medicine, Volume 65, Issue 4, October 2023, Pages 568-578)
    • "Systematic reviews by the WHO have shown an increased risk of morbidity and mortality related to ischemic heart disease and stroke among individuals working an average of ≥55 hours/week."
    • "The relationship between work hours, well-being, and health outcomes is complex. At least 2 pathways—a physiological stress response pathway (e.g., autonomic nervous system, immune function, hypertension, arrhythmia risk) and a behavioral stress response pathway (e.g., alcohol use, unhealthy diet, tobacco use, physical inactivity, impaired sleep)—may contribute to morbidity and mortality associated with long work hours."
    • "risk of burnout increases by approximately 2% for each 1 additional hour worked each week"
    • "recent studies have found that working ≥55 hours/week is associated with an increased risk of ischemic heart disease and stroke."
    • https://www.sciencedirect.com/science/article/pii/S0749379723001666
    • https://doi.org/10.1016/j.amepre.2023.03.020

 

 

Current backlog of additional links to review: 

 

 

 

 

Posted by No comments:
Labels: , , ,

2024-04-10

2024-04-11 Thursday - Book Review: Cracking the Data Science Interview

[image source: Amazon.com]

 

Cracking the Data Science Interview: Unlock insider tips from industry experts to master the data science field (Feb 29th, 2024)
https://www.amazon.com/Cracking-Data-Science-Interview-industry/dp/1805120506/

 
by Leondra R Gonzalez (Senior Data & Applied Scientist, Microsoft), and Aaren Stubberfield (Data Scientist, Microsoft)


[Link to my review on Amazon]

Review Title:
Packed with valuable guidance: A balanced survey of Data Science with great breadth and depth

Review thoughts:

  • It is difficult for most authors to strike the necessary balance when writing a book that covers so much ground - but this book achieves this quite well.
  • This book is well written - and earns the accolade I reserve for just a few books: Crisp!
  • The content is very well structured
  • The authors approach to teaching is actionable - with concrete skill building examples.
  • This book provides a good outline for helping people identifying gaps in their skills/knowledge
  • There are great suggestions for the reader to further explore various topics (versus overburdening the focused goals of the book)
  • Chapter-3 is a fast paced introduction to Python - and provides concise examples to gives the reader immediate skills in writing Python code.
  • One of the most important techniques the book teaches is covered in the section "Applying scenario-based storytelling".
  • Chapter-9's coverage of Feature Engineering is noteworthy for being well done in conveying the concepts with easy to understand examples.  
  • The illustrations are very nicely done.
  • code examples are concise, focused, and well explained.
  • The "when to use" and companion "tips" sections are very nice touches - that help the reader understand not just the WHAT and HOW, but also the WHY.
  • The "Assessment" and companion "Answer" sections are a great teaching technique to challenge the reader - and provide immediate guidance to clarify/correct any potential misunderstandings.
  • In Part-3, the discussion of "Assumptions", "Common Pitfalls", and the associated "Implement Example" entries - ARE WORTH THE PRICE OF THE BOOK ALONE.
  • Any manager or developer - will benefit from using this book's broad survey of topics - to expand their understanding of Data Science concepts and techniques.
  • As an architect, I learned quite a bit of useful Data Science concepts/techniques by working my way through this book.
  • If someone carefully worked their way through the full contents of this book - I believe they would have a good foundation established in preparing for a Data Science interview.


Suggestions for the next edition:

  • Create a "Data Science Awesome Jobs Board List" GitHub repository, as a companion to the book.
  • Add a new chapter to discuss common anti-patterns in data science.
  • Performance trade-offs/considerations would also be some very important information to perhaps consider adding in a next edition.
  • An Appendix of Suggested Reading/Books might be helpful (for example, in chapter-3, p-59, while text mining and NLP are noted as outside of the scope of the book - it is an important area of Data Science - and it would be helpful for the next edition to include some suggested books on topics that are designated outside of the book's scope).
  • On page-331, it would be helpful to also mention the recent open source fork of Terraform - OpenTofu.


There is one critical caution missing in "Part 3: Exploring Artificial Intelligence", "Chapter-11 Building Networks with Deep Learning" (for example, on page-317, in the section: "Introducing GenAI and LLMs"):
Any discussion of GenAI __MUST__ caution on the very real risks of hallucination and confabulation.
 


Posted by No comments:
Labels: , , ,
Subscribe to: Posts (Atom)

Copyright

© 2001-2021 International Technology Ventures, Inc., All Rights Reserved.