Curated by T Ashok @ash_thiru

Summary

This article is curated from SIX articles as a quick primer on AI. Starting with a glossary on AI, it delves into tacit knowledge as codified via ML  and understanding the difference between ML & AI. A quick peek into deep learning and challenges of explaining the patterns ending with a interesting piece AI written by an AI program.

Glossary of terminology in AI

Here is an easy article “A Simple, yet Technical Glossary of Terminology in AI” that provides simple glossary of terms, abbreviations, and concepts related to the field and sub-fields of artificial intelligence. Based on technical definitions by pioneers and leaders in AI.

ML & Polanyi’s paradox

“Explicit knowledge is formal, codified, and can be readily explained to people and captured in a computer program. But tacit knowledge, a concept first introduced in the 1950s by scientist and philosopher Michael Polanyi, is the kind of knowledge we’re often not aware we have, and is therefore difficult to transfer to another person, let alone capture in a computer program. Machine learning has enabled AI to get around one of its biggest obstacles, the so-called Polanyi’s paradox.” Read more in this article ”What Machine Learning Can and Cannot Do“

ML & AI – The difference (1)

There’s much confusion surrounding AI and ML. Some people refer to AI and ML as synonyms and use them interchangeably, while others use them as separate, parallel technologies. In many cases, the people speaking and writing about the technology don’t know the difference between AI and ML. In others, they intentionally ignore those differences to create hype and excitement for marketing and sales purposes.” This article  “Why the difference between AI and machine learning matters” attempts to disambiguate the jargon and myths surrounding AI.

ML & AI – The difference (2)

“Unfortunately, some tech organizations are deceiving customers by proclaiming using AI on their technologies while not being clear about their products’ limits. There’s still a lot of confusion within the public and the media regarding what truly is artificial intelligence, and what truly is machine learning. Often the terms are being used as synonyms, in other cases, these are being used as discrete, parallel advancements, while others are taking advantage of the trend to create hype and excitement, as to increase sales and revenue.” says Roberto Irliondo in his article “Machine Learning vs. AI, Important Differences Between Them”.

Explaining how patterns are connected

Deep learning is good at finding patterns in reams of data, but can’t explain how they’re connected. Turing Award winner Yoshua Bengio wants to change that, read about this is this article “An AI Pioneer Wants His Algorithms to Understand the ‘Why’“

Chapter on AI written by a AI program

Here is an interesting excerpt from an ‘autobiographical’ chapter written by an AI program “This chapter on the future of Artificial Intelligence was written by Artificial Intelligence”, excerpted from the book “The Tech Whispererer”.

Summary

What it takes to “Build with quality” ? Girish Elchuri outlines that it takes a good modern micro-services architecture, a robust design that is modular, adopting a zero trust programming mentality and documenting specifications & design to enabling good test cases.

The video of this “nano learning” smartbits video is available here.

When we are developing a product, we all know that apart from the functional requirements, the quality requirements are also equally important. It is important that the product works as per the functions and also as per the quality, and that must start from architecture. You should have an architecture which is as per the current trends going with the micro-services so that it becomes much easier to test it out for each service independently.

Then we look at the design. You need to have a robust design, preferably in a modular way which will simplify the process of testing because it is always easy to test a small portion than a big monotonous thing. That is the second thing you need to look at; having a design which is very modular so that you can do a plug and play much easily including testing.

The third thing that you would look at is what I call a zero-trust programming. When you are developing or programming, you don’t trust anything. For example, even if you are getting parameters from your own functions, you don’t trust them, you just verify them once again. Basically, the way to do programming is to do a lot of validation of the parameters, validation of the context and whole lot of other things and when you know everything is right, then go into the functionality. This way, you are catching a lot of errors that are possible, upfront rather than in the logic and kind of having the runtime issues.

After that, you have to also make sure that you put enough effort to write the functional specs and design documents, because that is one aspect that people always ignore. Primarily, if you have a good functional specs and design documents, it becomes that much easy for the testing/quality team to design the test cases. So, I would say that you should have a holistic approach to quality rather than a very narrow focus of testing it post product development and then suffer a lot.

click to video

1. Be disciplined, but stay creative.
2. Ask questions, find answers. 
3. Be helpful, but don’t do others’ work.
4. Point out mistakes, don’t blame though.
5. Find bugs, help get them fixed too.
6. Communicate clearly, communicate crisply.
7. Do good work, showcase value. 
8. Do the mundane things, innovate constantly.
9. Stay doggedly steadfast, but be flexible.
10. Observe well, see things that are hidden.
11. Stay focussed, but have a 360 degree vision.
12. Have a system’s view, but know the internals.
13. Think like end user, while engineering solution.
14. Analyse like an engineer when working with end users.
15. Do what you must, automate everything else.
16. Document tersely, do voraciously.
17. Find what you must, prevent what you can.
18. Do less, accomplish more.
19. Engineer in code, to enable finding issues.
20. Have an user’s mind, engineer’s brain, eagle’s eyes and a businessman’s head. 
21. Read, observe, analyse, explore, experiment, prove, disprove- Actively seek out. 
22. Analyse quantitatively the engineering data, present qualitatively the business impact.
23. Strive for clarity, visualise the flow, spot anomalies in mind’s eye
24. Don’t settle, constantly churn and evolve, unsettle
25. Learn constantly, unlearn continually

T Ashok @ash_thiru

“It is easy to make perfect decisions with perfect information. Medicine asks you make perfect decisions with imperfect information”.

Siddhartha Mukherjee

In this wonderfully thin book “The Laws of Medicine: Field Notes from an Uncertain Science”, Siddhartha Mukherjee investigates the most perplexing cases of his career ultimately identifying three principles that govern modern medicine.

Law One: A strong intuition is much more powerful than a weak test.
“A test can only be interpreted sanely in the context of prior probabilities”
The answer to why a dignified fifty-six-year-old man, from a tiny Boston neighbourhood, who was suffering from weight loss and fatigue was solved by simply getting to know the patient better!

Law Two: “Normals” teach us rules; “outliers” teach us laws.
“Rather than figure out why a drug failed, he would try to understand why it occasionally succeeded “
The strange case of “patient 45,” who miraculously responded to an experimental drug for bladder cancer (patients 1 through 44 weren’t as lucky) was studied deeply by Solit resulting in a discovery of an unusual genetic marker that could identify which future patients could also be helped.

Law Three: For every perfect medical experiment, there is a perfect human bias.
“The greatest clinicians have a sixth sense for bias. What doctors really hunt is bias”
Countless biases pervade the medical literature, even when studies have been randomized and controlled to eliminate prejudices.

 Read this brilliant book to understand counterintuitive thinking!

T Ashok @ash_thiru

Summary

In this article I have tried picture(ise) the landscape of the plethora of tools for testing software which has moved away from just testing to build-test-deploy in a continuous manner. Keeping the interesting visual I have listed the FIFTEEN broad categories of tools that make up the modern digital testing landscape.

Given the plethora of front ends for digital applications of today,  from PCs to tablets and mobile phones wth varied form factors, OS and browsers, with varying connection speeds, sometimes uncertain, the integration with many external systems via services with demands on non-functional attributes and the frequent nature of releases has made the challenge of automation and keeping in sync harder. 

In this article, I have attempted to picture(ise) the landscape of test tooling with the entity-under-test(EUT) at centre (note that an EUT may be a small component, a subsystem or the complete system) with multiple ways to access it via API, Message/Service or UI on the left, evaluation by various test types at the top, the EUT enclosed in a deployment environment that may be an container/system with various ‘platform choices’.  Keeping this as the base I have attempted to enumerate the various activities related to evaluation as inject/stimulate, observe/measure, validate/oracle, log/record and generate mocks as necessary to test for functionality or other non-functional attributes in the larger context of test design, automate, build and deploy on a variety of platforms as necessary. 

Using the above picture we have the FIFTEEN categories of tools with some example tools as a table below.

T Ashok @ash_thiru

Summary

This article is a set of brilliant ideas curated from four articles with the first suggesting ten ways to build high quality into software, second one from Scaled Agile framework outlining the clear definition of Done, the third highlighting how lean thinking and management helps, and the last outlining how Poka-Yoke can help in mistake proofing.

Building Quality In

“When looking at quality from a testing perspective, I would agree that it is not possible to build software quality in. To build quality in you need to look at the bigger picture. There are many ways to improve quality. It all depends on the problem. Maybe, you can automate something that previously had to be done by a human being. Maybe, you need training to better use the tools you have. Maybe you need to find a better tool to do the job. Or maybe, you need a checklist to remind you of what you need to look at. The possibilities are endless.

That’s not what I’m talking about when I talk about building quality in. Building in quality requires a more general, big-picture approach” says Karin Dames in the insightful article  10 Ways to Build Quality Into Software – Exploring the possibilities of high-quality software and outlines  TEN guidelines to consistently build quality into software:”

1. Slow down to speed up
You either do it fast, or thoroughly.

2. Keep the user in mind at all times
The story isn’t done until the right user can use it.

3. Focus on the integration points
Integration is probably the biggest cause for coding errors, understandably.

4. Make it visible
Spend time adding valuable logging with switches to to switch logging on and off on demand.

5. Error handling for humans
What would the next person need to understand this without having to bug me?

6. Stop and fix errors when they’re found
Done means done. End of story. Don’t accept commonly accepted levels of errors.

7. Prevent it from occurring again
Do RCA to uncover what caused the problem from happening in the first place and put a measure in place to prevent it from happening again.

8. Reduce the noise
Good design is simple. Good design is also good quality.

9. Reduce.Re-use.Recycle.
Focus on maintainability. A code base is organic. Factor in time for rewriting code and cleaning up code, just like you would spring clean your house regularly or clean up your desk.

10. Don’t rely on someone else to discover errors
Just because it’s not your job, doesn’t mean you shouldn’t be responsible. If you see something wrong, do something about it. If you can fix it, do it. Immediately.

Read the full article at 10 Ways to Build Quality Into Software – Exploring the possibilities of high-quality software

Reactive vs Proactive Quality Management

“To understand how to build quality into our products from the very beginning, we need to understand why this is not happening naturally. The most common way of preventing defects from reaching customers comes down to introducing a great number of inspections and countless KPI or metrics into the process. The problem with this approach is that it is reactive. And wasteful. If we think in the context of the value streams, neither inspections nor metrics add any value to the customer. At best, they help you discover and react to already produced defects. At worst, they encourage playing the system – you get what you measure.”  is what the insightful article “The Built-In Quality Management of Continuous Improvement” says.

The article continues on to outline the way how lean management views the issue of quality and defects is through the lens of value and continuous improvement.

Shifting into proactive quality management

Lean management views the issue of quality and defects is through the lens of value and continuous improvement

• Value-centered mindset means everything you do needs to be bringing value to your client. Your client is anyone who receives the deliverable of your work.
• Waste-conscious thinking helps remove whatever is not adding or supporting value. This results in fewer redundant metrics or steps in a process.
• Continuous flow of work encourages working in smaller batches. This reduces the risk of larger defects, makes fixes easier and establishes a smooth delivery flow.
• Bottlenecks are removed or guarded for the sake of the flow. If a work stage that adds a lot of value but is taking too much time, the cost of delay for the rest of the process might overcome this value.
• Pull-powered flow means efforts and resources should not get invested into the things irrelevant to your stakeholders.
• Upstream leadership empowers the person who is doing the work to elevate issues letting you cut the issues at the root.
• Analysis and continuous improvement. Applying the Lean principles once won’t do the trick. Continuously analyze your work, outcomes, mistakes and build on that.

Want to know more, read the full article “The Built-In Quality Management of Continuous Improvement” .

Scalable Definition of Done 

The interesting article Built-In Quality states “Definition of Done is an important way of ensuring increment of value can be considered complete. The continuous development of incremental system functionality requires a scaled definition of done to ensure the right work is done at the right time, some early and some only for release. An example is shown in the picture below, but each team, train, and enterprise should build their own definition.” 

Copyright Scaled Agile Inc. Read the FAQs on how to use SAFe content and trademarks here: https://www.scaledagile.com/about/about-us/permissions-faq/. Explore Training at: https://www.scaledagile.com/training/calendar/ 

Read the full article The Built-In Quality Management of Continuous Improvement.

On a closing note “Have you heard of Poka Yoke?” Poka Yoke means ‘mistake-proofing’ or more literally – avoiding (yokeru) inadvertent errors (poka).  Its idea is to prevent errors and defects from appearing in the first place is universally applicable and has proven to be a true efficiency booster.

Poka Yokes ensure that the right conditions exist before a process step is executed, and thus preventing defects from occurring in the first place. Where this is not possible, Poka Yokes perform a detective function, eliminating defects in the process as early as possible.

Poka Yoke is any mechanism in a Lean manufacturing process that helps to avoid mistakes. Its purpose is to eliminate product defects by preventing, correcting, or drawing attention to human errors as they occur.

One of the most common is when a driver of a car with manual gearbox must press on the clutch pedal (a process step – Poka Yoke) before starting the engine. The interlock prevents from an unintended movement of the car.

When and how to use it?

Poka Yoke technique could be used whenever a mistake could occur or something could be done wrong preventing all kinds of errors:

• Processing error: Process operation missed or not performed per the standard operating procedure.
• Setup error: Using the wrong tooling or setting machine adjustments incorrectly.
• Missing part: Not all parts included in the assembly, welding, or other processes.
• Improper part/item: Wrong part used in the process.
• Operations error: Carrying out an operation incorrectly; having the incorrect version of the specification.
• Measurement error: Errors in machine adjustment, test measurement or dimensions of a part coming in from a supplier.

If you are keen to know more, read the full article What is the Poka Yoke Technique?

—

References

1 Karin Dames,  “10 Ways to Build Quality Into Software – Exploring the possibilities of high-quality software“.

2. From Scaled Agile Framework Inc, “Build In Quality”.

3 From kanbanize.com , “The Built-In Quality Management of Continuous Improvement“.

4. From kanbanize.com , “What is the Poka Yoke Technique?”.