Future of Software Development 


There are so many angles to this topic – and this is my third attempt in three days to organize my thoughts around it . The trouble is not that I don’t have enough ideas – it is that most ideas seem to contradict each other when I read them again .  Let’s see if the third time truly is the charm 🙂


1. Everyone will NOT  be a (meaningful) programmer in future 

I know that is not a popular position to take today – but that is where my mind is at now . We will need to water down the definition of coding significantly to make “everyone is a coder” be a true statement . If I can change the tires and oil of a car  , and program the infotainment system – should I be called an automotive engineer ? That is “roughly” how “everyone will be a coder” sounds to me now . 

Don’t get me wrong – I do think that understanding how code works is important for everyone in future . That doesn’t translate to everyone coding , at least in traditional sense . Very complex applications exist today in MS Excel – created by business analysts who are not traditional programmers . If we change the definition of coding to include that kind of development – I can buy into “everyone will be a coder”. The closer statement – though less sexy – would be “everyone will be a designer or modeler” !

2.   More code will be destructed than created 

World around us is changing extremely fast and that means we need lots of newer kind of applications . But the pace of change is such that no application can satisfy a customer for any length of time . Building better components and better orchestration mechanisms are the only way to deal with it . Neither concept is new – but the execution will kick into a higher gear . API designs will need a lot more flexibility than we are used to 

3. Performance will trump simplicity 

By simplicity – I mean what “humans” think of as “simple”, not machines . Code for tomorrow will be used more for machine to machine communication than for machine to human – by orders of magnitude . Creation of code itself might not need a lot of human help for that matter . And while maintainability and human readability are important today , it might get trumped by the need for extreme performance tomorrow  . For example – if both ends of an interface are machines , why would they need to communicate in text and pay for the overhead of things like XML/JSON tags that need to be converted to binary and back again to text ? 

4. You won’t need as much code in future 

A lot of code is written today because a human does all thinking and tells computers what to do in very prescriptive ways with conditions and loops and all that. When computers get to “general AI” – they will learn to think and adapt like humans – and won’t need step by step instructions to do what they do today . Less code will do a lot more than a lot of code does for us today . We may be decades away at most – we are not centuries away from that stage . Software will eat the world now , AI will eat software tomorrow 🙂

5. Software offshoring/outsourcing  will not be for development or maintenance – it will be for training 

It’s already possible for machines to learn from vast amounts of .  Some time in far future , machines will self train too . Till then – and that’s at least a decade or more – humans will need to train machines on data . And that will need to make use of local knowledge , labor arbitrage etc and hence will be an ideal candidate for offshoring and outsourcing ! 

6. Community of developers will be the only thing that matters  

Well – that is already true, isn’t it . I have forgotten the last time I have checked official documentation or real books to learn anything . I google or search on stack overflow to get most of what I need . I am not a full time developer – but looking at the communities that help me , I am sure full time developers do what I do , a lot more than I do 🙂 . A better way of mining this treasure trove of information is the need of the hour to get significantly more engineering productivity. 

7. More and more use of biological sensors 

Human bodies and brains are the ultimate computers and we are some ways away from mimicking human thought . In near future I expect simple sensors for all kinds of chemical and biological stuff ( how cool would smell be as an input , like touch is today ) that provide input to and also dictate how code should work . Text is fast becoming the most boring part of data any way 🙂

8. We haven’t even scratched the surface of parallelism 

What we call as massively parallel today in all probability will be amusing and funny to tomorrow’s programmers . The over heads of making parallelization work today is pretty high – and that will go away soon. A part of the problem is also that majority of developers don’t think of parallelism when they design code . I guess the near term solution will be for more primitives in popular programming languages (like for data access) to have built in parallelism . Note to self : get better at functional programming in 2017

9. Ethics and Privacy become core to all development 

A few things are happening together now

a) data is exploding and we are leaving our digital finger prints everywhere 

b) applications won’t stay around long enough to have ethics and privacy as a “future release” issue to be fixed

c) more and more software affects humans , but is controlled by machines with little human input 

d) access to information is (and will be ) universal – which means bad guys and good guys can both use it for what they want 

e) legal systems won’t ever catch-up with the pace of tech innovation 

And that means – ethics , privacy etc need to be core principles of tomorrow’s software . It cannot be “in pockets” as it happens today. And the education on this topic needs to be pushed down to even the earliest levels of schools. 

9 is really not a conventional number of bullets for a list – but given there won’t be anything conventional about the future of software development , I think now would be a good time for me to stop this list . Feel free to add , edit and challenge in the comments – I look forward to it .

Happy 2017 everyone!

CES 2017 – Random Thoughts On Future of APIs In An AI world


I spent half this week at CES 2017 in Las Vegas !

15844324_10210319385955546_7881371335845216256_n

To say the least, it puts the “enterprise” side shows to shame in number of people it attracts, variety of solutions it offers and how boldly the future is thought about. It did not take any time to see that the future is all about AI – and how expansive the definition of AI has become.

There were bots of all flavors there – but voice was the major interaction media, and it was hard to walk the floor without hearing “hey Alexa” type conversations . Also noticed a lot of VR and AR. I walked away thinking voice will rule the consumer world for a while, and between VR and AR – I will bet on AR having more widespread use. While VR based video games are indeed cool – putting on something on your head to use technology makes me wonder how many will actually use it. Like 3D televisions – where you need special glasses, and hardly anyone uses it that I know.

The generation of products using AI that I saw (admittedly I only saw a small fraction of the HUGE show) barely scratched the surface of what is possible. If I think of what I saw with my engineering hat on , it is something like this

  1. Human voice or text waking up the AI service ( “hey Jane” )
  2. A natural language based request ( “When is my next meeting” )
  3. Voice to text translation as needed
  4. Intent and entity extraction ( me, my calendar, current time, read entry)
  5. Passing it to a structured API ( calendar.read ) and get a response
  6. Convert output to a string ( “your next meeting is in 2 hours with Joe” )
  7. Text to voice translation
  8. Keep the context for next question ( “is there a bridge number or should I call Joe’s cell?” )

This is easy stuff in general – there are plenty of APIs that do stuff, and many are RESTful. You can pass parameters and make them do stuff – like read calendar, switch a light on , or pay off a credit card. If you are a developer – all you need is imagination to make cool stuff happen. How fun is that !

Well – there are also some issues to take care of. Here are 5 things that I could think of in the 1 hour in the middle seat (also in the last row, next to the toilet) from Vegas back home.

Like say security – you might not want guests to voice control all devices in your house for example (which might not be the worst they can do, but you know…). Most of the gadgets I saw had very limited security features . It was also not clear in many cases on what happens to data security and privacy. A consistent privacy/security layer becomes all the more important in the AI driven world for all APIs. 

Then there is Natural language itself. NLP itself will get commoditized very quickly. Entity and intent extraction are not exactly trivial – but its largely a solvable problem and will continue to get better. The trouble is – APIs don’t take natural language as input – we still need to pass unstructured>structured>unstructured back and forth to make this work. That is not just elegant – and it is not efficient even when compute becomes negligibly cheap. Not sure how quickly it will happen, but I am betting on commonly used API’s should all have two ways of functioning in future – an NLP input for human interaction, and a binary input for machine to machine interaction (to avoid any needs to translate when two machines talk to each other) . Perhaps this might even be how the elusive API standardization will finally happen 🙂

If all – or most – APIs have an easy NLP interface, it also becomes easy to interoperate. For example – if I scream “I am hungry” to my fridge, it should be able to find all the APIs behind the scenes and give me some options and place an order and pay for it. And my car or microwave should be able to do the same as well and I should not have to hand code every possible combination . In future APIs should be able to use each other as needed and my entry point should not matter as much in getting the result I need. 

Human assistants get better with time. If an executive always flies by American Air, when she tells her assistant to book a flight, the assistant does not ask every time back “which airline do you prefer” or “should I book a car service also to take you to the meeting when you land”. The virtual assistants – or pretty much any conversational widget – I saw this week had any significant “learning” capability that was demonstrated. While I might enjoy having a smart device today since it is a big improvement from my normal devices – I will absolutely tire of it if it does not get smarter over time. My fridge should not just be able to order milk – it should learn from all the other smart fridges and take cues from other data like weather . In future, “learning” should be a standard functionality for all APIs – ideally unsupervised. 

The general trend I saw at CES was about “ordering” a machine to do something. No doubt that is cool. What I did not see – and where I think AI could really help – is in machines “servicing” humans and other machines. For example –  lets say I scream “I am hungry” to my fridge. The fridge has some food in it that I like and all I need is to put it in the oven. So fridge tells the oven to start pre-heating – and gets no response in return ! Telling me “the oven is dead” is a good start – But the intelligent fridge should be able to place a service order for the oven, as well as offer me an option to order a pizza to keep me alive for now. APIs should be able to diagnose ( and ideally self heal ) themselves and other APIs in future – as well as change orchestration when a standard workflow is disrupted.