Software Engineers Coding AI May Code Themselves Out of a Job

"We know only two things about the future: It cannot be known and it will be different from what exists now and from what we expect." - Peter Drucker

The History of Computer programming can be traced back to 1801 when Joseph Marle Jacquard invented a mechanical, automated loom, the Jacquard Loom.  The Jacquard Loom used punchcards to control the operation of the loom. Today much of everyday life is controlled by the instructions typed into programs by Software Engineers that run computers of all sizes embedded into the fabric of our life.  We now have computers in our clocks that ring us awake, our showers that adjust our water temperature, our houses that know where we are and  turn our lights on and off, our cars that we drive to work and the toll scanners that track our drive. And at work most of what we do in the modern office is done using computers, including the copy machines, the telephones, our desktops and our security systems, computers are everywhere.  And these computers, no matter how tiny or big are run by programs typed in by a Software Engineer.

Artificial Intelligence (AI) describes a program written by a software engineer to enable computers to perform tasks commonly associated with intelligent beings. Tasks include the ability to learn, reason, discover meaning, generalize, or learn from past experience. This is much different from the static pre-AI programs that are stamped with a finite amount of intelligence and get smarter over time as new versions are released over time.  But pre-AI programs can't learn or reason or get smarter, or do anything they weren't programmed for and that is the big difference.  AI programs can actually update themselves.

AI will be the biggest wave of technology disruption the world has ever seen, dwarfing the Industrial Revolution.  In their paper "Artificial Intelligence: The Next Digital Frontier", the McKinsey Globlal Institute writes:

"Artificial intelligence is poised to unleash the next wave of digital disruption, and companies should prepare for it now. We already see real-life benefits for a few early adopting firms, making it more urgent than ever for others to accelerate their digital transformations. "

Although today, many repetitive manual tasks have been automated by computer programming there were still many repetitive manual tasks that required learning, reasoning, discovering meaning, generalizing, or learning from past experience, these tasks could not be automated by pre-AI programs.  The automation of these tasks using AI programming will start biggest wave of technology disruption the world has ever seen. Conner Forest in his article "The first 10 jobs that will be automated by AI and robots" list the following:

1. Assembly Line Worker
2. Field Technician
3. Call Center Worker
4. Sorter
5. Data Entry
6. Insurance Underwriter
7. Tax Preparer
8. Sales Representative
9. Translator
10. Fast Food Employee

In fact, as he reports in his article, the  Oxford Martin School in the UK estimates that roughly 47 percent of the total US jobs are at risk of computerization or automation.  

So what about the Software Engineers who are coding the AI programs that are automating all these jobs, is it possible that they might code an AI program that could in fact write and rewrite itself and automate the job of a Software Engineer.  This is in fact where AI is going.  Here are some example projects:

• Pliny - Autocomplete for software engineers. “Imagine the power of having all the code that has ever been written in the past available to programmers at their fingertips as they write new code or fix old code,” said Vivek Sarkar, Rice’s E.D. Butcher Chair in Engineering, chair of the Department of Computer Science and the principal investigator (PI) on the PLINY project. “You can think of this as autocomplete for code, but in a far more sophisticated way".
  
• ExCAPE - aims to change programming from a purely manual task to one in which a programmer and an automated program synthesis tool can collaborate to generate software that meets its specification.
  
• ai.codes - In our view, software engineering is about modeling and automating the real world. Coding, to a large extent, is the boring part of the job. Coding is not only tedious, but it's error-prone. Software bugs happen when we, human translators, fail to translate our ideas into codes correctly. We believe that AI is at a stage where it can help software engineers in writing code.
  
• AI Software learns to write AI Software - Google and others think software that learns to learn could take over some work done by AI experts.

The Enterprise Minimal Viable Product

'The MVP Paradox' good read, worth the time. In the article the authors define the Minimum Viable Product or MVP as a "reality check for founders so they don't end up wasting tons of time and money building something no one needs or will pay for".  The MVP is at the core of the Lean Startup movement but it's original design, to be customer-driven instead of being product-driven, has been cheated by Product Managers eager to get products out the door.  

The problem with the term Minimum Viable Product is that it doesn't have a hard and fast definition. The MVP has given Product Managers license to build things fast to save money, ship and repeat regardless of whether the product feature set is complete.  The goal of the MVP, to learn from customers to validate the business hypothesis, can't be achieved because customers won't spend time with a product that doesn't have a minimal set of features they need to do their work.  Instead of the sound of early adopters working through the product providing feedback we hear the sound of crickets, no one is using the product.  The next sprint starts and a list of features, unvalidated by the market, are tee'd for implementation in an attempt to provide enough value in the product to attract early adopters. This cycle continues iteration after iteration with little customer feedback, the process is broken.  As the authors state "Over pursuing your MVP this way can be the fastest way for your company to 'go broke saving money'".

The 'MVP Paradox' is particularly important to watch for in the Enterprise Market where product niches are relatively mature.  For example, introducing a new document management (DM) system would require the MVP have a feature set that at least competes with the entry level DM systems on the market, we call this the 'table stakes' to enter the market.  An MVP with anything less than the 'table stakes' would not be viable. After all, why would a customer struggle with your MVP if they could buy the entry level DM and have everything they need? Hopefully your MVP has some innovative feature or process but this would have to be in addition to the minimal feature set. So it's important to remember, especially in the Enterprise Market, that MVP's may take several sprints/iterations before they have the minimal feature set to ship to the market. I agree with the author's of 'The MVP Paradox', it would have served everyone better if we had named the 'Minimum Viable Product', the 'Minimum Awesome Product', than Product Owners would stop misunderstanding it as minimal features, laziness in user research, or unpolished experiences.

The Governor of Agile - User Stories

In Agile, a user story is a set of words that communicates a software feature from an end-users perspective. And that's an important distinction, it's from the end users perspective, in layman's terms, not some gobbledegook verse from a technical person trying to translate from real world to computer world.  This is an enlightening aspect of Agile, that engineers don't need gobbledegook, they do better with the customer voice. 

User stories are accumulated in a 'back log', a list of stories to be prioritized in 'back log grooming' meetings by Product Management, then estimated by the development team, and finally assigned to a sprint where they are actually implemented by the team.  User stories are the fuel that runs agile, without user stories there is nothing for Product Managers to groom, nothing for developers and QA to estimate and nothing for the team to implement and deliver, there is no fuel for the engine.  Many times user stories become the Governor of the velocity of the team, or how fast the team can produce, without enough user stories the velocity is less than optimal or in some cases I have seen zero, yes developers actually 'sitting on their hands' doing nothing. 

So if you are embarking on or are implementing an Agile development process pay close  attention to the fuel of your scrum, the user stories.  Who is writing them, refining them, breaking them up into smaller stories that can be more accurately estimated?  This can be your weakest link.

Perfect Process Doesn't Always Make Perfect Product

Agile is the evolutionary equivalent of the Neanderthal in human evolution, not quite perfect but sustainable.  This evolutionary milestone is a testament to the state of modern application and collaboration technology. We now have the tools to enable self organizing  cross-functional teams  to collaborate on requirements and solutions.  Tools like Slack, Confluence, Trello provide the collaboration channels these teams can use to follow the Agile process.  The Agile process is an iterative development process, where requirements and solutions evolve efficiently through collaboration and realignment, and each iteration delivers shippable product.

Early morning scrum meetings, sprints, backlog grooming, planning, estimation, demo and post mortem's the process is well defined but flexible.  But sometimes the process becomes the 'finger pointing at the moon' the team becomes more focused on the process than the product.  This is especially true of teams that don't follow and learn from their product as it is shipped into the market, as an MVP or simply a new version.  Without a feedback loop a system or process can't adjust it's performance to meet the desired output, or what the customer really wants, it just keeps putting out ... well stuff.  I have seen more than one highly efficient agile team follow an optimized process and produce bits that no one ever used, and it's a shame, customer feedback would have changed everything.  Spend more time looking at the product and not the process.