This guide is for the project manager or client who is starting out on developing a device with Arduino, or have already started and is facing the inevitable growing pains that come along with this fantastic educational tool. We’ll take a look at what Arduino was designed for, the purposes it serves, and the hidden costs associated with developing with it. When used in the right context, Arduino is one of the best tools an engineer has at their disposal. It’s fast, well supported, and almost everyone in the industry is familiar with it. It is not a silver bullet for all development goals however. This guide will give context to when to use Arduino and when to let it go.

The Arduino project started in 2005 as a program for students at the Interaction Design Institute Ivrea in Italy aiming to provide a low-cost and easy way for novices and professionals to create devices that interact with their environment using sensors and actuators. Over the past decade, Arudino has become a popular software and hardware development environment for students, hobbyists, and professionals to build electronic projects quickly with a low learning curve. It is an essential part of the developers tool kit because of how fast a project can be built. 

Popular websites like Sparkfun, Adafruit, and others offer a large selection of components with prewritten software designed to run on Arduino hardware with lots of examples. This makes it incredibly easy to get up and running quickly with a high fidelity prototype.

It is important to understand that the same things that make arduino fantastic for prototyping make it inappropriate for production level projects.

It’s very easy to make something that looks like a product. It’s very difficult to build a production level design that is robust and maintainable.

This guide will step through the processes that product teams go through, where Arduino makes sense to use, the limitations it presents, and the traps that development teams can fall into. 

The Beginning

Have you ever heard one of these lines from a stakeholder?

“Do you think we could mock something up quick to see how this looks?”

“I don’t want to spend a lot of time on this”

“We just need something to illustrate the idea, it doesn’t have to be perfect yet”

Or the famous and pervasive one that engineers dread:

“My nephew/cousin/neighbor’s kid makes all kinds of gizmos and they’re only 19, why are you telling me this is going to take so much time?”

Here’s what’s really going on. Arduino has done an absolutely stellar job of achieving its mission to make electronics development accessible and easy to get started with. The barrier to entry for electronics development, IoT connectivity, and embedded programming has been substantially lowered. It is also mature enough that many people who started working with Arduino in the early days as students or hobbyists are now industry professionals familiar with the environment and the advantages of using the platform. In exchange for ease of use and speed of development Arduino sacrifices low level control and efficiency. Arduino is great at connecting a lot of things to prewritten libraries and getting a system up and running quickly. It’s not appropriate for production level work.

The best time to use Arduino is when system level blocks are not defined, or your team is exploring what the user really needs.

“Do I really need a LCD Display or will LED indicators work?”

“Should we use buttons or touch sensors?”

“We have to have an app…I think. I at least want the option…. I don’t know what it will do yet”

These are all perfect use cases to develop in Arduino because change is cheap, technical difficulty is relatively low, and the requirement for a polished user experience doesn’t exist yet. At this  phase; team morale is usually pretty high because everyone is essentially playing around and having fun exploring options. Code development is at the application level, not down in the weeds writing drivers for custom components. Afterall, most of the components in this prototype had code already available from the hobbyist site they were purchased from!

Arduino will excel at getting a system working together…mostly. It will allow the product team to dial in the features that need to exist, and get a sneak peek at a tangible manifestation of the product vision. 

Arduino does not offer a continuous pathway to a production level product, and it was never intended to.

Today we’re surrounded by connected devices, apps, and smart electronics. The DIY community is as strong as it’s ever been, and sites like kickstarter offering new products made by small teams has led to a misunderstanding that developing a connected product is easy. The people who are intimately familiar with Arduino know it’s limitation, but the people who only interact with the prototype based on the arduino often do not. 

Scrum and Agile project management methodologies for software development have found a home in physical product development as well. Agile is based on the acceptance of constantly changing requirements, which any complex project will have. Product development is no exception. 

Many development teams and project managers have their own customized project management practices, however looking through the lens of Agile will serve as a sufficient illustration of the benefits and pitfalls of Arduino.

Let’s take a look at the important parts of what makes Agile successful, and see how Arduino fits in. 

There are a few tenants of Agile that disqualify Arduino for production applications, these are in bold below.

From the Agile Manifesto:

• Customer satisfaction is of highest priority which is achieved through the continuous delivery of valuable software.

• Deliver working software frequently in a shorter timescale.

• The progress of the project is measured by working software.

• Technical excellence and good design should be the main focus.

Continuous Delivery of Working Product

Arduino already has a lot of the initial setup for a given project handled and a simple framework to start writing applications that do real things on your requirements list. It’s skipping ahead to the fun part. The limitation of Arduino comes from its “one size fits all” mentality – it was built for students and novice developers. That means all of the generalizations that make it easy for those new developers are now baked into your prototype.

Arduino development can go fast, but it can’t go far.

“Continuous Delivery” is the sticky part for Arduino development. At the beginning, a team will be able to implement features and make progress pretty steadily. There’s a lot that can be accomplished in this environment, but as the project grows and the feature set gets more sophisticated, The Arduino framework starts to fall apart. Remember that it was developed to be a simplification of what was previously complex. Now that you need the complexity, your team is feeling the squeeze of generic libraries.

Deliver Working Software Frequently in a Shorter Timescale

There is a sneaky assumption built into this mandate that the underlying architecture for the code being developed is going to support your application all the way through development, production, and product maintenance.

What it does not expect to happen is that part way through development, you’re going to max out the capability of your foundation.

Remember, Arduino makes something normally really complicated, really simple. However running the simple things still invokes all the complex things in the background. They’re just hidden from the developer until they become a problem.

What happens is eventually the developer gets to a point where each incremental change becomes more and more difficult. Eventually they’ve maxed out what can be done in Arduino and they have to start tweaking the generic libraries to continue trying to gain efficiency and free up resources for more application features. They’re not familiar with how the libraries were written, so a modification requires learning an entire library. The library was also written to be very generic and supports all kinds of hardware that isn’t relevant to the project at hand. Modifying that library breaks from the officially supported version and now other bugs become more mysterious. This repeats with each new feature.

Arduino trades long term expandability for short term development speed

The Progress of the Project is Measured by Working Software.

Protecting the ability of your team to make progress is one of the most important parts of managing a development project. The kicker that I want to caution PMs on is that if your team is using arduino at the beginning of a project, you have to have a transition plan to a hardware platform that is right for your application. 

Software written in the Arduino environment can serve as a wireframe for the real code development and will be reusable as a definition for what the production code needs to do. It probably won’t be copy/paste compatible though.

The difficult conversation that engineers don’t like to have is explaining to the rest of the project stakeholders why they need to redo everything or start over. It’s something that nobody likes to hear or explain to the project stakeholders, but it happens in every long term Arduino project when there’s not a transition plan on the schedule. The deeper into the project you are, the harder the transition.

Imagine these two conversations

“Guys, I’m really struggling with the code. Bugs keep coming up and I don’t think there’s enough resources left to add these features. I’ll keep trying but it’s getting bad”

OR

“Alright, now that we have the application kinda figured out, It’s time to kickoff the next phase and build up the production version”

The transition out of Arduino when properly managed is a planned event that everyone is aware of and expecting.

Technical Excellence and Good Design Should be the Main Focus

Arduino is a path of least resistance, however it’s only going to excel in the right applications. A sharp knife works well in a sushi restaurant, but it’s not going to be much use splitting wood. First gear is necessary to get up a hill, but if it’s all you have for a cross  bike country ride you’re going to make a lot more work for yourself. 

Photo by Harrison Broadbent on Unsplash