Back to Basics: Fundamentals of Dev Stack Code

By Taryn Engmark

Associate Editor

Embedded Computing Design

In this section, we’ll look at a new set of essential questions to ask yourself to determine what sort of workspace you’ll need to actually begin developing your software.

Welcome to Back to Basics, a series where we’re reviewing basic engineering concepts that require a more complex explanation than Google can provide.

Now that you’ve brainstormed your project and set your overarching project goals and requirements, it’s time to get technical. In this section, we’ll look at a new set of essential questions to ask yourself to determine what sort of workspace you’ll need to actually begin developing your software.

Jenga, Anyone?

A development stack is a way of streamlining your view of the physical tools and libraries you’re using to write code. If you mentally visualize the different tools, libraries, languages, etc. you are using, it can resemble a “stack” of resources.

Finding the set of resources best suited to your project is very subjective. When in doubt, you can start by looking at the lowest item in the dev stack: your programming language.

Translating Your Rosetta Stone

Before you get into your coding groove, it would be prudent to decide what programming language would best suit your project’s needs. There are many to choose from, but there are a few questions that can help narrow down which one is best.

How many platforms will your software be running on? If you’re looking at deploying on multiple operating systems, such as Windows and MacOS, Java or Python may be good options. Java and Python are known as WORA (Write Once, Run Anywhere) languages, meaning that you only have to manage one codebase while still being able to run on multiple systems.

How robust is your hardware? The hardware you plan on using will have a lot of sway over what programming language you can work with.

Java is a high-level programming language that will introduce memory inefficiencies with its simplicity. On hardware with limited RAM — Arduino, for example — this option will most likely lead to problems.
C and C++, offer much more control over memory management, and though harder to work with, are much slimmer in their hardware requirements.
Low-level languages like Prolog, or even Assembly, give the most possible memory control to you, the programmer, but are incredibly difficult to code in.

As a general rule, the smaller your hardware, the more low-level the language, the more difficult it is to code.

What libraries do you want to work with? When picking a language, you’ll want to assess the tools tied to the language itself. Different libraries limit what languages you can use. The Swing library limits you to programming in Java, for example. This concept extends to other areas like database management, game engines, or physics simulations. Libraries directly dictate language, and vice versa.

Once you’ve decided on a programming language, you can start looking at additional tools for your development environment.

Stuffing Your Toolbox

Tools in software development, like any other application, vary in cost, usefulness, and specialization. In database management, for example, it’s useful to include data storage, sorting, and retrieval, and many different solutions exist. For a large-scale app, it would be useful to have a web-based data solution like MicrosoftSQL, but a smaller project might only need a simpler solution like JSON or Excel.

In the end, it all comes back to your design requirements. Tools need to meet cost requirements and align with project scope. Remember: you can hammer a nail in with a screwdriver, but that doesn’t make it a good idea.

Once you’ve made decisions regarding your programming language and development tools, you can start considering where and how to configure your development environment.

Additional Resources:

The next section of this series will focus on the important decisions you'll need to make on Environment Configuration, so click here to read it!

Click here to read the first installment of Back to Basics: Ideation and Requirements

Click here to read the fourth installment: Pseudocode