Bet on machine learning

Companies like Google and Microsoft offer impressive machine learning capabilities in their public cloud products. This means artificial intelligence is significantly more accessible to any business than before.

How does it work?
At a high level, machine learning is a data analysis method which uses historical data, examples and experience to devise a model to automatically predict future outcomes (instead of hard-coded rules). The key is the "learning" part: the algorithm continues to evolve to make the predictions more accurate over time.

The traditional ways of machine learning involved more manual methods of developing models and algorithms. IBM's DeepBlue, for example, was programmed to learn to play chess in the 1990's (and beat the world champion). However, chess has a relatively small and finite set of moves per position (about 20) -- fairly easy to program a computer to learn through brute force.

Fast forward to 2016 and Google's DeepMind project AlphaGo. It utilizes sophisticated neural network algorithms, and was used to defeat the Go world champion. Go has about 200 moves per position, with more possible board configurations than there are atoms in the universe! This demonstrates the power of the neural network algorithm. Most importantly, it shows that general-purpose artificial intelligence can exist.

Neural networks mimic the learning process of the human brain. The AI from DeepMind uses a technique called Deep Reinforcement Learning. It learns from experience, using raw pixels as data input. AlphaGo was shown hundreds of thousands of Go games so it could learn from human players. Then Google had the AI play against itself 30 million times. Over time, it got better; to the point where one of the algorithms had an almost 90% win-rate against the other. That was the one selected.

Naturally, a human could never play 30 million Go games in their lifetime. The machine does not get tired, nor make emotional mistakes. The AI's experience becomes super-human, despite the fact it originally learned from humans.

Watch what happens when Google used the same algorithm to train the machine on the famous Atari game Breakout. The goal given to the machine was to maximize the score it could achieve in the shortest amount of time. At first, the AI is pretty terrible at the game. However, after about 2 hours of playing, it is very good. After 6 hours it does something amazing: it becomes super human.

Swiftkey, the makers of a keyboard app for mobile devices, nicely demonstrate how a neural network helps improve their word predictions.

Using ML in your organization

The ability to plug directly into some of Google's (and others' like Microsoft and Amazon) algorithms in the cloud make ML much more accessible. I am more familiar with Google's offerings, so will highlight a few:

Google's Cloud Vision API is image recognition in the cloud. It can detect what is occurring in images (including sentiment analysis of humans). A city in Canada trained Google's AI using thousands of school bus stop sign videos. The goal was to have the machine watch the videos and identify if a vehicle went passed the bus' stop sign illegally. The algorithm was trained to identify when the sign was out and active, and when vehicles had passed through it. It turned out to be 99% effective, while humans were only 83%. This resulted in increased revenue through traffic violation tickets.

Disney used Cloud Vision for their marketing campaign for the movie Pete's Dragon. The site set children on a hunt in their homes for common objects (like chair, door, tree, clouds, etc.). Once detected by the algorithm, Elliot the dragon would magically appear on the screen.

Google's natural language processing API is something which could be leveraged in the example given in my earlier blog post on data. By analyzing millions of public social media posts for certain sentiments and cues, the sales team can potentially land deeper leads.

Google also has a translation, audio-to-text, and even a new job search API.

Lastly, Google's open-source TensorFlow is a machine learning library for numerical computation using data flow graphs. Developers can use this to build models with very little code and eventually translate them into products in Google's cloud.

The future: humans + machines

I believe the businesses which adopt and master machine learning the best will be the most successful in the future, regardless of industry. (Of course, it helps to have a lot of data to train your model.)

While ML may eliminate some jobs, I feel it will be the successful partnership of humans and machines which will bring the most fruitful benefits. Take a radiologist, for example: she may leverage ML to assess her readings faster, but also provide additional oversight for deeper analysis. 

Ultimately, where the AI takes us is hard to predict, but the positive impact and advancements made will most certainly be exponential.

Do DevOps

DevOps is not a buzzword; it is the way quality software gets deployed fast.

In order for software teams to truly embrace DevOps, they must have an inherent continuous improvement culture which embraces ruthless amounts of automation. Many of my examples below will be Java-specific, but this can apply to all types of software languages.

The deployment pipeline
Your deployment pipeline is critical to enabling speed, so I will expand a bit more here. Some questions to ask yourself: How often do you deploy code to production? How long are your builds? How long does it take to do a production deployment? How often do we have bugs in production? Staging/UAT? Dev? The answers may vary based on many factors, but odds are, you can improve dramatically in all areas.

• Continuous integration. Enabling a distributed group of developers to integrate their local code into a shared development environment as efficiently as possible is the key first step. Generally a build server (like Jenkins or Bamboo) can help to enable this. Most importantly, though, are the automated tests which run on the code before moving it to development. These can be things like PMD or SonarQube which check for best practice violations, standards, or bugs. Similarly, unit, integration, and security tests can and should be run here. The key is code is not allowed to move to development until all tests are passed. We strive for quality, production-ready code even in development.
  
  
• Peer code reviews.* This is probably the only manual step of the deployment process. Having an additional pair of (usually senior- or architect-level) eyes helps to drive team standards, code re-use, scalability, security, and efficiency. Some teams may find it hard to incorporate this critical step, but it must become part of the process.
  
  
• Automated testing. Automated tests can occur at each stage, either with each build (depending on speed), or some regular rhythm (like nightly). These tests can be regression, smoke tests, integration, or performance tests. Visibility of the results are key, as test failures must be addressed promptly. Regular testing also helps to ensure tests stay current. As the test suite grows to have a comfortable percentage of coverage, code can move faster to production with less manual testing.
  
  
• Auto-build, auto-deploy. The build servers mentioned above can automate the process of building and deploying code to each environment. Moving to production may require additional steps due to segregation of duties and change controls. As a result, I recommend making everything standard changes -- this way a change control ticket can be opened automatically by the deployment process rather than requiring manual change controls to be approved. In the lower environments, builds and deploys can be scheduled automatically or occur automatically once new code is committed.
  
  
• Same artifact in each environment. Consistency is key in ensuring quality. Using the same artifact (or Docker image if you use Docker) throughout each environment minimizes variability.
  
  
• Visibility. It is important that with all of the above it is easily accessible and visible to all stakeholders -- from the project managers to the developers. Broken builds, for example, need to be remediated fast as they prevent code from moving for the other developers.
  
  
• Forward and back. Getting to production quickly is important, but it is also imperative to have a way to revert deployments fast. Your pipeline should support this.

Configuration management
Configuring and managing environments in a streamlined and automated fashion enables speed and consistency. Configuration management tools like Puppet or Chef enable centralized management of multiple servers at once. This is key to being able to quickly spin up or down new environments as needed, patch, or ensure the same settings are applied to each without individually tending to each.

These tools can also be used to push software to desktops. This is useful for a team of developers looking to ensure everyone has the same version and configuration of tools on their machines at all times. It also helps with installing those tools as it can literally be a simple double click and go get a cup of coffee.


Containers & container orchestration
Step aside VM's, containers are the new thing. Docker containers wrap your software in a complete filesystem. It is more lightweight than a VM, and enable speed through ensuring standardization of the environment. Their small size means you can have several containers inside one VM. The key point being that containers enable true application portability, as they abstract the underlying infrastructure from the app itself.

As your environment grows with more and more containers, orchestration tools like Kubernetes become important to help manage them all from a central place.


Situational awareness
It is key for the team to know the health of the system at all times. It encompasses the following:

• Monitoring. A constant pulse on the key metrics (response times, CPU usage, server memory, etc.) allows for quick identification of potential issues and can help prevent failures. Tools like Icinga can even automate the creation of monitors when setting up servers through Puppet, for example. I recommend making as much of these metrics visible using tools like Graphite, StatsD, and Grafana.
   
• Logging. Having additional details at hand help to give more insight into the various systems. Centralizing logging outputs using the ELK stack (Elasticsearch, Logstash, Kibana), or using tools like Takipi can help to reduce the time it takes to remediate issues.
  
  
• Alerting. In addition to visual dashboards, automated alerting of key thresholds plays a key role in ensuring timely resolution of issues. A tool like Seyren can be useful here in conjunction with Graphite.

Zero downtime
Who likes staying late or working on the weekend to push new code live? No one. One of the main reasons why this occurs is because many deployments incur downtime in some fashion. With a streamlined pipeline, and a little help from Docker, staying late may become a thing of the past.

When we push new code live, we launch a second Docker container in production and point only our internal network traffic to it using Vulcan. If all tests pass, we point all traffic to the new container (using Redis to maintain sessions) and we are live without any downtime! The same can be done in lower environments as well.


Conclusion
Ultimately we want to achieve a continuous delivery state, where code changes have the potential to go live very quickly, with high assurance of quality at each step. Visibility is key to this process, as it ensures everyone is on the same page.

Lastly, the term DevOps is the combination of Development and Operations. Traditionally development teams and operations teams have competing priorities: devs want to move code to production fast; ops wants to keep the environment stable. With DevOps, the developers take more ownership throughout the process, while operations get involved earlier, more automated tools, and better visibility of the pipeline. The partnership is what drives great business results.


*Side note on peer code reviews: There may be a times where code reviews seem a bit of a burden.

First, when refactoring is required/requested by the reviewing person. Refactoring is an important and natural part of keeping the code base in good order over time. There may be times when refactoring may not be possible due to time, which I would then suggest that a user story (requirement in Agile) is added to the top of the backlog and done in a subsequent sprint (keeping in mind that there is nothing more permanent than temporary code). If you are following Scrum, ensure your teams do not consider their user stories to be "done" until all the code review comments are addressed.

Second, when there are disagreements between the reviewer and the developer. This is pretty simple to resolve, especially when the reviewer is an architect -- the developer does what the architect says. Discussions are always welcome, but tie goes to the architect.

Creating the time to innovate -- Part II

I wanted to expand on my earlier post on creating more time. As I inherit or join new teams, the first deep-dive I do is an analysis on what people are spending their time on. The goal is to identify what can be eliminated, automated, or delegated to provide us time to do more impactful work.

Eliminate
I often tell folks, "Some parts of your role will be eliminated." I can sense fear in their eyes when I say that, so I quickly follow up with, "The goal is to eliminate the items which are not value-added work, so you have time to do more exciting and creative work."

The reaction I tend to get is no longer fear, but excitement, followed by a, "How...?"

The how is easier than you think. I propose taking an inventory of the work the team is doing, and assessing each item for its value and impact on the organization as compared to how much time is spent doing the task. It may become apparent some things which take a lot of time are not worth the value it is providing.

As an example, one team member told me each month for the past 2 years he worked on producing a set of reports for a particular group. It took him 2 days to compile the reports manually. I challenged him to identify if the reports are even being used or are still needed by that group. As it turns out, the reports were not being looked at any longer. He stopped creating the reports, and got 24 business days back each year.

Automate
Some things cannot be eliminated. Automate them.

Here are just a few items you should consider automating:

• Repetitive or common tasks
• Mindless items -- not requiring much human skill
• Anything considered a standard change (and if it is not standard, make it standard so it can be automated!)

The point is to let the machines do the work for you, so the team can focus on things which require more critical thinking and creativity.

Delegate

Having a single person be the sole holder of knowledge in a particular area can create bottlenecks. It means they may get pulled into urgent issues or other areas to help because no one else can. This is a time killer. They must spread their knowledge and delegate to others. 

Delegating can also occur in the reporting example I gave above. If those reports were still being used, perhaps the report creator could have devised a way for his business partners to view the details on their own. In other words, they can view or pull the reports whenever they needed without asking my team for help. An effective delegation.

Multi-tasking and context switching

We all want our teams to be 100% utilized. Why hire someone if they only will be working 75% of the time?

As a result, many managers ensure individuals on their team always have a full plate of tasks to complete. However, the size of a task rarely is calculated with context switching costs in mind.

Context switching costs
Neurologically, our brains are not wired to be multi-taskers. The brain simply switches from one task to another rapidly.

That shift comes with a cost. Our brains take time to re-adjust and focus on the new task.

Some neurologists say 10-20% of the time a task takes to complete can actually be wasted through context switching.

Take a Java developer for example. They may have a lot of variable names, functions, API's to remember for a particular product. Moving to another product requires almost a clean wipe of their short-term memory, and a gradual ramp-up of the knowledge of the new project.

Therefore, the goal is not piling on many tasks to ensure 100% utilization. Rather, it is to improve productivity through reducing context switching.

Reducing context switching
Ultimately, working on one thing at a time is the most effective way to reduce context switching. Other tips to consider:

• Asynchronous communication -- When things are not urgent, writing an email, for example, may be better than an IM or phone call. This allows the individual to stay focused on the task and respond when they are ready.
• Setting aside time -- Following on the item above, emails can become a distraction. Dedicating a set block of time during the day for emails or other non-project related work can help keep focus high when doing project work.
• Set expectations -- Let your colleagues know at certain times you may not be quick to respond. This can help take pressure off you to feel the need to constantly check emails.

Agile plays a huge part in minimizing context switching from a software development perspective. More on Agile in a future post.

The Kanban approach is also useful here. It stresses the important of a work in progress limit. Each individual can only work on a certain amount of tasks each day. Any more than that is added to the backlog. All tasks are prioritized, so there is no slow-down to figure out what to work on next. Our DevOps engineer uses Kanban, and he has a work in progress limit of two. More on Kanban in the future, too.

MVP: failing fast is a good thing

How many times has your team had a scenario similar to the following example?

A senior client says a product cannot launch until one particular feature is added. Her reasoning: "No one will ever use this product unless this feature is included."

Although small in size, the feature is quite complex and would require another 2 months of development effort. The team works tirelessly those two months, and launches the product shortly thereafter.

A few weeks after go-live, the analytics demonstrate an unfortunate reality: while the product overall is getting good traction, no customers are actually using the feature suggested by the senior exec.

This scenario is exactly what Eric Ries' book, The Lean Startup, tries to address. In it he assesses how successful software development companies build and launch products.

Minimum Viable Product (MVP)
Ries describes the MVP as the product whose minimum set of features allow for learning from early adopters. Using the MVP, we are able to avoid building products no one wants, and maximize the learning per dollar spent.

The image below takes us through Ries' build-measure-learn feedback loop. An idea is formed and then built and released as an MVP. That MVP contains measurements or ways to pull data which we can learn from. From there, the product team is prepared to act on that data, and pivot or iterate.

Through small increments we can continue to test hypotheses and build a better product by minimizing the time through the feedback loop. If a particular feature or iteration is not successful, we learn early in the process through facts (analytics, metrics, user feedback, etc.).

This means failing fast is a good thing! Validated learning means we do not have to wait months before we find out no one will use a particular feature. We spend more time on things we know the users will want.

Image credit: Eric Ries, TheLeanStartup.com

Putting it into practice
I like to think of MVP as happening at each phase of the software development life cycle, in addition to the product viewed as a whole.

Take the design phase, for instance. Low fidelity mock-ups (think black-and-white, hand-sketched) are key because they speed time through "the loop." The goal is to get feedback fast -- how can you get fast feedback if you're spending time perfecting the shade of blue a button should be?

When it comes to the product owner's vision for features in release planning, how many of them build on top of an unvalidated hypothesis? What can be built and released quickly as an MVP instead?

Teams must be prepared to iterate. This means we cannot launch something and forget about it. We must release our MVP's, analyze the results, and pivot (move in a different direction vs. our hypothesis) or iterate based on our learning.

It is important to remember software has no value until it is in the hands of the user. The MVP approach gets more engaging software to the users faster by adapting incrementally.

Creating the time to innovate -- Part I

I am frequently approached by leadership from other divisions asking how my teams find the time to be so innovative. I propose that it is not finding the time, but rather creating the time. We all need more time in the day, but if you create a culture which inspires quality, you will naturally have the time you've been looking for.

Culture
A culture of continuous improvement runs through my team's veins. When inefficiencies arise, the team identifies solutions to improve productivity.

Team members are encouraged to give back to the team (I call this "team community service") by proposing and implementing better ways of doing things. Generally it's about 20% of their time (equating to about 1 day per week).

The key is not assigning tasks nor me saying what to do, but rather giving each individual a blank slate to identify and contribute to the areas they are most passionate about. (See previous post about motivation.)

Quality
Where do we get the time to implement these solutions? We have a constant pulse on things which prevent us from working on value-add tasks. From here we identify where we need to simplify or improve quality. These improvements in quality add up to very large time savings.

At first the team uses this extra time to catch up on value-add work and achieve a consistent flow. However, once we achieve optimal flow, we use the extra time gained to continue to innovate, gradually reaching the magic 20% time for each individual.

Suggestions to get started
Analyze your team's errors, production bugs, defects, and other distractions which require someone to stop what they're doing and spend time fixing issues. Use the 80/20 rule to determine the 20% of items causing 80% of the issues, and start to eliminate them.

It may be difficult at first, but leverage key team member strengths and passions. Some folks will not mind putting in extra effort, especially if it means helping the team in the long run and working on something they enjoy.

Be sure to track your team's progress. Take a baseline of key metrics today (number of production defects, average time spent fixing issues, etc.), and track improvements along the way.

The key is to have a tipping point in mind: when do you stop giving the time saved back to "business as usual" work and start giving it to "team community service?" Some individuals may only be able to reach 10%, while others may reach 20% or more.

You will see that 10-20% of time spent on innovation and continuous improvement will produce 2-10x gains for your team in the long run. Create the time to do it.


Update: Read Part II of this topic here.

What motivates us

Daniel Pink challenges the conventional way of thinking about motivation. He points to research demonstrating larger rewards do not necessarily lead to better performance for tasks involving conceptual and creative thinking.

So what does motivate us?

Autonomy
No one likes a micro-manager. When things are 100% planned it equates to zero innovation. Self-direction, on the other hand, drives engagement.

Software company Atlassian provides developers 24 hours once a quarter to work on whatever they want, however they want. The only thing they must do is show their results to the company at the end of the 24 hours. This quarterly event has produced many new products, bug fixes, and productivity improvements which may never have emerged otherwise.

Mastery
Why do people play musical instruments? I learned to play the piano after college, not because I was getting paid for it (I wasn't), but because I enjoyed doing it and seeing my progress along the way.

Open source projects are another example here (think Wikipedia or Linux). Contributors to these projects do not get paid, many already have jobs, but challenge and mastery spark their desire to contribute.

Purpose
We want to be a part of something bigger than ourselves. This goes hand-in-hand with my post about the power of "why."

Skype's founder said, "Our goal is to be disruptive, but in the cause of making the world a better place." That is quite a purpose to get up and go to work for every day.

It is important to note that money is in fact a motivator. If you pay someone too little, that can be severely de-motivating. Pay someone enough to get the issue of money off the table and they can focus solely on their work.