While we all know that developing new and innovative products is fun and interesting, what happens after the excitement of a product launch?

The phrase “software product maintenance” tends to conjure up an image of an endless stream of boring bug fixes, alternating with occasional panicked responses to the latest ultraviolet priority crisis when a critical issue arises. As well as being no fun for the development team, this can be expensive and hard to manage for the product owner, and can lead to a reputation for being unresponsive or “stuck in the past” with products that are rarely updated or refreshed.

At Cambridge Consultants, while we are used to applying our processes to enable the latest and greatest innovations, we also use them to help care for our clients further downstream in the product life cycle.


Iridium's NEXT constellation

As an example, we’ve been working with Iridium Communications Inc. since 2003. Iridium operates a constellation of 66 satellites to provide the world’s only commercial voice and data communications network with fully global coverage. During that time we’ve supported Iridium with everything from transceiver miniaturisation, new handsets with location based services and SOS capability, new terminal and gateway equipment for their NEXT satellites, right through to the design, development and roll-out of an entirely new service, creating the world’s first truly global Push-To-Talk group netted communication system.

But there’s another side to these projects, and it’s just as important for long term success. All these new developments, once launched, have transitioned into the Sustaining Engineering part of their life cycle. This covers everything from new feature requests, bug fixes, and product improvements through to process improvements in the way the product source code is built and managed.

Last year, Iridium came to us with the challenge to help them implement their vision of a major enhancement for their Sustaining Engineering process. We worked closely with them to define a new process using a calendar-based schedule, where each product family in turn undergoes a 12-week improvement process, so that all product families can be addressed during the course of the year.

In advance of the 12 weeks, feedback is collected from a wide variety of stakeholders: from the Product Managers, who are in regular contact with the end users of the products; through Iridium’s internal customer support and manufacturing teams; right through to the development team. All the issues, new feature requests, improvements and plain old bugs are collected and prioritised into a backlog; then over the 12-week cycle a team of engineers works on these in priority order, following an agile workflow of two-week sprints, specifically optimised for Sustaining Engineering.

To ensure that quality is maintained, the team use Continuous Integration tools (in this case Atlassian Bamboo and Jira) and a rigorous automated regression test suite (using a tailored framework), running against every source code commit. Any issues are caught early, and the risk of introducing regressions is well-bounded. This is hugely important for Iridium products that are in use in hundreds of thousands of places around the world – in many cases installed in inhospitable or inaccessible environments, such as polar regions or offshore tsunami warning buoys.

At the end of the 12-week process, the fully tested release can then be taken to production. Iridium’s internal User Acceptance Test, Manufacturing Test and Customer Care teams are ready to work with the new release, and the end-customers are happy that any issues and new features they raised have been addressed in a timely manner.

As well as implementing and optimising Iridium’s Sustaining Engineering process in this way, we have taken the opportunity to make some other improvements: overhauling the structure of the release packages and software release notes, and rationalising the Subversion repositories where the source code is stored. In doing this we have applied a clean and consistent structure which reduces the cost of maintenance and increases deployment speed, accuracy, and clarity of communication across the product ecosystem.

We believe that a systematic approach like this is necessary to manage the full life cycle of an established product. It’s also very satisfying for the developer team, knowing that technical debt – which can accumulate during a new product development – is being paid down rather than built up.

Vicky Larmour