Embedded Template Library

We've been hard at work on our C++ embedded systems framework. A critical design requirement is that the framework core components do not utilize dynamic memory allocation. Unfortunately, this excludes most of the STL containers, as they get storage from the heap by default. Rather than reinventing the wheel, we spent some time searching for existing solutions to this problem. We were quite lucky to discover the Embedded Template Library, an open-source project created by John Wellbelove at Aster Consulting Ltd.

The Embedded Template Library (ETL) is complementary to the Standard Template Library (STL). The ETL provides fixed-size alternatives to STL container type. The ETL containers specify a maximum capacity at compile-time and make no calls to malloc/free/new/delete. As an added bonus, the containers are all cache friendly: storage for all container types is allocated in contiguous blocks.

Most of the ETL containers mimic, as best as possible, the existing STL containers. Additional container types are also provided, such as for memory pools.

We have been heavily using the following ETL modules while developing our framework:

  • <a href="https://www.etlcpp.com/list.html" target="_blank">list</a>
  • <a href="https://www.etlcpp.com/pool.html" target="_blank">pool</a>
  • <a href="https://www.etlcpp.com/queue.html" target="_blank">queue</a>
  • <a href="https://www.etlcpp.com/variant_pool.html" target="_blank">variant_pool</a>
  • <a href="https://www.etlcpp.com/vector.html" target="_blank">vector</a>

The ETL goes further than just providing fixed-size STL container alternatives. The entire library does not use dynamic memory allocation. All storage is allocated either at compile time or on the stack. The library also uses no run-time type information (RTTI). The library provides configurable error handling by allowing the user to choose exceptions, assertions, error logging, or to completely disable error checking.

The library also provides a variety of additional algorithms, utilities, and other features that are useful to embedded systems developers, including:

The ETL is designed to work with C++03, since many projects and chipsets cannot support the newer standards. The ETL is an excellent way to gain access to some modern C++ features on C++03 projects.

The project is well-documented, with reference information available on the ETL Website. John also provides free email support for the ETL.

The ETL is released under the MIT License.

Further Reading

A Look at Ten Hardware Startup Blunders, Part 4: Conclusion

At Embedded Artistry, we've spent countless hours meeting with founders, working at startups, and swapping war stories with fellow engineers. After enough iterations, we started to notice a repeated set of critical strategic missteps made by new hardware companies. These missteps result in compromised designs, increased development costs, and continual schedule delays.

We've selected ten mistakes regularly observed at new hardware companies which fall into three general categories: process, focus, and team. This article is the final article in our four-part series

  1. A Look at Ten Hardware Startup Blunders, Part 1: Process
  2. A Look at Ten Hardware Startup Blunders, Part 2: Schedule and Focus
  3. A Look at Ten Hardware Startup Blunders, Part 3: Team

A Review of Our Top Ten

Mistakes made at the beginning of a company's or product's life can have long-reaching effects.

The beginning is the most important part of the work. -- Plato

The impact of the mistakes we highlight are not immediately apparent. Like cancer, the damage slowly builds up over time until there is no going back. Your company will have to undertake painful exercises to get back on course, and if the damage is too great your team may not fully recover.

When the problems are finally big enough that your team must face them head on, they are often so far removed from the causes that it feels like an inevitable consequence of building a new product. Keep an eye out for signs of these common blunders and make a course correction before it becomes too painful:

  1. Failure to separate research and development phases
  2. Failure to consider data collection requirements
  3. Lack of defined internal processes
  4. Skipping software architecture
  5. Prioritizing mechanical design
  6. Setting the schedule based on hardware milestones
  7. Heading straight to China for manufacturing
  8. Committing to a schedule before having the execution team
  9. Hiring junior or mid-level engineers and expecting senior-level work
  10. Attempting to build a full-stack engineering team

None of these challenges and missteps are new. You can read about some of these observations in engineering classic written in the 1940s. So why are we repeatedly encountering the same basic problems?

Jack Ganssle, an embedded systems consultant, highlights our lack of learning while reflecting on "NASA's lost software engineering lessons":

And today, 49 years later, we still haven't learned those lessons. Large software projects are routinely plagued with the same sort of problems we "learned" to avoid half a century ago.

Jerry Fitzpatrick, a software consultant and author of The Timeless Laws of Software Development has this to say:

Collectively, we don’t seem to be learning from the past. I don’t know if this is due to an education shortfall, the influx of so many new developers, the acceleration of business expectations, or other factors. I suppose if the reasons were obvious, there would be fewer mistakes.

After all this time, the only thing that has changed is that we expect our engineers to produce faster and faster, even though we haven't fixed our fundamental attitudes and processes. We can change the trend and learn from companies who have gone before us.

Further Reading

Here are classic works related to software project management, scheduling, requirements, and estimation:

  1. The Mythical Man Month, by Fred Brooks
  2. Applied Software Project Management by Andrew Stellman and Jennifer Greene
  3. Software Requirements by Karl Wiegers and Joy Beatty
  4. Software Estimation: Demystifying the Black Art by Steve McConnell
  5. The Economics of Software Quality by Capers Jones

For a straightforward approach to software project estimation, try the Wideband Delphi technique described in the Karl Wiegers's paper "Stop Promising Miracles".

We frequently write about product development on Embedded Artistry:

The following websites provide excellent product development and manufacturing advice that can benefit new hardware teams:

Jack Ganssle, a veteran of the embedded systems industry, shared his own "Top 10 List for How Embedded Projects Run Into Trouble". He's also published a series on embedded.com which covers each point in further detail:

Thanks for Reading

Thanks for following this series. We hope that you will be able to identify and avoid these common blunders on your next project. We must learn from our mistakes to avoid repeating them endlessly. Wouldn't you rather solve new and interesting problems instead of rehashing the same old ones?

Would you tell me, please, which way I ought to go from here?”
“That depends a good deal on where you want to get to,” said the Cat.
“I don’t much care where–” said Alice.
“Then it doesn’t matter which way you go,” said the Cat.
“–so long as I get SOMEWHERE,” Alice added as an explanation.
“Oh, you’re sure to do that,” said the Cat, “if you only walk long enough.”

  • Alice’s Adventures in Wonderland, Chapter 6

A Look at Ten Hardware Startup Blunders, Part 3: Team

At Embedded Artistry, we've spent countless hours meeting with founders, working at startups, and swapping war stories with fellow engineers. After enough iterations, we started to notice a repeated set of critical strategic missteps made by new hardware companies. These missteps result in compromised designs, increased development costs, and continual schedule delays.

We've selected ten mistakes regularly observed at new hardware companies which fall into three general categories: process, focus, and team. This article is the third in our four-part series and focuses on team-related mistakes.

Team-related Mistakes

Building a team which can execute on your company’s business goals is a challenging task. Team composition can make or break a new company due to the serious cash flow constraints they face. Companies must focus carefully on hiring to ensure they have a mix of senior and junior engineers while also building a balanced team focused around the core business value. Hiring recklessly or staffing up too quickly can become a serious drain on company resources and morale.

The following three mistakes related to team composition are among the most common we encounter at new hardware companies:

  1. Committing to a schedule before having the execution team
  2. Hiring junior or mid-level engineers and expecting senior-level work
  3. Attempting to build a full-stack engineering team

Committing to a Schedule Before Having the Execution Team

In the previous article, we discussed how teams can build an unworkable schedule by focusing exclusively on hardware development milestones. Another major scheduling mistake is committing to a schedule before hiring an engineering team to execute your plan.

Hardware startups often base their schedules around market timing or investor expectations. The schedules are entirely fantastical, since teams construct them without input from the engineers who will be designing and building the product. Fundamentally, the company has agreed to deliver a product before having the ability to produce that product.

Teams making this kind of overly-aggressive schedule also exhibit unrealistic expectations for the time it takes to hire engineers, especially firmware developers. Young teams often think they can fill an engineering position in 2-6 weeks. Reality is not so kind: in the San Francisco Bay area, we find that it takes between 3-6 months to hire for each firmware engineering position. If a team’s schedule is dependent on quick hiring, reality will expose the plan as impractical.

When the leadership team sets the schedule without input from the actual engineers doing the work, and the hiring takes longer than expected, the new engineers that join the team are immediately put under pressure. The firmware is almost always “late” by the time the first engineer joins the team, and everyone else on the team is anxious to see the system working. This situation leads to conflicts, cutting corners, unhappy engineers, and delayed releases.

Your schedule is ultimately dictated by the capabilities of your team and the staff you have on hand at the present moment. You need your team’s input when creating the plan. Keep these facts in mind and create a schedule that matches your team’s realistic capabilities.

Hiring Junior or Mid-Level Engineers and Expecting Senior-Level Work

The most common mistake we see young hardware companies make is hiring junior or mid-level engineers and expecting them to produce senior-level work. This can occur because the CEO is not aware of a senior engineer’s value, because the schedule “necessitates” beginning work without senior engineering guidance, or because the team gave up on finding a senior engineer after a long search.

Hiring a senior engineer is essential for the success of a project, especially in today’s world of highly interconnected systems. These companies simply must start with someone who has shipped products before and led the whole process first hand. Junior engineers lack the experience, perspective, and design skills necessary to architect and build new systems. When someone with underdeveloped engineering and design skills builds a system, the most common result is a hard-to-maintain system held together with duct tape and prayers. What’s under the hood often resembles a shanty town, not the 5-star hotel the CEO envisioned. New features become increasingly difficult (or impossible) to implement due to the fragility of the system. When you add multiple interacting systems into the mix, the resulting design problems can multiply and prevent you from shipping your product.

Senior engineers have the experience and foresight to set requirements and identify critical design problems before it’s too late. They can provide guidance to junior engineers and ensure that they aren’t overtaxed. Senior engineers are also crucial when working with contractors, design houses, and other external suppliers. Junior engineers may not have the experience or perspective to review the work products, judge whether the quality is sufficient, and determine if the design satisfies the requirements. Having a senior engineer to manage the work of external teams acts as an insurance policy against integrating low-quality work into your system.

If you want to avoid schedule delays and hard-to-maintain systems, you must have senior engineers on staff.

Attempting to Build a Full-stack Engineering Team

Many new hardware companies focus on building a full-stack team that can handle all aspects of product development. As my friend Saket Vora pointed out, companies should instead build a team that focuses on their core business value.

Most small companies outsource accounting, bookkeeping, and payroll activities to external firms, since they do not directly contribute value to the business. For most new hardware teams, they can likewise outsource the bulk of firmware and hardware development to consultants, contractors, and design firms. Given the difficulty in hiring senior engineers at early stage companies, utilizing external experts can also help alleviate the problem of expecting senior-level work from junior engineers.

Unless your company’s focus is innovative firmware or electrical development, writing firmware and designing circuit boards does not add direct value to your business. Your team will need one experienced engineer who can integrate and review the outsourced work. Your remaining full-time engineers should be fully focused on feature development, integrating with external services, and improving the customer experience.

Another aspect to consider is whether you can justify the employment of your full-stack team. We’ve repeatedly seen companies hire multiple full-time firmware and electrical engineers and successfully keep the team busy while shipping the first product. As efforts shift from new product development to feature improvements, marketing, and customer support, these engineers find there is no work for them to do. If you don’t immediately have the second product on deck, the under-utilized engineers get laid off, leave the company because they’re bored, or simply hang around and serve as a drain on your runway.

Headcount is a precious commodity, and it can quickly turn into an anchor on your company. Make sure you carefully build your team to deliver on your core business value propositions. You don’t get style points for doing it all in house, and the customer can’t tell the difference.

Next Up

That’s it for common team mistakes. Next week, we’ll summarize our list of ten common blunders and provide resources for teams that wish to learn more about product development and project management.