When it comes to learning about the latest ideas in software development, Philips engineers are at the cutting edge. More than 300 of the company's healthtech software engineers gleaned insights from leading thinkers in DevOps, continuous development and software architecture at the July 25 Andover Software Excellence Conference.
 

Presenters from inside and outside the company emphasized the theme "Better Faster Forever." The idea? Intensify Philips' focus on quality, speed and sustainability to benefit products, customers and engineers whose skills become sharper and more valuable. After all, 60 percent of Philips engineering capacity is in software, and the company aims to be the best in the world at developing software specifically for healthtech.
 

Keynote speaker Dave Farley, a DevOps expert, said it was his goal to prove to attendees that continuous delivery, grounded in principles of science and engineering, is the state of the art for creating repeatable, reliable results in software development. Organizations that do continuous development, he explained, make small, continuous improvements, instead of releasing large, complicated changes. Farley backed up his argument with four key ideas:
 

1. The state of software development has been suboptimal for a long time. Farley explained that the industry got off to a bad start in the 1970s when software developers widely adopted the waterfall method despite the advice of computer scientist Winston Royce. Although Royce's now infamous publication, "Managing the Development of Large Software Systems," introduced the waterfall process, it came with a warning that most readers ignored: "I believe in this concept, but the implementation described above is risky and invites failure." As a result, Farley said, a "staggering percentage" of large software development projects go so badly wrong that they threaten their company's existence. "That's telling us something profound," he said. "It's telling us we've got the model wrong."

 

2. Agile development and the iterative approach to software development applies scientific reasoning to hard problems. Farley said software engineers can achieve excellence by "learning from our mistakes through a continuous loop of trying, learning, adapting." He encouraged engineers to embrace the scientific method and argued for an iterative process that repeats four steps: conceive an idea, introduce it to the customer, get feedback, do it again. "Instead of guessing, start measuring," he said.

3. Shortening cycle times is the path to game-changing advances. The core of continuous delivery is the feedback loop, Farley argued. "The way to drive change is to improve the speed, quality and efficiency of feedback." Improving the quality, frequency and availability of feedback, learning from it and experimenting based on those learnings is the key to developing better software.

 

4. With continuous delivery, software is always in a releasable state. To illustrate the value of software, Farley recounted a bank he worked with whose process made it incapable of releasing a single line change to its production system in under 100 days. On the other hand, a much larger financial exchange Farley collaborated with could evaluate any change and definitively decide to release into production in under an hour. "That's game-changing for the software development process," Farley said.

Simon Brown, an expert in software architecture and diagramming, also pointed to the misguided waterfall approach for problems in software development, and agreed with Farley about the importance of the agile methodology.

Brown shared four more ideas that he encouraged every developer in the room to embrace.
 

5. A good architecture enables agility. Being an agile development shop, Brown said, is about moving fast, embracing change, getting feedback and releasing often. Your architecture is key to success.

 

6. Developing a big, upfront design is a problematic idea, but having no design upfront is even more challenging. It's hard to believe, Brown said, but some organizations skip upfront design altogether. That's a bad idea. To determine how much upfront design to do, Brown recommended several steps: Engage your mind in the problem to analyze it thoroughly; ask yourself what you're going to build and if it is going to work; also ask what will be expensive to change about your system once it's done; and be sure you're making the right upfront choices.

 

7. Key to upfront design is to identify, prioritize and mitigate your risks. There are many approaches to identifying risk, but Brown has developed a visual, collaborative technique he calls "risk storming," which lets a team of engineers do enough upfront design to create a good starting point, a direction and a vision to stack the odds in its favor.
 

8. Every team needs technical leadership. Whether you're a software development team of one or 1,000, you need technical leadership, and different teams need different kinds of leadership, Brown said. "Your job as an architect is to see what kind of team you have and what kind of leadership it needs." Coding, coaching and collaboration are key skills for a leader, he noted.

These ideas, explained by two of the world's leading software development thinkers, were just a few of the many insights shared at the Andover Software Excellence Conference. Philips engineers who attended the event headed back to their desks with these concepts front of mind. Their application will put them—and any engineer—at an advantage to develop healthtech software better, faster and forever.

To learn more about software careers at Philips, visit www.philips.com/softwaredevelopment.