We’ve captured what the product should do in the requirements phase, the next step is to work out how the software is going to work. Even if no design has been written down before writing code, a developer usually has a one in mind. Of course, writing down the design can help formulate ideas and gives team members the opportunity to review and critique the design. A well-documented design is good practice and the more complex the software, or if multiple teams are involved, the more important documentation becomes.

In software, we can still think of the overall architecture of the code we’re about to write, much in the same that a physical product designer would work out what sub-parts a product is made up of. We can identify the different modules that make up the software and how they interact each other. More detail can then be added on how each module operates.

For our SmartBell, our product is made up of two software packages: the software on the microcontroller, and the phone application. At the design stage we would decide what languages the two pieces of software would be written in, and any tools and libraries that may be used in their development. We also need to determine how the two packages talk to each other. It’s not enough to say the SmartBell and the phone app will communicate over Bluetooth, there may be commands sent from the phone that the microcontroller on the product needs to respond to, or data may need to be formatted in a particular way (this may have been stated as some requirement earlier on). This all needs to be designed.

Drilling down into the design of the microcontroller source code, we want to determine how it will get and process the data from the accelerometer, and how it will handle communications over Bluetooth. There are many approaches to documenting software design, from explicitly writing out the design in words, to graphical designs like sequence and state diagrams. 

Once we’ve worked out what the software should do, we can (finally) start writing code. Software tends to be written in “high-level” languages, such as C or Python, but an additional compiling stage is required to get this code into a machine-readable language. Software is typically developed within an IDE (integrated development environment), a tool that allows engineers to develop software, compile code, and upload it to a device. Most microcontroller and processor manufacturers have IDEs for their products, minimising the time spent on setting up programming environment for the processor we’re working with.

More advanced IDEs allow you test your software, which is a vital, yet often overlooked, part of developing high-quality code. Debugging in IDEs helps you to see how the code is running on the device and pinpoint lines of code which are causing problems.

After writing any code it’s always  important to get someone to look over it (this is the case for any area of product design). Code reviews can take many forms, from a traditional meeting of a team who look over the code and discuss, to using online tools where reviewers can leave comments on code in a similar manner to an online forum discussion. Tools like GitHub provide useful tools for code reviews, alongside being a source code repository.

In part 3, we’ll move onto getting our code into the real world and see how we can check it actually works. If you’ve got a new product or idea you would like to develop, book a call to speak to one of our experienced engineers who can help bring your ideas into reality.