
Naresh Jain
Specialises In
Developer...Consultant...Conference Producer...Startup Founder…struggling to stay up-to-date with technology innovation. Null Process Evangelist.
Naresh Jain is an internationally recognised Technology & Product Development Expert. Over the last 15 years, he has helped many Unicorns and fortune 500 companies like Jio, Google, Amazon, JP Morgan, Hike, Directi, HP, Siemens Medical, GE Energy, Schlumberger, Shell, Dell, EMC, CA Technologies, etc. to streamline their product development. His hands-on approach of coaching teams by focusing on product discovery and engineering excellence is a key differentiator. In a nutshell, hire him as a lead-by-example type leader, who can help you build awesome, digital-native products and service. Learn more about his expert services.
Naresh is the founder of a consulting business called Xnsio, which helps organisations build the essential product, technology & people capabilities required to transform their business for the digital world. He is also responsible for building ConfEngine.com - one-stop conference/event management platform.
Check out our awesome products!

In 2004, Naresh started the Agile movement in India by creating the Agile Software community of India, a registered non-profit society to evangelise Agile, Lean and other Leading-Edge Software Development methods in India. He is responsible for creating and organising 100+ international conferences including the Functional Conf, Open Data Science Conference, Simple Design And Testing Conference (SDTConf), Agile Coach Camp, Selenium Conf India, Appium Conf, jQuery and Open Web Conference and Eclipse Summit India. He started many Agile User Groups including TechJam, Agile Philly User Group, and groups in India.
In recognition of his accomplishments, in 2007 the Agile Alliance awarded Naresh with the Gordon Pask Award for contributions to the Agile Community.
Learn more about Naresh at nareshjain.com or xnsio.com
-
keyboard_arrow_down
Contract Driven Development: The Death of Integration Hell
40 Mins
Talk
Intermediate
In a complex, interdependent eco-system, where each service is evolving rapidly, we typically end up with an Integration Hell .i.e. the myriad problems that occur when API integrations break down
- Provider and consumer integrations break when their understanding of the API endpoints are out of sync
- Working integrations break when the API developer makes a change without informing the consumer
- Development and testing slow down when the consumer depends on the provider API running in a staging environment:
- The network may be down
- The environment hosting the API may be down
- The staging API may crash, or may not even be started
- Development can be delayed if the staging API is not kept up-to-date
- API changes can come in at the last minute, resulting in breakage on the consumer side
- The provider API may break backward compatibility, resulting in breakage on the consumer
Instead, what if we could make the dependencies between the provider and consumers explicit in the form of executable contracts. These executable contracts provide a common, clear definition of their API endpoints. They give instantaneous feedback about accidental breakage to the teams so that they can work independently. These executable contracts are:
- Kept up-to-date and acts as a single source of truth
- Used for service virtualisation, keeping consumers in sync with the contract
- Run as tests against the provider API to validate it's request and response type definitions
- Tightly integrated with CI
- Capable of pinpointing any backwards-incompatible changes to the contract
This is Contract Driven Development, and it heralds the Death of Integration Hell.
Here's a sample contract:
This session will demonstrate all the key points of Contract Driven Development as implemented by the teams using an open-source tool called Qontract.
-
keyboard_arrow_down
Contract Driven Development: The Death of Integration Hell
45 Mins
Demonstration
Intermediate
In a complex, interdependent eco-system, where each service is evolving rapidly, we typically end up with an Integration Hell .i.e. the myriad problems that occur when API integrations break down
- Provider and consumer integrations break when their understanding of the API endpoints are out of sync
- Working integrations break when the API developer makes a change without informing the consumer
- Development and testing slow down when the consumer depends on the provider API running in a staging environment:
- The network may be down
- The environment hosting the API may be down
- The staging API may crash, or may not even be started
- Development can be delayed if the staging API is not kept up-to-date
- API changes can come in at the last minute, resulting in breakage on the consumer side
- The provider API may break backward compatibility, resulting in breakage on the consumer
Instead, what if we could make the dependencies between the provider and consumers explicit in the form of executable contracts. These executable contracts provide a common, clear definition of their API endpoints. They give instantaneous feedback about accidental breakage to the teams so that they can work independently. These executable contracts are:
- Kept up-to-date and acts as a single source of truth
- Used for service virtualisation, keeping consumers in sync with the contract
- Run as tests against the provider API to validate it's request and response type definitions
- Tightly integrated with CI
- Capable of pinpointing any backwards-incompatible changes to the contract
This is Contract Driven Development, and it heralds the Death of Integration Hell.
Here's a sample contract:
This session will demonstrate all the key points of Contract Driven Development as implemented by the teams using an open-source tool called Qontract.
-
keyboard_arrow_down
Q & A Panel Discussion with Code Beam Lite India Speakers
Naresh JainFounderXnsioAndrea LeopardiCore Team MemberElixir LangBruce TateFounderGroxioMohammad Maqbool AlamStudentGuru Gobind Singh Indraprastha UniversityNikhil MoreSr. EngineerVolansysRavi Chandra PadmalaPartnernilensoSujatha HemmadyTech LeadRedbusschedule 1 year ago
Sold Out!45 Mins
Talk
Beginner
During the Code Beam Lite conference you might have had questions that did not get answered, this is your opportunity to get them answered by our expert panel group
-
keyboard_arrow_down
Q & A Session With Functional Conf Speakers
Naresh JainFounderXnsioAaron W HsuComputer ScientistIndiana UniversityAndrea LeopardiCore Team MemberElixir LangBruce TateFounderGroxioEdward KmettResearch EngineerMachine Intelligence Research InstituteSaurabh NandaFounderVacation Labsschedule 1 year ago
Sold Out!45 Mins
Keynote
Beginner
During the conference you might have had questions that did not get answered, this is your opportunity to get them answered by our expert panel group
-
keyboard_arrow_down
Setting up Continuous Delivery Pipeline for a Large-Scale Mobile App
50 Mins
Talk
Intermediate
Hike is a mobile-first, messaging platform that is used by 100 million users to exchange 40 billion messages/month. Hike app is available on Android, iOS and Windows phone. On the back-end, we’ve 100+ macro-services in Java, Python, Ruby, Go and Elixir. While setting up a Continuous Delivery pipeline, we ran into a series of technical challenges. However it was more important to address the organisational/behavioural challenges to ensure a sustainable culture shift in the company.
In this talk, I’ll explain how we went about:
- Setup a trunk-based development model
- Decentralised our build & test environments using Docker and Jenkins
- Segregated and containerised our macro-services
- Refactored the mobile apps to be more container friendly
- Setup a mobile device farm using STF
- Improved the quality of code-reviews using PRBuilder & PRRiskAdvisor
- Created different kinds of automated tests to align with our CI Pipeline and get rapid feedback
- Finally how we used C3 to visualise the health of our code-base
-
keyboard_arrow_down
Ethical AI - Fishbowl
45 Mins
Keynote
Beginner
There has been a lot of concerns about the black-box nature of AI. People have been asking for a sensible AI guideline with the weight of Law behind it. In April 2019, the EU released it's Ethics guidelines for trustworthy AI. Before that during the Obama administration, the National Science and Technology Council came up with its own set of broad guidelines called "Preparing for the Future of Artificial Intelligence."
Most of these cover an impressive amount of ground in several major categories:
- Transparency: Any time an AI system makes decisions on a user's behalf, that person should be aware of it. The reasoning behind decisions should be easily explainable.
- Safety: AI systems should be designed to withstand attempted hijacking and other attacks performed by hackers.
- Fairness: Decisions made by AI systems should not be influenced by gender, race or other personal identifiers. They should be as impartial as possible and not reflect human biases.
- Environmental stewardship: Not all the stakeholders in AI development are human. The development of these platforms and the implications of their decision-making and sustainability should take into account the needs of the larger environment and other forms of life.
- And so on...
At this conference, we would like to bring our experts together to hear their views/concerns on this topic.
-
keyboard_arrow_down
Welcome Address
20 Mins
Keynote
Beginner
This talk will help you understand the vision behind ODSC Conference and how it has grown over the years.
-
keyboard_arrow_down
Welcome Address
-
keyboard_arrow_down
Q&A with the Appium Committee [Panel]
45 Mins
Keynote
Intermediate
Q & A with the Appium Committee:
- Bruno Alassia
- Christian Bromann
- Dan Cuellar
- Dan Graham
- Jason Haggins
- Jonah Stiennon
- Jonathan Lipps
- Kazuakai Matsuo
- Sai Krishna
- Srinivasan Sekar
Dan Cuellar & Naresh Jain would moderate this panel.
-
keyboard_arrow_down
Setting up Jenkins CI Pipeline using Appium tests for Android and iOS
45 Mins
Demonstration
Beginner
GUI and functional tests determine if the product is working correctly from an end user perspective. With increasing number of automated GUI tests we would want to automate when and where they are executed. Continuous Integration helps in merging code to a centralised repository frequently and find out issues early in development cycle in order to help push quality upstream.
In the talk, you will see examples of how you can setup CI system for Android and IOS native/hybrid apps and how to plugin your Appium tests in the pipeline using Jenkins. We will also talk about the challenges we face while setting it up for Android and IOS applications. We will also talk about how to strengthen your CI pipeline via integrating various tests and Static code analysis tools.
-
keyboard_arrow_down
Organisational Resilience - Design your Organisation to Flourish NOT merely Survive
45 Mins
Case Study
Executive
A resilient organizational can not only adapt and respond to incremental change but more importantly, can respond to sudden disruptions and also, be the source of disruption in order to prosper and flourish.
The traditional risk management approach focuses too much on defensive (stopping bad things happen) thinking versus a more progressive (making good things happen) thinking. Being defensive requires consistency across the organization and this is where methodologies like Plan-Do-Check-Act (PDCA) come in. However, PDCA approach does not bake in the required progressive thinking and flexibility required for a fast company organization which operates in a volatile environment.
Professor David Denyer of Cranfield University has recently published a very interesting research report on Organizational Resilience. He has identified the following four quadrants across to help us think about organizational resilience:
- preventative control (defensive consistency)
- mindful action (defensive flexibility)
- performance optimization (progressive consistency)
- adaptive innovation (progressive flexibility)
In this talk, I'll share my personal experience of using this thinking to help an organization to scale their product to Millions of users. I've dive deep into how we structured our organization for Structural Agility and how we set-up a very lightweight governance model using OKRs to drive the necessary flexible and progressive thinking.
-
keyboard_arrow_down
Improving the Quality of Incoming Code
45 Mins
Case Study
Intermediate
Looking to move to Continuous Delivery? Worried about the quality of your the code? Helping your developers understand clean-code practices and getting the right testing strategy in place can take a while. What should you do to control the quality of the incoming code till then? This talk shares our experience of using PRRiskAdvisor to gradually educate and influence developers to write better code and also help the code reviewer to be more effective at their reviews.
Every time a developer raises a pull-request, PRRiskAdvisor analyzes the files that were changed and publishes a report on the pull request itself with the overall risk associated with this pull request and also risk associated with each file. It also runs static code analysis using SonarQube and publishes the configured violations as comments on the pull request. This way the reviewer just has to look at the pull request to get a decent idea of what it means to review this pull request. If there are too many violations, then PRRiskAdvisor can also automatically reject the pull request.
By doing this, we saw our developers starting paying more attention to clean code practices and hence the overall quality of the incoming code improved, while we worked on putting the right engineering practices and testing strategy in place.
-
keyboard_arrow_down
Dark Side of Collaboration
40 Mins
Talk
Advanced
On Agile teams, collaboration is the way of life. Our leaders want their team members to work closely with each other, have shared goals and even think as one entity. Why? Because we believe that collaboration leads to happier, more productive teams that can build innovative products/services.
It's strange that companies use the word collaboration very tightly with innovation. Collaboration is based on consensus building, which rarely leads to visionary or revolutionary products/services. Innovative/disruptive concepts require people to independently test out divergent ideas without getting caught up in collaborative boardroom meetings.
In this presentation, Naresh Jain explores the scary, unspoken side of collaboration and explains in what context, collaboration can be extremely important; and when it can get in the way or be a total waste of time.
-
keyboard_arrow_down
Unanswered Questions - Ask the Experts!
Naresh JainFounderXnsioDr. Arun VermaSr. Quantitative Researcher & Head of Quant Solutions TeamBloomberg L.P.Dr. Denis BauerTeam Leader Transformational BioinformaticsCSIROFavio VázquezSr. Data ScientistRaken Data GroupSheamus McGovernFounderOpen Data ScienceDrs. Tarry SinghCEO, Founder & AI Neuroscience Researcherdeepkapha.aiDr. Tom StarkeCEOAAAQuantsDr. Veena MendirattaResearch LeaderNokia Bell Labsschedule 2 years ago
Sold Out!45 Mins
Keynote
Beginner
Through the conference, we would have heard different speaker's perspective and experience with Data Science and AI. In this closing panel, we want to step back and look at any unanswered questions that the audience would have.
-
keyboard_arrow_down
Welcome Address
20 Mins
Keynote
Beginner
This talk will help you understand the vision behind ODSC Conference and how it has grown over the years.
-
keyboard_arrow_down
Improving the Quality of Incoming Code
25 Mins
Talk
Intermediate
Looking to move to Continuous Delivery? Worried about the quality of your the code? Helping your developers understand clean-code practices and getting the right testing strategy in place can take a while. What should you do to control the quality of the incoming code till then? This talk shares our experience of using PRRiskAdvisor to gradually educate and influence developers to write better code and also help the code reviewer to be more effective at their reviews.
Every time a developer raises a pull-request, PRRiskAdvisor analyzes the files that were changed and publishes a report on the pull request itself with the overall risk associated with this pull request and also risk associated with each file. It also runs static code analysis using SonarQube and publishes the configured violations as comments on the pull request. This way the reviewer just has to look at the pull request to get a decent idea of what it means to review this pull request. If there are too many violations, then PRRiskAdvisor can also automatically reject the pull request.
By doing this, we saw our developers starting paying more attention to clean code practices and hence the overall quality of the incoming code improved, while we worked on putting the right engineering practices and testing strategy in place.
-
keyboard_arrow_down
Improving the Quality of Incoming Code
40 Mins
Case Study
Intermediate
Looking to move to Continuous Delivery? Worried about the quality of your the code? Helping your developers understand clean-code practices and getting the right testing strategy in place can take a while. What should you do to control the quality of the incoming code till then? This talk shares our experience of using PRRiskAdvisor to gradually educate and influence developers to write better code and also help the code reviewer to be more effective at their reviews.
Every time a developer raises a pull-request, PRRiskAdvisor analyzes the files that were changed and publishes a report on the pull request itself with the overall risk associated with this pull request and also risk associated with each file. It also runs static code analysis using SonarQube and publishes the configured violations as comments on the pull request. This way the reviewer just has to look at the pull request to get a decent idea of what it means to review this pull request. If there are too many violations, then PRRiskAdvisor can also automatically reject the pull request.
By doing this, we saw our developers starting paying more attention to clean code practices and hence the overall quality of the incoming code improved, while we worked on putting the right engineering practices and testing strategy in place.
-
keyboard_arrow_down
Lessons Learned by Quitting TDD
40 Mins
Case Study
Advanced
By working with some of the most successful tech-product companies, I realised that code is NOT an asset, it's a liability. We should strive hard to minimise code. In 2011, when I started to hack on ConfEngine, I questioned my belief in TDD. I had also started playing around with APL style Array-Programming and Functional Programming. I felt, may be, I was getting a bit too dogmatic about TDD and automated tests in-general. As a thought experiment, I decided to build ConfEngine without ANY automated test. At first, it was really scary not to have the safety-net of automated test (something I took for granted for almost a decade.)
As I scaled ConfEngine without any automated tests, I had certain interesting realisations:
- How to embrace Simplicity and Minimalism WITHOUT automated tests
- Why Throwing Away Code frequently helps you achieve a better decoupled-design and how this helps in better experimentation
- Fear of Refactoring WITHOUT Tests is over-rated (Good IDE and safe-refactoring techniques can take you a long way)
ConfEngine grew from a pet-project to a 8 member product team. It has over 60K users and has done financial transactions worth over half-million USD. And we continue to push forward without ANY automated tests. Its not perfect, but it has certainly helped me challenge my dogma around TDD.
Background: In 2001, I stumbled upon the Test Infected paper. For the next 2 years, I struggled to really apply the test-first concept on real projects. Finally in 2003, I felt that I had fully internalised TDD and was able to apply on almost all projects. Then I started playing around with FIT and FitNesse, using ATDD on some of the projects. In 2006 I published "Avatars of TDD" paper in which I explained various styles of TDD and its design implications. Until 2011, I was a very big advocate of TDD, ATDD and BDD. I still like those practices, however I would not recommend it in all projects.
-
keyboard_arrow_down
Lessons Learned by Quitting TDD
25 Mins
Talk
Advanced
By working with some of the most successful tech-product companies, I realised that code is NOT an asset, it's a liability. We should strive hard to minimise code. In 2011, when I started to hack on ConfEngine, I questioned my belief in TDD. I had also started playing around with APL style Array-Programming and Functional Programming. I felt, may be, I was getting a bit too dogmatic about TDD and automated tests in-general. As a thought experiment, I decided to build ConfEngine without ANY automated test. At first, it was really scary not to have the safety-net of automated test (something I took for granted for almost a decade.)
As I scaled ConfEngine without any automated tests, I had certain interesting realisations:
- How to embrace Simplicity and Minimalism WITHOUT automated tests
- Why Throwing Away Code frequently helps you achieve a better decoupled-design and how this helps in better experimentation
- Fear of Refactoring WITHOUT Tests is over-rated (Good IDE and safe-refactoring techniques can take you a long way)
ConfEngine grew from a pet-project to a 8 member product team. It has over 60K users and has done financial transactions worth over half-million USD. And we continue to push forward without ANY automated tests. Its not perfect, but it has certainly helped me challenge my dogma around TDD.
Background: In 2001, I stumbled upon the Test Infected paper. For the next 2 years, I struggled to really apply the test-first concept on real projects. Finally in 2003, I felt that I had fully internalised TDD and was able to apply on almost all projects. Then I started playing around with FIT and FitNesse, using ATDD on some of the projects. In 2006 I published "Avatars of TDD" paper in which I explained various styles of TDD and its design implications. Until 2011, I was a very big advocate of TDD, ATDD and BDD. I still like those practices, however I would not recommend it in all projects.
-
keyboard_arrow_down
Organisational Resilience - Design your Organisation to Flourish NOT merely Survive
25 Mins
Case Study
Executive
A resilient organizational can not only adapt and respond to incremental change but more importantly, can respond to sudden disruptions and also, be the source of disruption in order to prosper and flourish.
The traditional risk management approach focuses too much on defensive (stopping bad things happen) thinking versus a more progressive (making good things happen) thinking. Being defensive requires consistency across the organization and this is where methodologies like Plan-Do-Check-Act (PDCA) come in. However, PDCA approach does not bake in the required progressive thinking and flexibility required for a fast company organization which operates in a volatile environment.
Professor David Denyer of Cranfield University has recently published a very interesting research report on Organizational Resilience. He has identified the following four quadrants across to help us think about organizational resilience:
- preventative control (defensive consistency)
- mindful action (defensive flexibility)
- performance optimization (progressive consistency)
- adaptive innovation (progressive flexibility)
In this talk, I'll share my personal experience of using this thinking to help an organization to scale their product to Millions of users. I've dive deep into how we structured our organization for Structural Agility and how we set-up a very lightweight governance model using OKRs to drive the necessary flexible and progressive thinking.
-
No more submissions exist.
-
No more submissions exist.