The Opportunity of Designing Within Technical Constraints
Whatever you are developing there is going to be at least some type of constraint you are working within. Often this can be something such as time or money. These are business-facing constraints. I have yet to see a project that had unlimited time to complete and where there were no economic decisions to be made. At other times we may be faced with technical constraints. These can be things such as CPU speeds, disk space, or the amount of memory available. It can even be something as fundamental as the speed of light can become a constraint in some systems. These constraints often feel like obstacles to what we are working on but often I think this is where we get to show off our creativity and where the joy and the challenge of software engineering can be found.
In the spirit of trying something completely new and as just a fun side project and something I could use around the house I decided to program a microcontroller to run a LED matrix to be an information monitor for my home. The idea being it could show statistics from my home automation tool as well as the time, weather, and other useful information at a glance. I had stumbled upon a few YouTube videos of someone who had done some similar things and it seemed quite different from my day-to-day work of writing distributed web applications. The microcontroller in question is an ESP 32. These are amazing little devices that can be purchased for as low as a few dollars. They have a dual-core processor up to 240 MHz, 320 KiB RAM, and the variety I am using has 4 MB of flash storage. Looking at these specifications as someone that writes Java at their day job they feel paltry. Even then, looking at it from the grand scheme of things it still has some amazing power within such a small, affordable package. Given its constraints though, it unsurprisingly is most often programmed in C++. I hadn't programmed in C++ since the early days of college and had happily forgotten about pointers and manual memory management. C++ is by far much closer to the hardware than many languages and you have to manage everything about what is happening. For example, making HTTP calls I am writing out the Host headers and implementing the HTTP specification itself. There are likely some libraries that you can pull in to simplify some of this however in my search I was unable to find one that fit my needs and with such limited space, the desire to avoid pulling in anything more than necessary was to be avoided. Rather than seeing this as an obstacle, I looked at it as an opportunity to get to know what makes up HTTP more fully. There was also your usual C++ type of issues such as memory leaks from not freeing up objects as well as showing garbage data when I tried to use pointers to already freed objects.
These are not constraints that I am used to dealing with. However, dealing with them has been fun in its own way. They let me consider other things that I don't get to think about at other times. With this microcontroller, I'm not worried about serving many requests a second so that is a constraint I can now ignore but they are replaced by other things. The lessons learned from dealing with these other constraints can be applicable beyond where they are the main concern. Understanding what makes up an HTTP request can help understand what is happening under the hood when using a library in a higher-level language. Thinking about where object allocations and uses are and their relationship with each other can help reduce garbage collector pressure in performance-critical applications.
The next set of constraints came from the RGB LED matrix. The matrix I'm using is a 64x32 matrix meaning I have 2048 pixels to display all the information that I need. This may or may not sound like a lot but I can assure you it is not a lot of space. While I definitely wouldn't call myself a designer, having to design this information radiator has been tricky. Font choice became a huge thing as a font that took one less pixel to show was a huge help, but a the same time I need to make sure it is legible. Finding ways to express data and state via colors or locations of data are another thing I have had to explore. While often in my day job I'm not the one primarily responsible for the design and user experience, having at least a surface understanding of the types of constraints you deal with in this arena has been enlightening and helps me build empathy for those who this is their primary responsibility.
A good step in attacking these constraint-driven requirements is making sure you understand the constraints you are working within. It is only through first understanding these constraints that we can use them to our advantage. Embrace these constraints, they are what make things interesting. Often they are what makes what you are working on worthwhile. If things were straightforward someone else would have already done them.