The Road to Continuous Delivery in SW Development


(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.

Process Agility

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.

Advertisements

The Road to Universal Coverage in Real-Time Communications


Road to Universal Coverage white

(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.

——————
Daitan Group provides development services to accelerate product development in Telecom, Cloud, and Mobile. Daitan  customers can rely on a partner able either take complete ownership of a project, or work as part of a team in full Agile mode. Contact Daitan to discuss how we can help in your next project.

The Myth of Fixed-Price in Software Development


rendered concept of a project management triangle

(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.

—–

Daitan Group provides development services to accelerate product development in Telecom, Cloud, and Mobile. Daitan  customers can rely on a partner able either take complete ownership of a project, or work as part of a team in full Agile mode. Contact Daitan to discuss how we can help in your next project.

Beer Tasting: A Visit To An English Pub.


9349_10201228740099856_1673939528_n

A group of friends get together once a month to try different beers. I happen to be the host of this month’s meeting and the theme will be “A Visit to an English Pub”.

England brews beer since pre-historic times, mostly top-fermenting Ales.

Originally, a brew was an “Ale”. Add hops to ales and you get “Beer”. In England, beer (or “bitter”) is a normally a Pale Ale. Mild, Brown, Old, and India are variations of Pale Ales styles (but the Brits are very bad at agreeing exactly on what defines each style).

Beer in England is served at cellar temperature (about 55F) and is meant to be cask-conditioned in a Pub’s cellar and be poured from a tap. But in the era of InBev and Bev&More, we get it pasteurized and shipped to our door (and we will drink it a bit colder).

When tasting English beers, you say “flavour”, “colour”, not “flavor” and “color”.

This is today’s beer selection:

  • We start with two brown Ales that (based on my limited experience) are not commonly found in London English Pubs.
    • New Castle Brown Ale (4.7% ABV) – Probably the most common in Californian supermarkets in this set, most people has had it before. It originates in the North-east of England (but today owned by Heineken), it is known in England as a working man beer. You have drunk it, but have you tasted it?
    • Old Specked Hen (5.2% ABV) – I found it first here in California and felt in love. But loves wear off eventually. I always get a bit disappointed because it looks so beautifully red against the light in its clear bottle, but it turns amber-brown when we pour it in the glass.‘Old Speckled Hen’ has a full, smooth flavour and is very easy to drink. Fruity aromas are complemented by a blend of malty tastes and a dry finish.
  • Then we move on to brands and brews I actually tried first at some real English Pub
    • Fuller’s London Pride (4.7% ABV) – I found that if you walk into a London Pub, walk by the old guy sitting at the end of the bar and order “a bitter”, 7 out of 10 times, that is what you get.
    • Boddington’s Ale (4.6 %ABV) – Originated in England’s Northwest (now owned by InBev). If you like creamy beer (I do), Boddington’s is usually served in the pub extra “nitrogenated” (mixed with N2 gas at the tap, like Guinness). Having it from the can won’t feel the same, but it had to be part of the standard set.
    • Fuller’s ESB (5.9% ABV) – ESB stands for “Extra Special Bitter”. It is slightly stronger and supposedly more premium cousin to the London Pride.
    • Samuel Smith Old Brewery Pale Ale – It originated in Tadcaster, England and it is the last of the most traditional mainstream breweries to remain independent. Their beer (including the two in today’s tasting) are fermented in in “stone Yorkshire squares’~ fermenting vessels made of solid slabs of slate ~ which give the beers a fuller bodied taste, using the same strain of yeast since the nineteenth century.
  • And we finish with an Imperial Stout
    • Samuel Smith Imperial Stout (7%ABV) – This distinctive type of beer, like the IPA, was originally brewed to withstand the abuses of shipping in foul weather to Imperial Russia. It was a favourite of Russian nobility whose taste for the finest food and drink was world famous. A rich flavourful brew; deep chocolate in colour with a roasted barley nose and flavour that is a complexity of malt, hops, alcohol and yeast. Fermented in ‘stone Yorkshire squares’.

The End of Telecom (as we know it)



iStock_000011425873XSmall
(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.

———————

Marcio Saito is responsible for marketing at Daitan Group, a software development service provider helping technology vendors adopt new communication technologies and bring them to the market quickly. Daitan pioneered the development of cloud-based communications and was first to implement WebRTC for its customers. To contact Daitan, click here.

WebRTC and Business Applications


Daitan WebRTC

(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.

TMC-Article

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


Daitan Group is a pioneer in WebRTC development for business applications. Our development partners were the first in the industry to introduce call center and customer service products supporting WebRTC. If you plan to develop WebRTC services, don’t start it before contacting us.

Customer Service and WebRTC: A Technology Game Changer


WebRTC

(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).

—————————————————–
Daitan Group is a pioneer in WebRTC development for business applications. Our development partners were the first in the industry to introduce call center and customer service products supporting WebRTC. If you plan to develop WebRTC services, don’t start it before contacting us.