DevChat: Pros & Cons of Taking the Fast Path to a Solution


Facebook Twitter Link

Every IoT development project comes with time and budget constraints, which means that the IoT development process is always full of potential risks and trade-offs. 

Many of the decisions you make earlier in the process can significantly affect the choices you have available down the line — and there’s no one-size-fits-all approach, as each situation has unique elements to consider. 

Sometimes, choosing a slower path now can mean time is saved later. Sometimes the opposite is true. With every decision, it’s critical to keep the needs of the customer top-of-mind. 

In this post taken straight from our #dev_chat Slack channel (where our engineers collaborate to solve complex challenges), you’ll get an inside look into how our software engineers and product managers work together strategically to find the best solution for every project and client. 

The Cast of Characters

Here’s a list of the experts who appear in this chat, in order of appearance: 

A Quick Glossary

Here’s a quick summary of terms used in the chat that might not be obvious to those who aren’t on our software engineering team:  

  • FW: firmware 
  • GLFW: an open-source, multi-platform library for OpenGL, OpenGL ES and Vulkan development on the desktop
  • HTOP: an interactive system-monitor process-viewer and process-manager
  • Nerves: an open-source platform and infrastructure to build, deploy, and securely manage fleets of IoT devices at speed and scale
  • Scenic: an (almost) all-Elixir framework that builds and runs UI without a browser. It is aimed at IoT devices, has a very small footprint, and works with Nerves.

Sign up for our newsletter

Join 10,000+ subscribers to get the latest IoT development news delivered to your inbox.

Solving for App Performance Issues on IoT Devices

Here’s some context for the problem our engineers were working to solve: on a recent client project, Software Engineering Fellow Justin Schneck was working with Scenic to render an application UI onto an IoT device.


However, he found that the app was running into performance issues, so he shared the challenge on the #dev_chat channel.


Straight from the Chat

Below is the conversation our team had on Slack in response to Justin’s problem — unedited for authenticity. 

Jeff McGehee: What’s the framerate?

Justin Schneck: Sadly I think its only drawing once per 5 seconds. I would need to litter it with debug code to learn more

Daniel Spofford: Can we drop the viewport to what our resolution will be?

config :my_app, :viewport, %{
    name: :main_viewport,
    size: {700, 600},

Jeff McGehee: Can we render with something other than scenic and get better performance?

Daniel Spofford: I believe he wants to use scenic to leverage its work done against GLFW drivers

Daniel Spofford: I still suspect there is some easy win here to get a ton of performance back, seems to me that HTOP screen would have been doing way more work and was an order of magnitude more performant.

Jeff McGehee: Yeah — just pushing on the fastest path again. We can ship a FW update once we’ve launched, but we can’t get time back once we’ve failed to hit a launch date.

Jeff McGehee: If the rendering can be cleanly abstracted from the app logic, it might be safe tech debt to take on.

Daniel Spofford: "Rendering with something other than Scenic" is likely a non-trivial lift that warrants further exploration here before pivoting.

Jeff McGehee: got it 👍

Ryan Solnik: Can we ship a firmware update after we've launched?  Wouldn't that require a support contract to be in place? I also worry just getting something rather than getting something satisfactory might give the customer a bad feeling about what they're paying for.

Jeff McGehee: Not getting anything will give them a worse feeling

Jeff McGehee: I agree we have to meet a standard, but software is easy to fix if it’s designed well, and we have to take wins every chance we can get them.

Ryan Solnik: I don't think we're at the point in the project where we need to start cutting corners to deliver yet.

Jeff McGehee: 👍 yep — the path of the project is your call, and you have more context than me.  I’m more trying to get the team to always think critically about taking the best path forward.  The final path of action should always lie in the hands of the PM and project engineers.

I don’t think that every decision that moves forward fast is cutting corners though.  Any decision that yields time savings and is reversible with work that doesn’t compound over time is probably a good one. If we finish early, we can improve upon isolated decisions that were suboptimal from a product experience perspective, but if we don’t finish, they get nothing, or we eat the cost.

Any time that can be saved without compounding interest is worth saving.  The downside is zero, and the upside is huge.

Product quality IMO comes from iteration through use of the full system, and this cannot be achieved until the full system is functioning.

Jeff McGehee : ☝️these are my opinions, which I will be glad to release given evidence to the contrary, but that giant “blog post” was my attempt to explain/clarify my thoughts rather than assert their universal truth. 

Jeff McGehee: Also, for the kids watching — Ryan and Jeff still ❤️ each other. Healthy discussion/disagreement is critical for us to be the best possible team.

Daniel Spofford: Yeah that is what we are after here: get something that renders with Nerves and settles the controller discussion ASAP.

Not looking for perfect performance right now, only that it can work at all.

What We Learned

The most valuable lesson we can take from this chat is just as Jeff said: healthy conflict is necessary for our team to create the best possible IoT products and outcomes for our clients. Taking the fastest path to a solution doesn’t necessarily mean cutting corners. However, it’s important to consider all of the available options and the side effects of each potential choice. In the end, it’s all about what’s best for the customer. 

Looking for a team to solve complex problems on your IoT project? Get in touch with us today