The pitfalls of rushed development with mixed frameworks
Developing software that controls hardware is undoubtedly challenging, and ultimately, very rewarding once it’s working. In an effort to help make the process a bit smoother, this post focuses on the importance of addressing friction points when trying to merge development frameworks and shares lessons learned.
A piece of hardware, such as a custom board, can have one set of design input requirements (DIRs) to meet many customer use cases when it’s part of a bigger system. For example, temperature control between 4°C and 40°C is a DIR. Controlling temperature at setpoint, changing setpoints, and shifting setpoints manually or with automation are use cases that empower the user. The problem is that software DIRs don’t capture these use cases very well.
Siloing software development into projects based on DIRs forces software engineers (SWEs) to narrow their planning. For example, the first project is to just control the temperature at setpoint, not realizing that a later project will allow a user to change the setpoint. Trying to compensate by releasing user features while still using a waterfall project framework leads to a lot of issues, including lack of transparency on future use cases and short-sided tradeoffs that affect stability.
Mixing development frameworks
Project goals are a little selfish because they require a thing to be delivered on time. Especially for this reason, they often forget adjacent, dependent projects. The goals are important, though, because they describe everything that is necessary to make the project a success. Any gaps can really impact useability.
SWEs like to work in an Agile framework. Building software is more flexible and forgiving than hardware. SWEs like shipping often to users and relying on the feedback to refactor. Combining a waterfall project and Agile framework obviously has issues.
Software DIRs as described above don’t tell what the user needs. For example, the user may need transparency about the current temperature setpoint, measured temperature, and upcoming automated changes. Shipping a feature that allows only temperature control without easy access to the automated script makes transparency difficult. User feedback will reflect this gap, and valuable project time is required to refactor and meet the gaps in usability.
The time spent refactoring primarily eats away at two things: fewer project goals can be completed and fewer projects get started. Teams intuitively know and expect this heavy refactoring and budget time for it, meaning fewer goals completed. Project timelines are subsequently extended, so new projects are delayed or skipped.
Risks of siloed projects
Combining waterfall with intermediate user releases for feedback and iteration ultimately loses focus on the broader picture. Easy wins to meet UX expectations become prioritized because leadership can easily see and report progress on the perceived gaps. Required features for robustness and stability are sacrificed without even realizing it.
Siloing architecture decisions into separate projects with strict release timelines also pushes architecture to a low priority. Novice teams will mistake high velocity to also mean the system can scale or withstand edge cases. Siloing architecture development also impacts the robustness of the product — it’ll be built piecemeal, organically. There will inevitably be severe tech debt that’s not understood until it’s empirically observed in full end-to-end testing.
A better approach is a transparent and clear roadmap with objectives and outcomes for each feature. A roadmap gives SWEs the necessary insight to architect the backend well through multiple development cycles. It can facilitate a conversation around expectations as the product matures. User releases and feedback can be folded into future developments instead of immediate refactors.
Test and fix early
Along with unthoughtful architecture, a solid QA testbed and framework will be relegated in this development environment. Rushed timelines don’t include adequate time for robust testing or meaningful user feedback. A solid testbed and environment are so critical to many things, helping teams understand how the software and hardware are practically working together by running low-cost automated tests and high-cost manual tests. If the burden to set up a test is too high, the team will of course kick the can down the road.
The expectation is simply that things work but that’s often not what actually happens. It’s important to characterize how the software works by empirical observation, running wet tests and full tests. A fixed project schedule doesn’t give any room for addressing bigger bugs found in testing. So, they’re also inevitably kicked down the road.
Asking to harden features at the end of project cycles without extensive user feedback or software-hardware testing also inherits tech debt. Features will break as underlying firmware or drivers need to be modified. Then refactoring is a very expensive exercise and begins to cost multiples of originally estimated time.
Lessons learned
There’s certainly no one right way to build software for hardware. Ultimately, the market will tell you if you did it well. But with the long lead times before hitting the market, the software development life cycle becomes very important.
Trying to “go fast” to meet deadlines without product discipline will likely lead to a badly understood product. For example, if DIRs and waterfall are chosen, then the product team must be comfortable not refactoring UX until meaningful user feedback is available. As development timelines inevitably slip, it’s important to understand why velocity is slow and address the systematic reasons, whether it’s support distractions, a poor testing environment, or something else.
To meet delivery deadlines, entire features should be moved to post an alpha or beta test; the tradeoffs should be shipping a smaller scoped product with confidence over a bigger product that is on shaky infrastructure. This means ruthless prioritization of the DIRs and what’s really necessary for the MVP.
So, three takeaways to keep in mind:
- There are no shortcuts (including hardware DIRs) to actual software user research.
- A software roadmap is really important to ensure architecture is thoughtful.
- Don’t mistake releasing features “on time” with releasing a successful product.
informal is a freelance collective for the most talented independent professionals in hardware and hardtech. Whether you’re looking for a single contractor, a full-time employee, or an entire team of professionals to work on everything from product development to go-to-market, informal has the perfect collection of people for the job.