Successful Delivery

Designing, building, and delivering an embedded product to market can be challenging. Products today have become sophisticated, complex software systems that sit upon an ever-evolving hardware landscape. At every turn, there is a challenge, whether it’s optimizing a system for energy consumption, architecting for configurability and scalability, or simply getting a supply of the microcontrollers your system is built. Embedded software design requires chutzpah.

Despite the many challenges designers, developers, and teams often encounter, it is possible to successfully deliver embedded products to market. In fact, I’ll go a step further and suggest that it’s even possible to do so on time, on budget, and at the quality level required by the system stakeholders. It’s a bold statement, and, alas, many teams fall short. Even the best teams stumble, but it is possible to reach a level of consistency and success that many teams can’t reach today.

Embedded Software Design, this book, is about providing you and your team with the design philosophies, modern processes, and coding skills you need to deliver your embedded products successfully. Throughout the book, we cover the foundational concepts that will help you and your team overcome modern challenges and help you thrive. As you can imagine, the book is not all-inclusive in that every team will have different needs based on their industry, experience, and goals. Embedded Software Design will help get you started, and if you get stuck or need professional assistance, I’m just an email away.

Before we dive into the intricate details of Embedded Software Design, we need to initialize our minds, just like our embedded systems. We need to understand the lens through which we will view the material in this book and how we can apply it successfully to our unique situations. This chapter will explore how this book is organized, essential concepts on how to use the material, and how to maximize the value you receive from it.

The Embedded Software Triad

Many teams developing embedded software struggle to deliver on time, on budget, and at a quality level that meets customer expectations. Successful development is often elusive, and software teams have all kinds of excuses for their failure.¹ However, many teams in the industry are repeatedly successful even under the direst conditions. I’ve found that these teams have mastered what I call the embedded software triad.

Software architecture and design consists of everything necessary to solicit the requirements, create user stories, and design the architecture. The software architecture defines the blueprint for the system. It’s important to note that the architecture should be evolvable and does not necessarily need to be developed up front.² How the architecture is designed follows the processes used by the team.

Agile, DevOps, and Processes are the procedures and best practices that are used to step-by-step design, build, test, and deliver the software. Processes provide the steps that allow a team to deliver successfully based on the budget, time, and quality parameters provided to them consistently. In today’s software development environment, processes are often based on various agile methodologies. Therefore, the processes help to guide the implementation under the parameters and disciplines defined by the team. I’ve also called out DevOps specifically because it is a type of process often overlooked by embedded software teams that offers many benefits.

Development and coding skills are required to construct and build the software. Development entails everything necessary to take the architecture and construct the system using the processes! At the end of the day, the business and our users only care about the implementation which is completed through development and coding skills. The implementation should result in a working system that meets agreed-upon features, quality, and performance characteristics. Teams will organize their software structure, develop modules, write code, and test it. Testing is a critical piece of implementation that can’t be overlooked that we will be discussing throughout the book.

To be successful, embedded software designers, developers, and teams must not just master the embedded software triad but also balance them. Too much focus on one area will disrupt the development cycle and lead to late deliveries, going over budget, and even buggy, low-quality software. None of us want that outcome. This brings us to the question, “How can we balance the triad?”

Balancing the Triad

Designers, developers, and teams can’t ignore any element of the embedded software triad. Each piece plays a role in guiding the team to success. Unfortunately, balancing these three elements in the real world is not always easy. In fact, in nearly every software audit I have performed from small to large companies, there is almost always some imbalance that can be found. In some teams, it’s minor and adjustments can result in small efficiency improvements. In others, the imbalance is major and often crippling to the company.

The relationships between the elements in the triad can be best visualized through a Venn diagram, as shown in Figure 1. When a team masters and balances each element, marked by the number 4 in Figure 1, it is more likely that the team will deliver their software on time, on budget, and at the required quality level. Unfortunately, finding a team that is balanced is relatively rare. It is more common to find teams that are hyperfocused on one or two elements. When a team is out of balance, there are three regions of Figure 1 where the teams often fall, denoted by 1, 2, and 3. Each area has its own symptoms and prescription to solve the imbalance.

A Venn diagram depicts the result of the embedded software triad. The outer circles have software architecture and design, development and coding skills, and agile, dev ops, and processes. The overlapping parts are labeled 1, 2, and 3, and the center is 4.

The first imbalance that a team may fall into is region 1. Teams fall into region 1 when they focus more on software architecture and implementation (denoted by a 1 in Figure 1) than on development processes. In my experience, many small- to medium-sized teams fall within region 1. In smaller teams, the focus is almost always delivery. Delivery equates to implementation and getting the job done, which is good, except that many teams jump right in without giving much thought to what they are building (the software architecture) or how they will implement their software successfully (the processes) repeatedly and consistently.³

Teams that operate in region 1 can be successful, but that success will often require extra effort. Deliveries and product quality will be inconsistent and not easily reproducible. The reason, of course, is that they lack the processes that create consistency and reproducibility. Without those processes, they will also likely struggle with quality issues that could cause project delays and cause them to go over budget. Teams don’t necessarily need to go all out on their processes to get back into balance, but only need to put in place the right amount of processes to ensure repeatability.

The second unbalanced region to consider is region 2. Teams that fall into region 2 focus on development processes and implementation while neglecting the software architecture (denoted by a 2 in Figure 1). These teams design their system on the fly without any road map or blueprint for what it is they are building. As a result, while the team’s software quality and consistency may be good, they will often still deliver late because they constantly must rework their system with every new feature and requirement. I often refer to these teams as lost or meandering because they don’t have the big picture to work from.

The final unbalanced region to consider is region 3. Teams in region 3 focus on their software architecture and processes with little thought given to implementation (denoted by a 3 in Figure 1). These teams will never complete their software. They either lack the implementation skills or bog down so much in the theory of software that they run out of money or customers before the project is completed.

There are several characteristics that a balanced team will exhibit to master the embedded software triad. First, a balanced team will have a software architecture that guides their implementation efforts. The architecture is used as an evolving road map that gets the team from where they are to where their software needs to be. Next, a balanced team will have the correct amount of processes and best practices to ensure quality software and consistency. These teams won’t have too much process and not too little. Finally, a balanced team will have development and coding skills to construct the architecture and leverage their processes to test and verify the implementation.

Successful Embedded Software Design

Successful software delivery requires a team to balance the embedded software triad, but it also requires that teams adopt and deploy industry best practices. As we discuss how to design and build embedded software throughout this book, our focus will discuss general best practices. Best practices “are procedures shown by research and experience to produce optimal results and establish or propose a standard for widespread adoption.”⁴ The best practices we focus on will be general to embedded software, particularly for microcontroller-based systems. Developers and teams must carefully evaluate them to determine whether they fit well within their industry and company culture.

Applying best practices within a business requires discipline and an agreement that the best practices will be adhered to no matter what happens. Too often, a team starts following best practices, but when management puts on the heat, best practices go out the window, and the software development process decays into a free for all. There are three core areas where discipline must be maintained to successfully deploy best practices throughout the development cycle, as shown in Figure 2.

Three blocks depict three core areas to maintain discipline. They are the company, team, and developer.

Developers form the foundation for maintaining best practices. They are the ones on the frontline writing code. If their discipline breaks, no matter what else is going on in the company, the code will descend into chaos. Developers are often the ones that also identify best practices and bring new ideas into the company culture. Therefore, they must adhere to agreed-upon best practices no matter the pressures placed upon them.

Developers may form the foundation for adhering to best practices, but the team they work on is the second layer that needs to maintain discipline. First, the team must identify the best practices they believe must be followed to succeed. Next, they need to reinforce each developer, and the team needs to act as a buffer with upper management when the pressure is on. Often, a single developer pushing back will fail, but an entire team will usually hold some sway. Remember, slow and steady wins the race, as counterintuitive as that is to us intellectually and emotionally.

Finally, the management team needs to understand the best practices that the team has adopted. Management must also buy into the benefits and then agree to the best practices’ value. If they know why those best practices are in place, they will realize that it is to preserve product quality, minimize time to market, or some other desired benefit when the team pushes back. The push to cut corners or meet arbitrary dates will occur less but won’t completely go away, given its usually market pressure that drives unrealistic deadlines. However, if there is an understanding about what is in the best interest of the company and the customers, a short delay for a superior product can often be negotiated.

How to Use This Book

As you might have guessed from our discussions, this book focuses on embedded software design best practices in each area of the embedded software triad. There are more best practices within the industry than could probably be written into a book; however, I’ve tried to focus on the best practices in each area that is “low-hanging fruit” and should provide high value to the reader. You’ll need to consult other texts and standards for specific best practices in your industry, such as functional safety.

I’ve done this to allow the reader to dive into each area of the embedded software triad and provide them with the best practices and tools necessary to balance their development cycles. Balancing can be sometimes accomplished through internal efforts, but often a team is too close to the problem and “drinking the Kool-Aid” which makes resolution difficult. When this happens, feel free to reach out to me through www.beningo.com to get additional resources and ideas. Embedded Software Design is meant to help you be more successful.

A quick note on the Agile, DevOps, and Processes part. These chapters can be read independently, but there are aspects to each chapter that build on each other. Each chapter walks you through getting a fundamental piece of a CI/CD pipeline up and running. For this reason, I would recommend reading this part in order.

I hope that whether you are new to embedded software development or a seasoned professional, you’ll find new or be reminded of best practices that can help improve how you design and develop embedded software. We work in an exciting industry that powers our world and society can’t live without. The technologies we work with evolve rapidly and are constantly changing. Our opportunities are limitless if we can master how to design and build embedded software effectively.