All transformations have to start from within. This session was an attempt to create awareness on Diversity and Inclusion.

"Shipping is not success; let it sail" has been my mantra. Many organizations fall into the trap of project-based thinking and for them launching a product/service is success. We should step back and ask, "by launching this product/service, has it created any value (economic or otherwise) for the business and/or customers?" If the answer is no/not-sure, then it's premature to celebrate. Organizations want to achieve certain goals, expressed via measurable outcomes. Unless we see quantitative progress on those outcomes, our job is not done.

In this session, Naresh will share his experience helping organizations shift from project/output based thinking to product/outcome-based thinking. Not just at one team level, but at the entire organization level. Once we have the thinking in place, then how do we create a governance model which brings transparency and encourages collective ownership.

With Functions as a Service (FaaS), the smallest billable unit of computation is a single function execution. It's a beautifully simple idea, rejecting the metaphor of a server, and freeing developers to design smaller and simpler services. We can iterate on our code with a high degree of isolation, without fear of affecting other parts of the system; deploy systems in seconds with zero downtime, and always be available regardless of load.

However, building serverless apps is relatively new and filled with complexity:

• Configuration tooling was designed for the last generation of computing metaphors (and often lags behind the releases of new functionality)
• AWS is massive and overwhelming with many similar, but not the same, products
• The web console is confusing, with divergent interfaces between interlocking services
• Deep proprietary knowledge is required to configure and maintain common infrastructure primitives

In this talk, Naresh will walk you through a new approach to architecting applications with plain text using arc.codes to create apps in minutes and subsequently deploy in seconds with zero downtime and unprecedented availability.

This talk is an inspiration from Brian LeRoux's presentation Architecture as Text: Setup AWS Lambda, API Gateway, SNS, and DynamoDB on Easy Mode at YOW! 2017 Conference.

The ability to get the latest greatest version of your product into the hands of users, safely and quickly in a sustainable way, a.k.a Continuous Delivery is the need of the hour for every enterprise out there. Over the years, we've got very good about Continuous Delivery for server-side, web-applications. However, it's not as streamlined for Mobile or Desktop Apps.

This talk will cover the typical aspects we need to address while setting up a Continuous Delivery culture in the context of a large-scale mobile app:

• SCM/Version Control: moving from Feature Branches to a trunk-based development model
• Build/Test Environments: Decentralising the build & test environments using Containers(Docker) and CI Server(Jenkins)
• Microservices Architecture: Segregating and containerize the micro-services. Also refactoring the mobile apps to be more container friendly.
• Device Farm: Setting up a mobile device farm (using STF or ADF)
• Code-reviews: Improving the quality of code-reviews (using SonarQube, PRBuilder & PRRiskAdvisor)
• Test Pyramid: Building the right Test Pyramid to get rapid feedback by creating different kinds of automated tests to align with the CI Pipeline
• Code Quality: Visualising the health of our code-base (using C3)

The ability to get the latest greatest version of your product into the hands of users, safely and quickly in a sustainable way, a.k.a Continuous Delivery is the need of the hour for every enterprise out there. Over the years, we've got very good about Continuous Delivery for server-side, web-applications. However, it's not as streamlined for Mobile or Desktop Apps.

This talk will cover the typical aspects we need to address while setting up a Continuous Delivery culture in the context of a large-scale mobile app:

• SCM/Version Control: moving from Feature Branches to a trunk-based development model
• Build/Test Environments: Decentralising the build & test environments using Containers(Docker) and CI Server(Jenkins)
• Microservices Architecture: Segregating and containerize the micro-services. Also refactoring the mobile apps to be more container friendly.
• Device Farm: Setting up a mobile device farm (using STF or ADF)
• Code-reviews: Improving the quality of code-reviews (using SonarQube, PRBuilder & PRRiskAdvisor)
• Test Pyramid: Building the right Test Pyramid to get rapid feedback by creating different kinds of automated tests to align with the CI Pipeline
• Code Quality: Visualising the health of our code-base (using C3)

Array-oriented Programming (AoP) dates back to 1960s.The fundamental idea behind AoP is that operations apply at once to an entire set of values. This allows the programmer to think and operate on whole aggregates of data, without having to resort to explicit loops of individual scalar operations. At ConfEngine.com, a platform for organising and managing technical conferences/events, we've been heavily influenced by the APL style of AoP. In our context, this means each function focuses on applying one transformation to an immutable array (ordered-map) and then spitting out a new array, which can be piped to another function thus achieving functional composition. This has allowed us to build a very modular, decoupled design, which is extremely simple to reason about.

If you think of typical web-apps, they are generally CRUD applications. Data comes in, you apply a set of transformation and you pass it to someone else via an API or you save/query a data store. And on the way out, you get data from somewhere (data-store, API, etc.), apply a set of transformations and render the transformed data as HTML or JSON. Now we can visualise most web-apps using standard Pipe-and-Filter Architecture. With this, applying some of the functional programming concepts becomes more intuitive.

At ConfEngine.com, we use the standard LAMP stack. We've used PHP's philosophy of shared-nothing-architecture to address concurrency and scalability concerns. PHP itself has all the basic ingredients required for Functional Programming - first-class, higher-order functions, lambda, closures, partial functions, recursion and so on. We use array (ordered-map) to hold the data. PHP provides 79 array functions that allows you to do pretty much everything you need to in terms of transforming arrays including map, reduce, filter, merge and so on. One needs to be careful, but most of these are pure, higher-order functions.

If you are interested to learn more about AoP, I'll give a walk through of our design. Also I'll take a couple of problems to explain how to think in terms of AoP and how its really helps with functional programming.

As developers, we often shy away from making changes to existing (legacy) code base due to the fear of breaking existing functionality. While we've enough industry wisdom on how to refactor large monolithic applications, its usually hard to find team members, who can champion the cause. For many folks, refactoring code without having automated tests can be scary. And quite often, it ends up being an egg-and-chicken problem, .i.e. to write tests one needs to refactor the code. But to refactor the code, we first need tests. Even if we break the egg-and-chicken problem, where do we start and how do we visualise the progress, becomes a big challenge.

This hands-on workshop will equip you with the necessary tools, technique and skills to confront legacy code. It teaches you how to use various safe-refactoring strategies, while breaking dependencies and writing first few scaffolding tests to guide your excavation. These techniques are very useful to get existing code safely under test for refactoring. You will also learn how to use these techniques in conjunction with TDD to breathe new life into large existing code bases.

You have a great idea and you want to build the product and launch it in market as soon as possible. Before anyone else can launch it. Great! But building the product takes time, money and opportunity cost. While building and launching a successful product, several things can go wrong:

• Have you really understood the core problem from the user's point of view?
• Will your users like the user experience?
• Have you validated your core-loop which makes your product very engaging?
• Is your business model flushed out and validated?
• And so on...

So how do you minimise these risks? 

In this 90 mins workshop, you will run some real tests with real users to de-risk yourself and gain validated learning.

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.

Over the last few years, as agile has gained traction inside the enterprises, we've seen many scaling frameworks have sprung up. These scaling frameworks claim to retain the core agile values & principles and aim to provide a simple yet comprehensive way to scale agility across the organisation. There have been several success case-studies that have been published. We also hear and see many horror stories of failed scaling attempts. 

In this panel, let's have a critical view of the entire scaling framework eco-system.

Today over 100 million users share over 40 billion messages per month on Hike. Its not just simple 1:1 chat messages. Users can do Video Call, VoIP call or share rich multi-media content in 8 different languages in group chats with hundreds of members. User can transfer large (upto 100 MB) file using Wifi-Direct .i.e. device to device file transfer without using Internet. And many more features. Consumer product companies, who build mobile applications are under constant pressure to deliver new experiences, faster with a lot of experimentation and analytics baked in. How do you support various features at differing maturity levels? How do you ensure that you can roll out a release every month without breaking any of these features?

"Experiment. Learn. Repeat."  is one of the core values of Hike as an organisation. We are very much obsessed with delivering user delight and we follow an experiment based model to gather user feedback for our rollouts. 

In this conversation, we would like to offer some insights to how engineering@Hike has been incorporating agile development philosophy in order to keep raising the quality bar and repeatedly deliver user delight.

Depending on the people in the room, we would either do a panel or a birds of feather session. We'll be agile and decide on the last responsible moment!

We've several conference attendees who would show how they've used Functional Programming to do something really awesome! If you are trying to convince other people to use Functional Programming, you should watch these demos and show them these demos.

Refactoring is a series of small steps, each of which changes the program’s internal structure without changing its external behaviour. Refactoring, as a tool, to automate behaviour-preserving transformations to source code are not only very popular in agile development environments, but have been widely established as a cornerstone of the daily software development process, regardless of the methodology being used. Most major development environments such as Eclipse offer a set of powerful refactoring to substantially increase development productivity. 

In this live demo, I’ll show 

• the real value of refactoring,
• how we practice it safely,
• when and why we refactor,
• the power of refactoring tools and
• when we avoid refactoring.

I’ll be using two real-world examples of refactoring and sharing what I’ve learned about this important practice of the last 15 years.

Q & A with the Selenium Committee

Hike is used by 100 Million users and many of our users have cheap smart phone (~ $120 USD) that can install no more than 3 mobile apps.

So the questions is: Should testing of app be limited to its functionality? At Hike, we believe "Performance is Queen!" For our users, if we misuse the critical resources such as Battery, CPU, Network and Memory, its a deal-breaker. Hence pref-testing is very important.

During the initial days of Hike, we were very reactive and only did (manual) perf testing, when our users reported issues.

Now, every Sprint (2 weeks) and every public release (monthly), we run our automated perf tests. We measure our app's performance using several app specific use-cases on 4 key areas:

• CPU,
• Memory,
• Battery and
• Network (data consumption.)

We also benchmark the following scenarios for app latency:

• App launch time upon Force Stop
• App launch time upon Force Kill
• App's busiest screen openning time
• Scrolling latency in different parts of the app
• Contact loading time in Compose screen

We still have a long way to go in terms of our pref-testing journey at Hike. But we feel, we've some key learnings, which would be worth while to share with the community. Join us, for a fast paced perf-testing session.

Today over 100 million users share over 40 billion messages per month on Hike. Its not just simple 1:1 chat messages. Users can do a VoIP call or share rich multi-media content in 8 different languages in group chats with hundreds of members. User can transfer large (upto 100 MB) file using Wifi-Direct .i.e. device to device file transfer without using Internet. And many more features. How do you ensure that you can roll out a release every month without breaking any of these features?

With such a large user based, which is very sensitive to frequent upgrades due to data consumption cost, rigorously testing the app becomes extremely critical.

When we started our automation journey in 2014, we were looking for a device lab which can simplify our testing effort. However we gave up and ended up building our own setup. The reason being, we require multiple devices that can communicate with each other for a single test. And we have 6000+ such tests, which we want to run in parallel. While many device labs allow you to run tests in parallel, they don't allow the devices to communicate with each other. Also its not possible to run the same test across multiple devices. Imagine testing a group-chat flow with photo sharing or imagine the device to device file transfer using hotspot. How would you test these features?

If this interests you, join us and we'll share our learning trying to achieve this at Hike.

Over the past decade, eXtreme Programming practices like Test-Driven Development (TDD) & Behaviour Driven Developer (BDD), Refactoring, Continuous Integration and Automation have fundamentally changed software development processes and inherently how engineers work. While TDD has seen a great adoption on server side, developers still find it hard to apply TDD for developing UI components.

In code walk-thru where Naresh will build a web commenting and discussion feature (like Disqus) in React.js, 100% test driven. He will also demonstrate how TDD will help us drive an object-functional design to strike a pragmatic balance between the Object-Oriented and Functional Programming paradigms.

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.