(this post originally written for Daitan Blog)

Once upon a time, people just wrote code and then run it to find how well it worked. Working individually, the developer was able to iterate quickly until the software was useful to solve a real problem.

By the 1990’s, as software became more complex, it was broken into separate and independent sub-modules developed more or less in isolation by individual developers. Each sub-module was tested, the system was integrated back together, then tested, staged, released, deployed. Software development cycles stretched over several months (or several years).

The pendulum is swinging back. Software engineering is now evolving towards shortening the feedback loops and minimizing the time it takes from code being written and being in production. This time, we want to do it with more quality and predictability. The tools to achieve that are processes, automation, and collaboration.

Moving across the levels depicted on the picture above (Source Code Control, Build Automation, Test Automation, Continuous Integration, Release Automation, Continuous Delivery) is not simple. It involves not only changing processes and automating them, but also changes in culture and organization.

• Source Code Control – Single source code repository with version control.
• Build Automation – Compile and Build applications without human intervention.
• Test Automation – Execute unit, integration and service tests without human intervention.
• Continuous Integration – Developers integrate code into a shared repository (which triggers automated build/test) often.
• Release Automation – Packaging, deploying and post-deployment testing without human intervention.
• Continuous Delivery – Every change to the system is releasable. Release can be done by the push of a button.

Continuous Integration

Continuous Integration (CI) is the practice of accelerating the daily commits of code by software developers. If in the past developers would work for weeks before trying to integrate their work to the main tree, in a CI environment you want developers to check-in their work several times a day.

A CI server monitors code check-outs and check-ins by developers and, as often as practical, it builds the system and runs unit and integration tests. If there is any failure in the process, the CI server alerts the developers. A broken build gets the attention and top priority from the team.

CI requires test-driven development and automation.

Benefits:

• CI does not eliminate software bugs, but it accelerates their discovery and keeps people from going in the wrong direction for too long.
• The system is always in a state that can be released to users. That provides more flexibility to the business and enables the automation of the release process and delivery to users.

Continuous Delivery

Once you are doing Continuous Integration and is able to automate the deployment process, you can consider extending the process and automation all the way to the end-user. Continuous Delivery (CD) is the practice and ability to rapidly, reliably and repeatedly push out enhancements and bug fixes to customers at low risk and with minimal manual overhead.

The automation system let changes to the system be released on a granular basis. Releasing features just to a subset of users and being able to seamless roll back to a previous version become possible.

The result is that there is no delay between enhancements and bug fixes being implemented and available to users.

(this post originally written for Daitan Blog)

It took more than 100 years from the invention of the telephone to the point where virtually every home in the developed word had a phone line.

In the mid-1980’s the first cellular networks appeared and, 25 years later, we get to the point where there are 6 billion cell phones in a world with 7 billion people. More people have access to a cell phone than to drinking water or toilets.

As cell phones reach universal coverage, traditional phones usage is declining. As of 2013, 1/3 of the US households no longer have a phone landline, and that is declining fast.

VoIP technology as we know it today appeared in the 90’s and became widely available to consumers in the early 2000’s. Those services have incorporated capabilities to add video, text chat, screen share, etc.

But IP-based communications has not yet reached universal coverage. I cannot simply “pick-up the phone and call anyone in the word”. Users are still segmented among a handful of proprietary platforms.

But the day when real-time communications over IP become universal is coming. We can already see the beginnings of the decline in the use of cell phone. I am not necessarily typical, but I used only 5 minutes of my cell phone plan last month (most of my communication these days happen over Facebook, Twitter and Skype).

How long will it take? Considering that adoption of new technologies is accelerating, it won’t take 100 years like the telephone or 25 years like the cell phone. We have been using IP-based communications for over 10 years, so we are going to see universal coverage in IP RTC in a couple of years.

(This post originally written for Daitan Blog)

There are two rational reasons why customers of software development projects are still attracted to fixed-price contracts:

• Budget predictability
• Transfer of technical  risk to the provider

The title of this post calls that a myth because in exchange for offloading the technical risk, the customer usually assumes the risk or requirements uncertainty. Naturally, to take on a fixed-price project, the provider will demand a fixed set of well-defined requirements and a static Statement of Work.

So what happens? As the project starts, we naturally learn more about the competitive landscape, the real market requirements, new use cases. The technical requirements change and we are left with two options: (a) stick to the fixed-everything contract and develop a product that does not match user needs or (b) change the scope of the project and adjust the schedule/price accordingly.

So, the fixed-price project is not really.

Agile Development is about recognizing the reality that both market requirements and engineering estimates will change over the life of a project. So, the agreements and software releases are iterative, fixed only for short periods of time and adaptive to the reality of execution.  Most internal software development organizations have already made that transition.

Agile Outsourcing is about finding external development partners that will be able to share technical and market risks and work collaboratively to adapt to those changes and deliver the best possible result, within schedule and budget. Most external development organizations became good at minimizing per hour cost, but are still not able to deal with change in requirements. So most software development outsourcing is still based on simple fixed tasks.

—–

(Originally written by Marcio Saito for Daitan Blog)

It was early 1900’s when the telephone become a medium for real-time communications. It took us 100 years to build a telecom infrastructure that brought a phone line to virtually every home in the developed world.

But that picture of universal coverage is changing rapidly. As of end of 2012, more than a third of all households in the US were no longer using a landline (source). These people have ditched their traditional telephones and rely solely on their cell phones and internet connections.

AT&T, the largest telephone operator in the US has publicly announced it will turn off its traditional telephone network (PSTN) by 2015. Regulatory requirements are the only reason that doesn’t happen even faster.

The first cellular networks appeared in the early 1980’s and, 20 years later, we reach the point where virtually every person in the developed world has a cell phone. In emerging countries, cell phone penetration is higher than landlines have ever been. In Brazil today, there are 260M cell phones for 190M people. China has 1.1B cell phones, 3 times more than the US. It is universal coverage again.

We are already living a new major transformation. We are starting to use our cell phones less and do most real-time communications using Social Media and Voice/Video-over IP (Skype, Facebook, FaceTime, Google Voice).

We have finally reached a point where the communication applications are independent from the underlying transport infrastructure. When we talk over the Internet, it doesn’t matter what the transport is (wi-fi, cell, copper wires), applications are free from control from operators. New technologies and standards like WebRTC will further democratize access to communication functions, making them available from any IP capable device.

What is coming is a new wave of innovation, when real-time communications will be richer (voice, video, screen, text), ubiquitous (computer, appliances, mobile, wearable) and seamless (move from one device or network or media to another without interrupting the conversation).

It is the end of Telecom as we know it. Or a new beginning.

———————

(originally written for Daitan Blog)

In the past years, communications applications such as Skype and FaceTime have revolutionized how consumers use computers to communicate in real-time. Grandma talks and interacts with her grandchildren even when they live thousands of miles apart.

Now WebRTC, an emerging standard for real-time communications, is gathering a lot of attention. Its promise is similar: seamless sharing of voice, video, data. Why is it so special?

The big difference is that WebRTC is embedded in the web browser. There is no need to install a native client. Once WebRTC is available in the mainstream, developers without telecom experience can integrate communications features into web and mobile applications by adding a couple of lines of JavaScript code.

That will bring a new wave of inovation, creating disruption and new opportunities. Grandma led the way, now it is time for business to wake up to the potential of WebRTC in customer service, video conferencing, marketing, sales.

We have recently talked to TMC about WebRTC in Business. Check the interview here.

(This was originally written for Daitan Blog)

What is WebRTC? Why is it Relevant to Customer Service?

WebRTC is an emerging standard to enable real-time communications (voice, text, video, data) directly on a web-browser running in any machine or mobile phone. It is like having ubiquitous Skype, but without the need to install any proprietary application or browser plugins.

With WebRTC, web developers can easily embed rich voice/video/data applications into web pages or apps using nothing more than  HTML5 and JavaScript. They can quickly develop new communication applications without owning media pipes (once connection is set, data flows peer-to-peer) and writing just a few lines of code.

Skype, Google Hangouts, and other stand-alone communication applications are changing how we communicate using our laptops and smartphones. WebRTC integrates that change to web services and mobile Apps.

WebRTC and Customer Service: Transforming Customer Communications

One of the greatest challenges for Customer Service today is to keep context independent of channel. A conversation that starts on the website via chat can turn into a phone call and then transition to Twitter to be eventually resolved by email.

The promisse of WebRTC is to be the single channel of real-time communications enabling the seamless transition between data, text, voice, video sharing. For example,  “Click to Call” buttons become trivial and independent of platform or type of client device.

So what we see in the horizon is a future of no more traditional phone lines, no more proprietary web widgets for chat, and a seamless, integrated channel for real time communication that will both make current problems irrelevant and create a new set of challenges for Customer Service organizations.

Where is WebRTC today?

WebRTC is a standard driven by the IETF and W3C. It is in draft mode and is currently supported by Google Chrome, Mozilla and Opera Browsers. Safari and Internet Explorer are not yet supporting the WebRTC standards, although plug-ins are available for both browsers.

A good gateway for additional information can be found at http://www.webrtc.org/ (which is maintained by the Chrome Browser team).

(originally written for Daitan blog)

In the past decade or so the software industry has moved from waterfall to Agile Software Development methods.

In waterfall development, marketing and engineering signed a “contract” based on a fixed scope of work (the “Product Requirements Document”) and embarked in a long project based on engineering estimates of execution complexity. That provided a false sense of predictability and risk management. The problem is that requirements change and estimates are proved wrong as soon as developers start writing code, resulting in delays, budget overruns, and mismatch between product capabilities and user needs.

The idea behind Agile is that both marketing and engineering teams develop a relationship of trust and share common goals and responsibilities. Both sides agree that plans are subject to change and work collaboratively, managing schedule, scope and cost,  continuously making plan adjustments often. The result is more efficiency and better products.

Is Your Software Development Agile? Think again

Another trend in software development that has only increased in the past decade is the use of external development teams (outsourcing). It is about cost and risk management and accessing skills where they are readily available.

If you do or plan to use external teams for software development, you must transform your thinking on the relationship with them to materialize the efficiency advantages of Agile development. The interface between product developers and traditional outsourcing providers has not yet caught up with the level of transparency and collaboration required for Agile methods to work.

So, what do you need to look for when working with a software development partner?

Here are the top 3 Requirements for Agile Outsourcing:

1. Cost Efficiency.  Yes, there are other good reasons to outsource, but managing development costs is still an important driver. The common mistake is to focus in hourly cost per developer. You need to think cost of results and development organizations working in Agile with more capable developers should be able to deliver a lot more than just low cost per head.
2. Technical Capabilities.  In an Agile development team, every member must interact with others and contribute their ideas. If external developers are seen as second-class contributors, you are on the wrong path. They should be as capable as the internal team and bring their previous technical and process experience in similar projects to add value to the relationship.
3. Collaboration and Communication.  Since outsourcing often involves teams in different countries, factors such as language, time zone, cultural differences can be a challenge. Before starting a project make sure you can trust your partner and that the communication infrastructure is adequate and that there is a good match of culture, language and capabilities to communicate in real time. Joint development is not a transaction, it needs to be a trusted relationship between teams.