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.

What started off as a trial-and-error approach to improve the state of software development by a bunch of tinkerers, is today dominated by management consultants, "Thou-Shall" codified frameworks and rigid, expensive tools. Over the last 20 years, we've gone from, "I'm not sure, let's try this in a small-safe environment" to "you/your-team sucks; you guys have a very poor agile maturity because you are not doing _x_y_z_ (not conforming to the standards)." Along the way, we've lost the purpose of being agile .i.e. to embrace uncertainty and simplicity. Instead we've been forced to believe that consistency via top-down standardisation and predictability by increasing the rigour on process is our eternal quest. Anything that sounds simple and works 80% of the cases is discarded as being naive. What once drove thought-leader into agile, is now driving them insane. This is the unfortunate fate of Agile.

Luckily there has been some fresh perspectives from Nassim Taleb, author of Antifragile. His work explains how some things benefit from shocks; they thrive and grow when exposed to volatility, randomness, disorder, and stressors and love adventure, risk, and uncertainty. More importantly why antifragility is beyond resilience or robustness.

In this talk, I'll use some of Nassim's thoughts (and some of my own) to explain what is wrong with our current approach to Agile and how we can bring life back into Agile. Particularly how we can leverage Volatility, Uncertainty, Complexity, and Ambiguity to make product development more antifragile.

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.

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.

A successful startup/product company needs to master the art of validating early product ideas quickly and effectively. Whether you are building a product, service or a new feature, the two most important questions to find out early are:

• are we solving the right problem?
• if yes, how do we pitch the idea to the target customer to generate a favourable action?

During this session, we'll focus on various safe-fail experimentation techniques used by Lean Startups for quickly identifying and validating the customer's value hypothesis, without having to build the real product. You will leave this session equipped with various MVP design techniques, that will allow you to rapidly discover a viable product/service that delights your customers, without spending a lot of time and effort.

Traditionally, entrepreneurs believed that the only way to test their product/service hypothesis was to build the best-in-class product/service in that category, launch it, and then pray. Most often, products/services fail, not because they cannot be built or delivered. But because, they lack the market-fitment and customer appeal.

To avoid these risks, these days startups are focusing on building a "Minimum Viable Product" (MVP), a product that includes just enough core features to allow useful feedback from early adopters. This reduces the time to market and allows the company to build subsequent customer-driven versions of the product. Hence mitigating the likelihood of wasting time on features that nobody wants. MVPs are typically deployed to a subset of customers, such as early adopters that are more forgiving, more likely to give valuable feedback.

However the problem with MVPs is that companies still spend too much time building stuff and very little time learning. Don't forget the purpose of MVP is validated learning NOT building. This session will give you ideas on how to quickly formulate and test your value and growth hypothesis in a scientific framework using extremely cheap MVP techniques collectively referred to as MVP Design Hacks.

As more and more companies are moving to the Cloud, they want their latest, greatest software features to be available to their users as quickly as they are built. However there are several issues blocking them from moving ahead.

One key issue is the massive amount of time it takes for someone to certify that the new feature is indeed working as expected and also to assure that the rest of the features will continuing to work. In spite of this long waiting cycle, we still cannot assure that our software will not have any issues. In fact, many times our assumptions about the user's needs or behavior might itself be wrong. But this long testing cycle only helps us validate that our assumptions works as assumed.

How can we break out of this rut & get thin slices of our features in front of our users to validate our assumptions early?

Most software organizations today suffer from what I call, the "Inverted Testing Pyramid" problem. They spend maximum time and effort manually checking software. Some invest in automation, but mostly building slow, complex, fragile end-to-end GUI test. Very little effort is spent on building a solid foundation of unit & acceptance tests.

This over-investment in end-to-end tests is a slippery slope. Once you start on this path, you end up investing even more time & effort on testing which gives you diminishing returns.

In this session Naresh Jain will explain the key misconceptions that has lead to the inverted testing pyramid approach being massively adopted, main drawbacks of this approach and how to turn your organization around to get the right testing pyramid.

A successful startup/product company needs to master the art of validating early product ideas quickly and effectively. Whether you are building a product, service or a new feature, the two most important questions to find out early are:

• are we solving the right problem?
• if yes, how do we pitch the idea to the target customer to generate a favourable action?

During this session, we'll focus on various safe-fail experimentation techniques used by Lean Startups for quickly identifying and validating the customer's value hypothesis, without having to build the real product. You will leave this session equipped with various MVP design techniques, that will allow you to rapidly discover a viable product/service that delights your customers, without spending a lot of time and effort.

Traditionally, entrepreneurs believed that the only way to test their product/service hypothesis was to build the best-in-class product/service in that category, launch it, and then pray. Most often, products/services fail, not because they cannot be built or delivered. But because, they lack the market-fitment and customer appeal.

To avoid these risks, these days startups are focusing on building a "Minimum Viable Product" (MVP), a product that includes just enough core features to allow useful feedback from early adopters. This reduces the time to market and allows the company to build subsequent customer-driven versions of the product. Hence mitigating the likelihood of wasting time on features that nobody wants. MVPs are typically deployed to a subset of customers, such as early adopters that are more forgiving, more likely to give valuable feedback.

However the problem with MVPs is that companies still spend too much time building stuff and very little time learning. Don't forget the purpose of MVP is validated learning NOT building. This session will give you ideas on how to quickly formulate and test your value and growth hypothesis in a scientific framework using extremely cheap MVP techniques collectively referred to as MVP Design Hacks.

What started off as a trial-and-error approach to improve the state of software development by a bunch of tinkerers, is today dominated by management consultants, "Thou-Shall" codified frameworks and rigid, expensive tools. Over the last 20 years, we've gone from, "I'm not sure, let's try this in a small-safe environment" to "you/your-team sucks; you guys have a very poor agile maturity because you are not doing _x_y_z_ (not conforming to the standards)." Along the way, we've lost the purpose of being agile .i.e. to embrace uncertainty and simplicity. Instead we've been forced to believe that consistency via top-down standardisation and predictability by increasing the rigour on process is our eternal quest. Anything that sounds simple and works 80% of the cases is discarded as being naive. What once drove thought-leader into agile, is now driving them insane. This is the unfortunate fate of Agile.

Luckily there has been some fresh perspectives from Nassim Taleb, author of Antifragile. His work explains how some things benefit from shocks; they thrive and grow when exposed to volatility, randomness, disorder, and stressors and love adventure, risk, and uncertainty. More importantly why antifragility is beyond resilience or robustness.

In this talk, I'll use some of Nassim's thoughts (and some of my own) to explain what is wrong with our current approach to Agile and how we can bring life back into Agile. Particularly how we can leverage Volatility, Uncertainty, Complexity, and Ambiguity to make product development more antifragile.

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 this hands-on, live coding demo, 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.

In Indian classical music, we have Jugalbandi, where two lead musicians or vocalist engage in a playful competition. There is jugalbandi between Flutist and a Percussionist (say using Tabla as the instrument). Compositions rendered by flutist will be heard by the percussionist and will replay the same notes, but now on Tabla and vice-versa is also possible.

In a similar way, we will perform Code Jugalbandi to see how the solution looks using different programming languages and paradigms.

During the session, conference attendees will take turns at coding the same problem using different languages and paradigms. There would be multiple such attempts by different participants during the Jugalbandi.

When we think of OO, most people think of modeling THE real world in software by mapping every real world object (nouns) to entities in software. These entities are then modeled using Is-A-Has-A relationship to build complex, polymorphic hierarchies with deep object graphs. State is stored and mutated in-place inside the object to achieve the desired functionality. This paradigm leads to a fairly convoluted design and encourage imperative style of programming.

Not everyone who has designed large complex systems, think of OO the same way. For instance, people who Test Drive, do not have the luxury of a big-up-front design, instead they focus on small and incremental design. IME, TDD facilities a design that is side-effect free and encourages a declarative style of programming. While decoupling and composing objects in a functional style with the right granularity of abstraction.

Let's assume we've to build a web commenting and discussion feature (like Disqus). And we've a requirement to implement this as a jQuery Plugin. Can we apply pure functional principles to design this? Or will the design be better if we try a classical OO JS approach? In this live demo, we'll build this plugin from scratch and see how TDD will help us drive an object-functional design to strike a pragmatic balance between the 2 paradigms.

Aap Ki Adalat is the longest running talk show in the history of Indian television. In this show, the anchor, Mr. Rajat Sharma has grilled over 500 personalities on various sensitive and personal issues. We would like to put the key members of the jQuery Foundation through a similar session, where participants will ask them hard questions around various technical and non-technical choices made by the Foundation and the future direction of the foundation.

As more and more companies are moving to the Cloud, they want their latest, greatest software features to be available to their users as quickly as they are built. However there are several issues blocking them from moving ahead.

One key issue is the massive amount of time it takes for someone to certify that the new feature is indeed working as expected and also to assure that the rest of the features will continuing to work. In spite of this long waiting cycle, we still cannot assure that our software will not have any issues. In fact, many times our assumptions about the user's needs or behavior might itself be wrong. But this long testing cycle only helps us validate that our assumptions works as assumed.

How can we break out of this rut & get thin slices of our features in front of our users to validate our assumptions early?

Most software organizations today suffer from what I call, the "Inverted Testing Pyramid" problem. They spend maximum time and effort manually checking software. Some invest in automation, but mostly building slow, complex, fragile end-to-end GUI test. Very little effort is spent on building a solid foundation of unit & acceptance tests.

This over-investment in end-to-end tests is a slippery slope. Once you start on this path, you end up investing even more time & effort on testing which gives you diminishing returns.

In this session Naresh Jain will explain the key misconceptions that has lead to the inverted testing pyramid approach being massively adopted, main drawbacks of this approach and how to turn your organization around to get the right testing pyramid.

On Reddit, IAmA stands for "I am a" and AMA stands for "ask me anything".

In an IAmA post, a person will post what they are, and other people will ask the original poster some questions to gain insights about the experience the person has had.
 
Ex: I'm Jeff Patton, creator of Story Mapping, Ask Me Anything... OR I'm Diana Larsen, co-creator of the Fluency Model and co-author of Agile Retrospectives, Ask Me Anything...

We plan to take this concept and apply it to the Agile context. We've few luminaries at the conference and we plan to do an live interview with them using this format.

Over the past decade, eXtreme Programming practices like Test-Driven Development (TDD), Behavior Driven Developer (BDD), Refactoring and Continuous Integration have fundamentally changed software development processes and inherently how engineers work. Practitioners claim that it has helped them significantly improve their development speed, design quality and responsiveness to changing requirements. Software professionals across the board, from Internet startups to medical device companies to space research organizations, today have embraced these practices. But can these practices be applied to front-end development? Especially jQuery plugin development?

This demo will show how we can test drive a jQuery plugin with the help of various patterns, strategies, tools and techniques. Participants will understand how they can apply this approach for testing any jQuery code.