Ian Adam THUMB

Ian Adam

Design

Interaction Design

Engineering

Electrical & Software Engineering

There are an infinite number of ways to write the software for an embedded system. How do you decide which way is the right way? 
Your number one priority should always be to write code that meets the system requirements. But how the code is written can have an immense impact on modularity, maintainability, and testability.

Delve's experts in insights, strategy, design, and engineering can guide you through an end-to-end innovation process that delivers results.

Our Services Page: Product Design and Development (text only)

At Delve, we often employ an approach called “Tell, Don’t Ask,” or “TDA” for short.
<h2>What is “Tell, Don’t Ask”?</h2>
Tell, Don't Ask&nbsp;says objects should be responsible for their own data. And those objects should be the ones to make decisions based on that data, not the application at large. Tell, Don't Ask&nbsp;has been popular among object-oriented programmers for years.&nbsp;

Note: <a href="https://www.delve.com/news/delve-bresslergroup-unite-under-one-name-delve" target="_blank">Bresslergroup is now Delve</a>. This Design Defined video was recorded prior to the merger of Bresslergroup and Delve.

Rather than write code that asks an object for data and uses that data to make a decision, TDA says the code should tell objects to use the data they have to make decisions for themselves. The principle considers data, and functions that operate on the data, as part of the same class.
<h2>Example: Using TDA for a Battery-Powered Device</h2>
To demonstrate how TDA simplifies application level code, consider the example below.
This could be for something that runs off of primary cells but has backup rechargeable batteries — like a handheld medical device or a portable gaming console. The code puts the system in standby when the battery is low.

Coding simplified embedded system inline1

In the non-TDA example, the device asks the object what the battery percentage is. If the object responds that the battery power is low, the device will put the system in standby. In the TDA example, if the battery power is low, the object will initiate standby.
In the non-TDA example, the application is responsible for knowing that the critical battery level is different when running off of double-A batteries versus LiPo batteries. It’s also responsible for knowing the critical threshold for each and initiating standby mode.
In the TDA example, all that low-level knowledge, and the execution, is contained within the power subsystem. As you can see, the code is greatly simplified as a result.
<h2>TDA Encourages Good Programming Practices</h2>
This advice applies easily to embedded programmers using C++. It’s equally valuable for most of the embedded community who are using non-object-oriented languages like C.
For object-oriented programmers, TDA encourages good programming practices like encapsulation and event-driven design.
In embedded systems, it encourages the programmer to decompose the system into modules that are responsible for their own data. TDA aims to take low-level decisions away from the application and give that decision-making power to the modules.
This yields a number of positive effects. When code is broken into modules, the application is simpler, the code lends itself to reuse, and maintenance is easier because bugs can be spotted quickly.

Coding simplified embedded system inline2

<h2>TDA Safeguards Products for the Future</h2>
A future engineer who has to modify the application is unlikely to know or care how the values in the example above were chosen.
Encapsulating that decision-making in the power subsystem makes it less likely those values will be inadvertently modified or left out by a future maintenance effort.
<h2>TDA Streamlines Testing</h2>
Code that’s written using TDA can be tested more easily, too.
One consequence of the principle is that the system is easily exercised from the command line. The command line interface is essentially an extension of the powers granted to the application. If the application design is complex, the command line code to exercise the system will be complex.
Instead of manipulating the data in modules to trigger events, events can simply be dispatched by the command line. This technique is not adequate to test modules at the function level, but it helps greatly with integration tests.
<h2>TDA Makes Sense for IoT Devices</h2>
This principle lends itself well to IoT products that combine real-time data collection and an asynchronous networking module.
In these products, the application usually oversees data collection at a high level, aggregates data, and transfers it to the internet or a mobile device.

By decoupling the intricacies of the low-level system from the application layer, it frees the designer to focus on elegant and stable top-level design.

<h2>The Origins of TDA</h2>
“Tell, Don’t Ask” comes from a book called <a href="https://en.wikipedia.org/wiki/The_Pragmatic_Programmer">The Pragmatic Programmer: From Journeyman to Master</a>, by Andrew Hunt and David Thomas.
Published in 1999, it’s one book in a series called “The Pragmatic Bookshelf.” It aims to provide a collection of practical suggestions to improve software development.
Since it was written, several concepts from the book, such as “rubber duck programming” and TDA, have become popular in the industry.
<h2>Putting TDA to Use</h2>
Can you use “Tell, Don’t Ask” to simplify your embedded systems? Once you begin to think about how the principle might benefit the IoT or embedded devices you’re working on, you’ll discover lots of opportunities to put it to good use.
To explore other key product design principles, download our ebook, Design Defined:

Proving out robust and clever technological, mechanical, and electrical solutions, we rapidly and rigorously move your product ideas to launch.

Services Page: Electrical & Software Engineering

Download: Design Defined 30 Key Design Principles

Learn more about&nbsp;<a href="https://www.delve.com/services/engineering/electrical-software-engineering" target="_blank">Electrical Hardware & Software Product Engineering at Delve​.</a>

SEO Text: Electrical & Software Engineering Services

Coding simplified embedded system Hero image

There are an infinite number of ways to write the software for an embedded system. How do you decide which way is the right way?

Contact Us | General (Let's build something together)

Digital

Home

Insights

‘Tell, Don’t Ask’ Is a Design Principle for Simplified Embedded Systems

Breadcrumbs

A full-service product design and strategic innovation consultancy.

Delve

There are an infinite number of ways to write the software for an embedded system. How do you decide which way is the right way?

description

generator

kSwNn6qD4B-4HloWnWMUBWQNpBx2_mPi3nMqgsh6ato

google-site-verification

ways, write, number, software, infinite, embedded, decide, right

keywords

https://cms.delve.com/assets/images/_1200x630_crop_center-center_82_none/coding-simplified-embedded-system_Hero-image.jpg?mtime=1709227982

https://linkedin.com/company/delvedesign/

‘Tell, Don’t Ask’ Is a Design Principle for Simplified Embedded…

https://www.delve.com/insights/tell-dont-ask-is-a-design-principle-for-simplified-embedded-systems

referrer

robots

twitter:card

twitter:creator

twitter:description

https://cms.delve.com/assets/images/_800x418_crop_center-center_82_none/coding-simplified-embedded-system_Hero-image.jpg?mtime=1709227982

twitter:image

twitter:image:alt

twitter:image:height

twitter:image:width

twitter:site

twitter:title

{"title":{"title":"‘Tell, Don’t Ask’ Is a Design Principle for Simplified… | Delve"}}

Think Digital

Privacy Policy

FCOI Policy

Services

Case Studies

Testimonials

What We Do

About Us

Our People

Join Our Team

Careers

Newsroom

Who We Are

Boston

Madison

Philadelphia

San Francisco

Our Studios

Partner with Delve

Contact Us

Contact

Vamsee Pamula, Founder &amp; President, Baebies

Read informative articles from Delve's team of experts. Discover innovative strategies and insights about product design, engineering, and development.

Delve Insights: Product Innovation & Development Blog

innovation, product, design, advice, development

https://cms.delve.com/assets/images/_1200x630_crop_center-center_82_none/Delve_titlecard.png?mtime=1654035558

https://cms.delve.com/assets/images/_800x418_crop_center-center_82_none/Delve_titlecard.png?mtime=1654035558

‘Tell, Don’t Ask’ Is a Design Principle for Simplified Embedded Systems

‘Tell, Don’t Ask’ Is a Design Principle for Simplified Embedded Systems

Related Insights