Showing posts with label complexity. Show all posts
Showing posts with label complexity. Show all posts

Saturday, April 12, 2025

Alarm Fatigue

Alarm fatigue or alert fatigue describes how busy workers become desensitized to safety alerts, and as a result ignore or fail to respond appropriately to such warnings. Alarm fatigue occurs in many fields, including construction and mining, healthcare, and the nuclear power field. Like crying wolf, such false alarms rob the critical alarms of the importance they deserve. Alarm management and policy are critical to prevent alarm fatigue. 

Examples

  • Vehicle back-up alarms sound so frequently that they often become senseless background noise
  • Electronic medical monitors tracking clinical information such as vital signs and blood glucose sound alarms so frequently, and often for such minor reasons, that they lose the urgency and attention-grabbing power which they are intended to have
  • California Proposition 65 has been criticized for causing "over-warning" due to encouraging "meaningless warnings." There is no penalty for posting an unnecessary warning sign, and to the extent that warnings are vague or overused, they may not communicate much information to the end user. Many companies now routinely attach Prop 65 warning labels to any product of theirs that they think might possibly contain one of the 900 listed chemicals without testing to see whether the chemical is really present in their product and without reformulating their product, because it is cheaper to do so than to run the risk of being sued by Prop 65 enforcers.

Proposed solutions

  • Identify by sound alone. Change alarm sounds to be softer and friendlier in order to improve identification of alarms. 
  • Adjust the parameters and delays to alarms to match the traits and status. However, this directly trades sensitivity for specificity.
  • Centrally monitor alarms where a trained person evaluates each alarm and distributes alerts only when necessary.
  • Adjust automated alarm algorithms to be more specific and not overly sensitive to mitigate false alarms and balance sensitivity and specificity to still detect actionable conditions.

See also

source: https://en.wikipedia.org/wiki/Alarm_fatigue

Friday, July 7, 2023

Zeigarnik Effect

When we finish a task, we get
closure and stop thinking about it.
When we don’t finish tasks, we
keep thinking about them.
We yearn for completion.

Defined by Bluma Zeigarnik, a Lithuanian-Soviet psychologist who in the 1920s conducted a study on memory, in which she compared memory in relation to incomplete and complete tasks.

In her study, Zeigarnik found a strong correlation between the memory of an incomplete task and the desire to close the loop. She declared that if we have tasks that are incomplete, we consume brainpower by holding onto the memory; our subconscious continues to remind (or nag) our conscious mind.

A few open loops might be good for our productivity; they remind us to bring these tasks to completion.

If there are too many open loops, however, you may suffer cognitive overload: that feeling of stress that comes when a significant amount of mental resources are tied up.

source: Agile Coffee

On the positive side is the adage "always leave them wanting more". Intentionally stopping a task before you are exhausted can be a motivation to get back to that task again soon.

Saturday, August 28, 2021

Braess's paradox

Braess's paradox is the observation that adding one or more roads to a road network can slow down overall traffic flow through it. The paradox was postulated in 1968 by German mathematician Dietrich Braess.

The paradox may have analogies in electrical power grids and biological systems. It has been suggested that in theory, the improvement of a malfunctioning network could be accomplished by removing certain parts of it. The paradox has been used to explain instances of improved traffic flow when existing major roads are closed.

The idea behind Braess's discovery is that the Nash equilibrium may not equate with the best overall flow through a network.

Adding extra capacity to a network when the moving entities selfishly choose their route can in some cases reduce overall performance. That is because the Nash equilibrium of such a system is not necessarily optimal. In a Nash equilibrium, drivers have no incentive to change their routes. While the system is not in a Nash equilibrium, individual drivers are able to improve their respective travel times by changing the routes they take. In the case of Braess's paradox, drivers will continue to switch until they reach Nash equilibrium despite the reduction in overall performance.


 

source: https://en.wikipedia.org/wiki/Braess%27s_paradox


Saturday, August 21, 2021

Dunning-Kreuger Effect

The Dunning-Kreuger Effect is a very eloquent representation of experience and perceived intelligence regarding a topic area or subject matter.  It is “a cognitive bias in which people mistakenly assess their cognitive ability as greater than it is.”

source: https://evidenceinmotion.com/goodharts-law-the-cobra-effect-and-dunning-kreuger/

The concept of the Dunning-Kruger effect is based on a 1999 paper by Cornell University psychologists David Dunning and Justin Kruger. The pair tested participants on their logic, grammar, and sense of humor, and found that those who performed in the bottom quartile rated their skills far above average. For example, those in the 12th percentile self-rated their expertise to be, on average, in the 62nd percentile. 

source: https://www.psychologytoday.com/us/basics/dunning-kruger-effect




 

Saturday, July 11, 2020

Legacy Code

In his book Working Effectively With Legacy Code, Michael Feathers gives a clear definition of what Legacy Code means to him:

To me, legacy code is simply code without tests.

Without tests, it’s usually very hard to know everything a code can do. If you need to understand what the code is doing, you need to read it carefully, play the computer in your head and envision all the possible scenarios. You can also test it manually to see what it does. Generally, code without tests is tricky to change without introducing a regression somewhere.

This is my [Nicolas Carlo] definition of Legacy Code.

Legacy Code is valuable code you’re afraid to change.

You need to realize a few things:
  • Unfamiliarity with the code plays a lot. We overestimate the complexity of unfamiliar code. This is why you think this code you didn’t write is Legacy Code. And, yes, your past self often does silly mistakes that result in unfamiliar code for future you.
  • Good tests make you comfortable changing unfamiliar code. Hence Feathers’ definition. But poor tests won’t.
  • It gets better after a few months. Keep that in mind if you started on working on a legacy project and you’re struggling. I’m not saying the code is great, but you’ll get used to it and understand its quirks and specificities better.
  • Most of the code is terrible because it’s the result of many people working on it, over a long period of time, with conflicting requirements, under time pressure. Knowledge is imperfect and shortcuts are taken to meet the deadlines. That’s VERY common. Eventually, you’ll reach a state where every move introduces a bug and any feature takes forever to be implemented.
The following definition states something people fail to realize: Legacy Code is a personal point of view.

Legacy Code is the code you need to change and you struggle to understand.

It depends on your understanding of the code. And your feeling about changing it.

Learning to understand Legacy Code is essential to be productive. You can try to avoid it and feel bad when you’re stuck with it… Or you can see this as an opportunity to develop valuable skills that will make you stand out as a great developer.

Original article, from which this is excerpted, was written by Nicolas Carlo who lives and works in Montreal, Canada 🍁 He founded the Software Crafters Montreal community which cares about building maintainable softwares.


For me [Doug], legacy code is:
  • written without best current practices, for example, tests
  • authored by someone else (or me long enough ago I've forgotten it)
  • has stood the test of time and is part of a successful product.
As Nicolas Carlo stated, legacy code is valuable.


Sunday, August 12, 2018

Antifragile

This Christmas you may get a package labeled , which you know means “don’t shake the box to guess its contents!”. Most gifts will be unlabeled, meaning they are robust, that is, unaffected by shaking. But robust is not the opposite of fragile. Antifragile is its opposite. Nassim Taleb, in his book by the same name, defines antifragile as those objects and systems that improve when perturbed. Thus, an antifragile Christmas package would come with the following label:

Ackermann's Function and Recursion

Professor Brailsford explains recursion with one of the most difficult programs to compute: Ackermann's function.

Source (YouTube): The Most Difficult Program to Compute? - Computerphile

Friday, April 27, 2018

bloom filter

A Bloom filter is a data structure designed to tell you, rapidly and memory-efficiently, whether an element is present in a set.The price paid for this efficiency is that a Bloom filter is a probabilistic data structure: it tells us that the element either definitely is not in the set or may be in the set.The base data structure of a Bloom filter is a Bit Vector. Visit Bloom Filters by Example for an interactive visualization.

source: http://llimllib.github.io/bloomfilter-tutorial/

Operations

The basic bloom filter supports two operations: test and add.
Test is used to check whether a given element is in the set or not. If it returns:
  • false then the element is definitely not in the set.
  • true then the element is probably in the set. The false positive rate is a function of the bloom filter's size and the number and independence of the hash functions used.
Add simply adds an element to the set. Removal is impossible without introducing false negatives, but extensions to the bloom filter are possible that allow removal e.g. counting filters.

Applications

The classic example is using bloom filters to reduce expensive disk (or network) lookups for non-existent keys. If the element is not in the bloom filter, then we know for sure we don't need to perform the expensive lookup. On the other hand, if it is in the bloom filter, we perform the lookup, and we can expect it to fail some proportion of the time (the false positive rate).

source: https://www.jasondavies.com/bloomfilter/ including a bloom filter implementation in JavaScript

Wikipedia

A Bloom filter is a space-efficient probabilistic data structure, conceived by Burton Howard Bloom in 1970, that is used to test whether an element is a member of a set. False positive matches are possible, but false negatives are not – in other words, a query returns either "possibly in set" or "definitely not in set". Elements can be added to the set, but not removed (though this can be addressed with a "counting" filter); the more elements that are added to the set, the larger the probability of false positives.

The following topics are also covered:
  • Algorithm description
  • Space and time advantages
  • Probability of false positives
  • Optimal number of hash functions
  • Approximating the number of items in a Bloom filter
  • The union and intersection of sets
  • Interesting properties

Extensions and applications

  • Cache filtering
  • Counting filters
  • Decentralized aggregation
  • Data synchronization
  • Bloomier filters
  • Compact approximators
  • Stable Bloom filters
  • Scalable Bloom filters
  • Layered Bloom filters
  • Attenuated Bloom filters
  • Chemical structure searching

Examples

  • Akamai's web servers use Bloom filters to prevent "one-hit-wonders" from being stored in its disk caches. One-hit-wonders are web objects requested by users just once, something that Akamai found applied to nearly three-quarters of their caching infrastructure. Using a Bloom filter to detect the second request for a web object and caching that object only on its second request prevents one-hit wonders from entering the disk cache.
  • Google Bigtable, Apache HBase and Apache Cassandra, and Postgresql use Bloom filters to reduce the disk lookups for non-existent rows or columns. Avoiding costly disk lookups considerably increases the performance of a database query operation.
  • The Google Chrome web browser used to use a Bloom filter to identify malicious URLs.
  • Medium uses Bloom filters to avoid recommending articles a user has previously read.
Link to the whole article: https://en.wikipedia.org/wiki/Bloom_filter

Saturday, April 21, 2018

Sharding: Database, Protractor Tests, Architecture

Database

Jason Tee explains: "In the simplest sense, sharding your database involves breaking up your big database into many, much smaller databases that share nothing and can be spread across multiple servers."

Technically, sharding is a synonym for horizontal partitioning. In some cases, database sharding can be done fairly simply. One common example is splitting a customer database geographically. Customers located on the East Coast can be placed on one server, while customers on the West Coast can be placed on a second  server.

source: https://searchcloudcomputing.techtarget.com/definition/sharding

Protractor Tests

Protractor can run your tests in parallel when you enable sharding. The files are executed across different browsers as they become available. Make your tests independent at the file level because the order in which they run is not guaranteed and it's easier to run a test in isolation.

source: https://www.protractortest.org/#/style-guide

Architecture


The Shard skyscraper in London

By © User:Colin / Wikimedia Commons, CC BY-SA 4.0, https://commons.wikimedia.org/w/index.php?curid=39978232






Friday, September 18, 2015

bikeshedding




“the amount of noise generated by a change is inversely proportional to the complexity of the change.”

“Parkinson explains that this is because an atomic plant is so vast, so expensive and so complicated that people cannot grasp it, and rather than try, they fall back on the assumption that somebody else checked all the details before it got this far.”


Parkinson’s Law of Triviality. Parkinson observed that a committee whose job is to approve plans for a nuclear power plant may spend the majority of its time on relatively unimportant but easy-to-grasp issues, such as what materials to use for the staff bikeshed, while neglecting the design of the power plant itself, which is far more important but also far more difficult to criticize constructively.

Wednesday, May 7, 2014