What goes wrong with Agile? And how to fix it.

With the introduction of iterative development, frequent releases, a cross-discipline team, continuous integration, demos and retrospections, Agile development methodology has scored huge in the project execution as compared to traditional waterfall. It’s all going to be rainbows and sunshine, and everything will be smooth and perfect! Not surprised, many digital projects committed to Agile from the beginning.

But in reality, Agile is not a silver bullet. It can go wrong in various places. In this podcast, Atish Narlawar talks to Matt Toigo, Technical Architect at Huge, things that go out of the way in Agile and ways to address it.

Venue: Brooklyn, NY.

Host: Atish Narlawar

Guest: Matt Toigo @Toigo

Contact: techpodcast@aol.com

The Evolving Role of QA

In this episode, Tech Talk Podcast Host Atish Narlawar talks to Kate Falanga, an organizer of New York City Testers Meetup about "The Evolving Role of QA" in Software Engineering.

Kate gives an overview of how the role of QA has shaped in the software development since the era of GeoCities. With the aspects of processes, engineering practices, automation, and culture the role of QA has indeed gone far from waiting for testable code rather start to offer inputs at the beginning of requirement gathering.

Kate explains, the difference between QA Engineer and QA Analyst, and how both roles are very different and efficient in the software development. She insists although Automation is imperative, but it has to go through the lenses of usefulness, what make sense and what doesn't.

"The days of QA are getting numbered?" Recently one of the group from Yahoo got rid of QA Team altogether, stating testing is a part of culture, and, in fact, it's a shared responsibility. Kate answers QA is not dead, and it will never be dead. She think QA going through transformations, and the expectations have changed with this the role itself in validating requirements upfront, managing automation, release planning and recognizing what make sense and what doesn't. As next generation gadgets evolve with Augment & Virtual Reality, Driverless cars, Internet of Things the domain of QA is expanding fast and the ways to measure and manage quality is becoming quite challenging as certain rules need to get defined in these areas.

Podcast: Tech Time Podcast

Venue: Brooklyn, NY.

Host: Atish Narlawar

Guest: Kate Falanga

Meetup: NYC Tester

Blog: Evolving QA

Is adopting agile harder for agencies and consulting companies?

Agile development has imprinted solid mark in the software development in last 5-6 years. There is a jump from fringe to the mainstream, and the claim of "We are Agile!" is truer at this time in the teams while it wasn't back in 2010.

The Agile Manifesto was written by a group of software developers for their use. Many of the underlying principles of a framework like Scrum assume the existence of an in-house team and working for the business that employs them.

There is a strong argument for

"Agile Methodology is easier in the settings where you have all the control. Adhering to agile frameworks such as Scrum is more difficult within an agency/consulting structure than it is for an in-house development team especially with the client who understands fixed costs, fixed deadlines, and fixed bid contracts."

On this notion, Atish Narlawar speaks with Christopher Cunningham, a Group Technology Director at Huge, to understands "Does Agile works in the client engagements?" and what are the factors which play a significant role to make it happen.

They start the discussion by going through the factors which have changed in the engagement following Agile process. Chris mentions the importance of a shared language which plays a significant role to create a shift where agencies and client services pushing Agile with their customers. This change has worked with a positive note as agencies started to spend more time delivering excellent products, and less time arguing over out-of-date functional specs. Infact he thinks clients are also requesting and even demanding agile practices from their agencies.

Chris mentions even though some contracts bound with a deadline and fixed costs but there are better ways to get overcome with this, and the best way is to get rid of the fear of uncontrolled cost with the clients. With the combination of informed decisions, tangible results, waste reduction, risk transparency and time to market Agile can certainly give enough ammunition to influence customers and build the trust. With delivering a fully-working product at every milestone, Chris mentions agile expects more involvement from the clients at every step, and corporate companies responded to this need with the positive note.

On the reporting side, Agile driven burn down charts, sprint velocity and points breakdown offers the better way of tracking the progress, identifying the impediments than traditional metrics.

Christopher also notes that within an enterprise environment, Agile methodology is restricted to the software development teams. Other parts of an engagement like business, approval workflows and delivery management still go through traditional way, and that's one of the main reason the clients are not able to leverage the full Agile potential. He predicts there will be a positive change in upcoming days and companies will experience company-wide adoption.

Podcast: Tech Time Podcast

Venue: Brooklyn, NY.

Host: Atish Narlawar

Guest: Christopher Cunningham

React Native Development and Industry Adoption.

React Native is a framework for building native apps using Javascript and React js. Since the announcement which came on early 2015 from Facebook React has been one of the hot topics has ever discussed in Mobile community.

With this notion, Atish Narlawar speaks with Nicholas Brown, Founder of React Native NYC meetup. They start the conversation by jumping to the React JS component based framework and then natural progression of extending the web framework to mobile platforms through React Native.

Nicholas briefs the Architecture and introduces the feature of converting Javascript functionality into native platform code. Nicholas clarifies how React Native differs entirely from existing Javascript based mobile frameworks like Cordova and Appcelerator Titanium. He mentions within a year, the number of contribution to React Native exceeds that to the Cordova.

He explains the performance impact of using React Native compared to directly developing with Native code, especially during the transition of Javascript to Native code. However, to address this concern, better features and tools has been evolved like live reload and Microsoft CodePush. He also goes through various use cases where developing a mobile solution using React Native turns to be better as compared to native ios/android code.

Nicholas thinks once the solution gets developed on one platform, for example, iOS then the same solution can be used for Android with the minimal efforts around of 10% of the total. The discussion then goes through the current adoption of React Native in the tech industry and how most of the company are gearing up themselves meanwhile taking the cautious approach to be ready for next real change. He also shares the Google's attempt to enter into this domain with Flutter.

The discussion winds up with the recommendations for the beginners, with Facebook own tutorial and plugin repository named as React Parts for Native and Web plugins.

Podcast: Tech Time Podcast

Venue: Brooklyn, NY.

Host: Atish Narlawar

Guest: Nicholas Brown

Meetup: React Native NYC

Links: Facebook React, React Parts, Flutter

Search Engine Optimization in 2015.

Search engine optimization (SEO) is the process of affecting the visibility of a website in a search engine's especially unpaid results. In general, the earlier and more frequently a site appears in the search results list, the more visitors it will receive from the search engine's users.

As the internet evolves over the time, it also showed impressive progression about the changes in user behavior about how, why and what they search for. This creates a continuous battle of how/why search engines prefer to represent information and creates a wide array of variations for SEO team to focus on.

One of the key impression with SEO, it is ever changing landscape. With this notion Atish Narlawar talks with David Sosnowski, a technologist, Group Director of Marketing at Huge.

They start the discussion by going through the ever-changing landscape of SEO. David explains even through SEO are changing fast to adapt the users and SEO analysts also needs to evolve over the period but the fundamental SEO principles have remained same even in 2015. He explains the core fundamentals user signals like bounce rate, ATOS (average time on site), ATOP (average time on page), conversion rate, click throughs which still be effective to guide SEO strategies.

With stressing Links and URLS as the most important factor, the discussion outlines few simpler and effective steps for any SEO strategy,

  • Understand the areas of improving indexation of the site through using Google Webmaster tools.
  • Task the SEO and technology teams to enhance coding elements.
  • Work with content teams to make sure expected voice matches how audience is searching through keyword research.
  • Monitor links coming into the site with tools like h-refs and teach your content, communication and social teams on the importance of links.

To deal with high volume CMS based website (For eg. a website with 70,000 pages) he recommends to focus first on categorization and second to rely heavily on google analytics based on understanding what is happening not just reporting numbers.

David shares the insights about how to keep and stay ahead in SEO Learning curve. Heclears the misconception revolves around redirects 401, add notes to the security and keyword selections. David recognizes the importance of Machine learning through the introduction of Google ‘RankBrain’ and explains SEO is turning to be a team work with co-ordination with other disciplines like UX and Products.

The discussion concludes with the mantra that SEO is no different, and definitely, it's not a rocket science. He recommends coming up with the roadmap of “Do, Report, Understand, Do.”

Venue: Brooklyn, NY.

Host: Atish Narlawar

Guest: David Sosnowski

Twitter: @SEO_Raptor

BEM - CSS Methodology.

Since the age of Geocities Era, CSS has been evolved a lot. It has seen the transition from plain CSS to emerging development framework such as such as OOCSS (object oriented CSS), SMACSS and now BEM.

BEM – stands for block, element, modifier. By definition, it is a CSS development methodology specifically designed with flexibility and ease of modification in the mind. In the given podcast episode, Atish Narlawar talks to William Anderson about the BEM. William is a die hard Technologist, Software Engineer and part time Professor at The New School University New York.

The conversation gets a start by going through high-level CSS evolution since the the 1990s. William shares the fascinating things in the CSS in 2015 like logical integration, media queries, and animations. Along with he also explains how CSS development became quite complex down the line due to cascade, responsive design and the javascript itself.

One of the major challenges gets added with the new found complexity includes messy CMS, broken semantics and SEO refactor and BEM emerged as one of the possible solution to address these challenges.

With the example of feature card, William explains how BEM tries to fix the issues mentioned, such as complexity, semantics, and decoupling. Using zero specificity, he shares how seamlessly his team were able to integrate SEO tag change in the live project.

William also shares his valuable insight in terms of how BEM works with other CSS methodologies such as OOCSS (object oriented CSS) or SMACSS (smacks). He tries to clarify the long haunting doubts about BEM such as BEM is too verbose and it pollutes the DOM with Blocks, Elements, and Modifiers all cooked in class names. He shares what could be the best strategy for initiating the adoption of BEM into existing projects, and quite possible barriers team may face during the transitionary switch.

At the end, he also shares valuable resources where someone should start digging about BEM methodology and its related practices.

Venue: Brooklyn, NY.

Host: Atish Narlawar

Guest: William Anderson

Twitter: @TheWAAnderson

Boot the Swagger: API as good as it's documentation.

Swagger provides one of the best representation of the REST API during development. It provides interactive API documentation baked in with the application itself. Contrary to create separate specification document with cost of maintenance and risk of obsolete, Swagger generates the API documentation on the run time with updates. It also provides user friendly REST interface to test the code at the same place. This idea of live documentation has real value, and I guess you should give a try during API development.

In one of the recent engagement, I had to showcase the working proto of Swagger to the client, and being said easy to setup I estimated it for 15 mins. But I was damn wrong, I had to spend 2 hours to get Swagger up and running. So, I had an idea why not to just simplify the Swagger configuration process in very simple steps, so hungry user like me can configure in existing application and see the benefits.

I configured it for Spring Boot, but I fairly assume it should be similar in most Swagger supported frameworks.

Add dependency.

In pom.xml

Add Configuration Class

Add annotations.

For every REST endpoint methods of Controller, @ApiOperation annotation needs to be added. For eg,

Add Swagger UI HTML library from GitHub.

Download Swagger UI Library v2.1.1 from Github into resource/public folder. Replace the declaration of Url from the first index.html function,

These are minimal steps required to spinup swagger on existing Spring Boot web application. Swagger API configuration and Swagger UI documentation can be seen at




Swagger has been updated with Specification 2.0. Version used in the example may go obsolete in near by future.