Teaching AI To Be ‘Smarter’ By Doubting Itself

Interesting post that suggests that in deep learning algorithms, questioning things may lead to higher quality conclusions.

Researchers at Uber and Google are working on modifications to the two most popular deep-learning frameworks that will enable them to handle probability. This will provide a way for the smartest AI programs to measure their confidence in a prediction or a decision—essentially, to know when they should doubt themselves.

Deep learning, which involves feeding example data to a large and powerful neural network, has been an enormous success over the past few years, enabling machines to recognize objects in images or transcribe speech almost perfectly. But it requires lots of training data and computing power, and it can be surprisingly brittle.

Somewhat counterintuitively, this self-doubt offers one fix. The new approach could be useful in critical scenarios involving self-driving cars and other autonomous machines.

“You would like a system that gives you a measure of how certain it is,” says Dustin Tran, who is working on this problem at Google. “If a self-driving car doesn’t know its level of uncertainty, it can make a fatal error, and that can be catastrophic.”

What Does An Enterprise Architect Do?

‘Enterprise Architect’ is a very fashionable title these days which causes a bit of confusion (and consternation) for actual EA practitioners. Typically, this title is attached to the role of someone who has deep technical knowledge about a given technology/application/suite. This is not an Enterprise Architect.

This article does a great job of clarifying what Enterprise Architecture is and what an Architect does (or should do).

“Before answering that question, it is important to note that no architecture is a solution. Often people confuse a solution, such as corporate infrastructure, as the architecture. This is an all too common mistake and very misleading. An architecture guided the development of the infrastructure, the infrastructure is a solution – not the architecture.

“The architect’s role isn’t to create solutions. Rather the architect’s role is to inform decision-makers and guide development of solutions based on understanding business drivers and needs of the organization. Although a single person can have both a role as an architect and a developer. The architect typically takes a broader and material independent view than the developer, yet leaves much downstream detail to the development community.

“So, since architecture is not a solution what is it? It is a package of information that describes what is needed to achieve a given result and what it might look like in a future state if implemented. In order for an architecture to be effective, that is for it to be realized in solutions, it must guide decisions.

“Any good architecture addresses a well-defined scope and seeks to achieve specified goals. For example, an architecture for a back-office software suite will seek to enable improvements to back office operations, an architecture for a department network will enable department interconnectivity, an architecture for corporate infrastructure will address needed services throughout at lower costs, etc. For each scope there are decision-makers that can either accept or reject the guidance from the architect such as office managers, network managers, the head of IT, etc.

“Those that deal with Enterprise Architecture take the broadest view, deal with issues that are oftentimes beyond even the corporate level, and are most effective when they influence corporate or Board level decision-makers.

Unpredictions for Artificial Intelligence (AI)

This post is a refreshing counterpoint to the breathless ‘AI will take over everything’ reporting that is increasingly common of late.

Self-driving cars
The first area is that “we won’t be riding in self-driving cars”. As Dr. Reddy explains: “While many are predicting a driverless future, we’re a long ‘road’ away from autonomous vehicles.” This is is terms of cars that will take commuters to work, a situation where the commuter can sit back and read his or her iPad while paying little attention to the traffic outside.
He adds: “For a number of years ahead, human operators and oversight will still rule the roads, because the discrete human judgments that are essential while driving will still require a person with all of his or her faculties — and the attendant liability for when mistakes happen. Besides technical challenges, humans tend to be more forgiving about mistakes made by human intelligence as opposed to those made by artificial intelligence.”
Disappearing jobs
The second ‘unprediction’ is that people will not be replaced by AI bots this year. Dr. Reddy states: “While it is possible that artificial intelligence agents might replace (but more likely supplement) certain administrative tasks, the reality is that worker displacement by AI is over-hyped and unlikely.” So robots won’t be taking over most jobs any time soon.
This is because, the analyst states: “Even in an environment where Automated Machine Learning is helping machines to build machines through deep learning, the really complex aspects of jobs will not be replaced. Thus, while AI will help automate various tasks that mostly we don’t want to do anyway, we’ll still need the human knowledge workers for thinking, judgment and creativity. But, routine tasks beware: AI is coming for you!”
Medical diagnosis
The third aspect is that we won’t get AI-powered medical diagnoses. This is, Dr. Reddy says “Due to a lack of training data and continued challenges around learning diagnosis and prognosis decision-making through identifying patterns, AI algorithms are not very good at medical decision automation and will only be used on a limited basis to support but not replace diagnosis and treatment recommendations by humans.”
He adds: “AI will be increasingly deployed against sporadic research needs in the medical arena, but, as with fraud detection, pattern recognition by machines only goes so far, and human insight, ingenuity and judgment come into play. People are still better than machines at learning patterns and developing intuition about new approaches.”
Importantly: “People are still better than machines at learning patterns and developing intuition about new approaches.”
AI at work
The fourth and final area is that we will still struggle with determining where artificial intelligence should be deployed. Dr. Reddy states: “Despite what you might be hearing from AI solution vendors, businesses that want to adopt AI must first conduct a careful needs assessment. As part of this process, companies also must gain a realistic view of what benefits are being sought and how AI can be strategically deployed for maximum benefit.”
The analyst adds: “IT management, business users and developers should avoid being overly ambitious and carefully assess the infrastructure and data required to drive value from AI. Best practices and ‘buy versus build’ analysis also should be part of the conversations about implementing AI applications.”

What Is Missing From Big Data

This is an excellent TEDTalk on what is missing from bigdata (hint: it is the human element).

Why do so many companies make bad decisions, even with access to unprecedented amounts of data? With stories from Nokia to Netflix to the oracles of ancient Greece, Tricia Wang demystifies big data and identifies its pitfalls, suggesting that we focus instead on “thick data” — precious, unquantifiable insights from actual people — to make the right business decisions and thrive in the unknown.

An interesting (but not too surprising) stat from the intro is that 73% of all bigdata projects deliver no value.

Turn Off All Your Push Notifications

Really? Someone had to write a 500 word ‘article‘ about what should be common sense?

There’s a solution, though: Kill your notifications. Yes, really. Turn them all off. (You can leave on phone calls and text messages, if you must, but nothing else.) You’ll discover that you don’t miss the stream of cards filling your lockscreen, because they never existed for your benefit. They’re for brands and developers, methods by which thirsty growth hackers can grab your attention anytime they want. Allowing an app to send you push notifications is like allowing a store clerk to grab you by the ear and drag you into their store. You’re letting someone insert a commercial into your life anytime they want. Time to turn it off.

Welcome to Our Startup Where Everyone is 23 Years Old Because We Believe Old People Are Visually Displeasing and Out of Ideas 


This is hilarious because it is true. I’ve seen so many ‘startups’ spend a huge amount of money and effort trying to imitate the trappings of a startup rather than having original ideas and actually producing something. Here is a sample (more at the link above):

Hello, and welcome to our startup. We hope you’re enjoying your complimentary snifter of vaporized coconut water. Once you’re done, please place the glass into one of the blue receptacles around the office, which will send the glass to be washed and dried. Do not place it into one of the red receptacles. The red receptacles take whatever you put inside of them and launch it into space.

If you look to your left, you’ll see one of our employees using a state-of-the-art ergonomic sleeping desk. Most startups have standing desks, but we have sleeping desks, dancing desks, and even skateboarding desks. The skateboarding desks are just large skateboards you can use to skate around the office. Be careful while skating, though, because we don’t offer any sort of medical insurance, since our benefits budget all goes toward cool desks.

Volvo’s Electric Car Announcement

I think that Volvo’s announcement regarding electric vehicles (EVs) has been largely misunderstood or mis-reported as them stating that they will only have EVs by 2020. Actually, they stated that they will only design and release NEW EVs after that date. The existing stable of gasoline powered vehicles will continue to live on past 2020.

Headphones Evesdropping On You

This is an older story, but it has come around again recently.

Researchers at Israel’s Ben Gurion University have created a piece of proof-of-concept code they call “Speake(a)r,” designed to demonstrate how determined hackers could find a way to surreptitiously hijack a computer to record audio even when the device’s microphones have been entirely removed or disabled. The experimental malware instead repurposes the speakers in earbuds or headphones to use them as microphones, converting the vibrations in air into electromagnetic signals to clearly capture audio from across a room.

But, as it turns out, this is less of an out-and-out hack, but just simply taking advantage of a somewhat questionable ‘feature’:

But the Ben Gurion researchers took that hack a step further. Their malware uses a little-known feature of RealTek audio codec chips to silently “retask” the computer’s output channel as an input channel, allowing the malware to record audio even when the headphones remain connected into an output-only jack and don’t even have a microphone channel on their plug. The researchers say the RealTek chips are so common that the attack works on practically any desktop computer, whether it runs Windows or MacOS, and most laptops, too. RealTek didn’t immediately respond to WIRED’s request for comment on the Ben Gurion researchers’ work. “This is the real vulnerability,” says Guri. “It’s what makes almost every computer today vulnerable to this type of attack.”

Scalable Microservices

Here is an excellent, in-depth discussion on creating scalable microservices.

In this article, we will look at microservices, not as a tool to scale the organization, development and release process (even though it’s one of the main reasons for adopting microservices), but from an architecture and design perspective, and put it in its true context: distributed systems. In particular, we will discuss how to leverage Events-first Domain Driven Design and Reactive principles to build scalable microservices, working our way through the evolution of a scalable microservices-based system.

Reactions To Failure

Great article on system failures in IT and how groups/people react to them. Here is a summary:

tl;dr: Catastrophic system failures are remarkably common in IT-dependent environments. The reactions to such failures varies but is often some version of blame-and-train. There are a number of problems with blame-and-train but perhaps the most important is it is a form of organizational blindness that forestalls improvement.

Three things:

  1. These failures are markers of systemic brittleness, the inverse of resilience.
  2. The blame-and-train reaction is a diversion, a red herring, and counterproductive; it increases brittleness.
  3. There are productive reactions to failure but they are difficult to accomplish, especially when the failure has big consequences.

Serverless Approach To Testing

Here is a thought provoking article on testing in a serverless environment:

Serverless architecture uses a lot of services — hence why some prefer to call the architecture “service-full” instead of serverless. Those services are essentially elements of an application that are independent of your testing regime.

An external element.

A good external service will be tested for you. And that’s really important. Because you shouldn’t have to test the service itself. You only really need to test the effect of your interaction with it.

Here’s an example …

Let’s say you have a Function as a Service (e.g. Lambda function) and you utilise a database service (e.g. DynamoDB). You’ll want to test the interaction with the database service from the function to ensure your data is saved/read correctly, and that your function can deal with the responses from the service.

Now, the above scenario is relatively easy because you can utilise DynamoDB from your local machine, and run unit tests to check the values stored in the database. But have you spotted something with this scenario? It’s not the live service — it’s a copy of it. But the API is the same. So, as long as the API doesn’t change we’re ok, right?

To be honest, I’ve reached a point where I’m realising that if we use an AWS service, the likelihood is that AWS have done a much better job of testing it than I have. So we mock the majority of our interactions with AWS (and other) services in unit tests. This makes it relatively simple to develop a function of logic and unit test it — with mocks for services required.

Android Things Developer Preview Available

Here is a quick summary of what is new in the latest Android Things Developer Preview.

Earlier this month Google announced a partnership with AIY by releasing a co-produced build-your-own Google Home kit. Built on Google’s Raspberry Pi 3 developer board, the kit showcased Android Things’ ever-expanding features, particularly the integration of Voice Kit. Enabling developers to build a proper Voice User Interface (VUI) Voice Kit is an open-source platform which can integrate cloud services such as Google Assistant SDK or Cloud Speech API or simply run similar services directly on the device with Tensorflow – Google’s on-board neural-network.

Google also added some important drivers to the mix – most notably those necessary for implementing Google Assistant SDK on any certified development board. Also in tow is support for Inter-IC Sound Bus (I2S) which has been Added to the Peripheral I/O API. A Voice Kit sample for which is included, aimed at demonstrating the use of I2S for audio.

Developer Preview 4 will also bring new hardware, adding a Board Support Package for the NXP i.MX7D. Also, in a display of Android Things’ scalability, Google has released Edison Candle – a sample of custom hardware which fits modularly with SoM’s (system-on-modules) running the lightweight OS. Code for this sample is hosted on GitHub while hardware design files can be found on CircuitHub.

Things seem to be coming together quite well for Google’s IoT solution. With the 1.0 release of Tensorflow in February and I/O kicking off, we hope to see even bigger strides today.

Microservices Need Architects

Microservices Need Architects – An excellent article on the complexity of something with ‘micro’ in it’s name. And, yes, I know and I am here to help with over a decade of experience in service design and enterprise integration skills.

For the past two years, microservices have been taking the software development world by storm. Their use has been popularized by organizations adopting Agile Software Development, continuous delivery and DevOps, as a logical next step in the progression to remove bottlenecks that slow down software delivery. As a result, much of the public discussion on microservices is coming from software developers who feel liberated by the chance to code without the constraints and dependencies of a monolithic application structure. While this “inside the microservice” perspective is important and compelling for the developer community, there are a number of other important areas of microservice architecture that aren’t getting enough attention.

Specifically, as the number of microservices in an organization grows linearly, this new collection of services forms an unbounded system whose complexity threatens to increase exponentially. This complexity introduces problems with security, visibility, testability, and service discoverability. However, many developers currently treat these as “operational issues” and leave them for someone else to fix downstream. If addressed up front—when the software system is being designed—these aspects can be handled more effectively. Likewise, although there is discussion on techniques to define service boundaries and on the linkage between organizational structure and software composition, these areas can also benefit from an architectural approach. So, where are the architects?