Issue #7: The Map of "pocketDevOps"

Let's take a step back for a moment.

We've spent several issues exploring individual pieces of the puzzle - feedback loops, testing pyramid, the DevOps cycle adapted for embedded systems. But I haven't shown you the full picture yet. Where are we going? What are we actually trying to build here? And why?

Welcome to the "pocketDevOps" newsletter.
Not subscribed yet? Want the next issue delivered straight to your inbox? Join the newsletter here.
If this email doesn't display correctly, you can read the web version here.

What problem is "pocketDevOps" trying to solve?

Small teams working on embedded systems face very similar problems to large organizations: unclear requirements, difficult decisions, integration surprises, missing data, lack of testability, lack of repeatability. The difference is that small teams don't have the resources of large companies - no dedicated infrastructure, no specialized departments, no time to build enterprise-grade processes.

I'm creating the "pocketDevOps" for them.

But before I show you the idea, I want you to do one thing. Look at the project you're currently working on and answer these few simple questions. Be honest with yourself.

About your requirements:

How much would it hurt if half of your project requirements changed overnight? Do you have a mechanism to quickly validate the impact of those changes?
How confident are you that you're building "product A" and not "product B" without knowing it yet? Can you quickly prove that your product aligns with its requirements?
Can you prove that your regression tests cover all requirements? And that you're not testing things that aren't in the requirements at all?

About your project history:

Can you reconstruct the history of design decisions and understand why the system looks the way it does?
Does everyone on your team share the same understanding of the project's business assumptions?

About your decisions:

How long does it take you to make critical decisions? Do you have time to gather and analyze data? Or are you constantly busy and making decisions in a hurry based only on gut feeling?
Do you have any data about how your product actually behaves in the real world? Are your decisions driven by telemetry and observability - or by assumptions?

About your process:

How often do you integrate all parts of the system? Is integration a continuous process, or something you keep postponing, hoping everything will just work at the end?
Is every release of your product fully reproducible and complete? Could you rebuild it exactly, bit for bit, right now?

About your resilience:

What happens if the microcontroller you're using disappears from the market tomorrow? How long would it take to port your firmware to a new platform - days, weeks, or months?
If you were hit by a bus tomorrow and you were out of action for a several months, would your team be able to continue your work from where you left off? Or would they have to rebuild your part from scratch?

If at least one of these questions made you uncomfortable - good. That means "pocketDevOps" is for you.

The root causes

These questions aren't random. They come from the most common causes of embedded project failures - problems that repeat across industries, technologies, and project scales.

Teams don't understand the product they're building. Requirements are unclear, inconsistent, or unverified. Decisions are made on assumptions instead of data.
Project assumptions go stale, but the plan doesn't change. Requirement changes are painful because there's no mechanism to quickly validate their impact.
System components are built in isolation. Integration is postponed. When it finally happens, components don't fit together - and it's too late to revisit the initial assumptions.
Critical decisions are made under time pressure. Without full context and without data. Telemetry, observability, and real product analysis are missing.
Project history is unreadable or nonexistent. It's hard to reconstruct why the system looks the way it does - which increases the risk of errors, delays, and a high bus factor.

All of these problems share a common root: the absence of a working philosophy that ensures understanding, testability, measurability, integration, and fast feedback loops.

What you actually need

To minimize risk, you need to change the way you think about your project. Here's what that looks like in practice:

Understanding-Driven Development - You can't build something you don't understand. Minimize errors caused by missing context. Verify your hypotheses through experiments - base your architecture decisions on data, not opinions.
Agile Project Management - Agile isn't about ceremonies. It's about reducing risk. Assume everything could change at every stage of the project, and plan for it. Build in iterations - verify the idea before committing to a full-scale feature.
Interdisciplinary Teams - Gather Hardware, Firmware, Software, and Test engineers in one place and let them build together - iteratively. Build incrementally across all domains in parallel. Foster direct communication on a daily basis.
Process Automation - Your time is precious. If you have a cyclic task that is difficult or tedious to perform, automate it. Focus on the work that actually moves your project forward, and let automation do the rest.

The "pocketDevOps" Cycle

Those four principles are the philosophy. But philosophy needs a structure to become a habit. That's what the "pocketDevOps" Cycle provides.

You've seen this diagram before. But today, with the full context of the problem in mind, I want you to look at it from a fresh perspective.

pocketDevOps full diagram

Each step has a specific purpose:

PLAN - Refine and verify your requirements. Focus only on features for the next iteration. Assume everything else will change - plan for change.
BUILD - Create the next product increment. Not a complete device prototype - just the minimum needed to deliver a new feature or test a hypothesis. If you can't prepare the next hardware iteration, consider simulating or emulating it.
INTEGRATE - Integrate hardware, firmware, and software as often as possible - at least once per iteration. This helps catch requirement mismatches and gaps early in the process.
ANALYZE - Monitor your product's behaviour. Draw conclusions from the collected data. Adjust your plan based on new insights. Then start the next iteration.
RELEASE - After N iterations, release your product into users' hands.
FEEDBACK LOOP - Get feedback from the field and use it to drive the next round.

You can find more context on the reasoning behind this diagram in the previous issues:

The "pocketDevOps" Framework

Philosophy is philosophy. But to put it into practice, you need tools.

The "pocketDevOps" Framework gives you those tools, organized into six pillars. Think of this as a map - each pillar covers a specific area of your development process. Together, they address every problem I mentioned above.

1. Requirements Management

Refine and verify your requirements. Make sure you're building the right product - and that everyone understands it the same way. This is where the foundation is built: what you're building, why, how you'll verify it, and when you'll consider it done.

Behavior-Driven Development - Write testable requirements. Every requirement must be verifiable by at least one test.
Test-Driven Development - Build your product with testability in mind from the very start. Give yourself the confidence to modify code without worrying about breaking it.
Spec-Driven Development - Requirements as context for AI Agents. Define behavior first, then implement.
Bugs and Issues Tracking - Treat bugs and issues as missing requirements. They are a living record of every edge case and every weird behaviour your system has encountered. They extend your specification.

2. Documentation

Document everything you do. In a few months, you won't remember what you did today. Write it down for your future self. Documentation is your project's memory. Without it, you lose traceability, consistency, and resilience to bus factor.

Docs as Code - Version your documentation alongside your project. Keep it aligned with your project history.
Live Documentation - Make sure your docs always reflect the current state of the system.
Test Reports - Use reports from testing sessions as an extension of your documentation.
Context for AI - Documentation that AI Agents can read and use, supporting further automation.

3. Observability Pipelines

Implement feedback loops. Make sure your project decisions are based on real data, not on assumptions.

Automated Code Analysis - Use automated tools for code analysis. A computer will analyze your code faster and more consistently than any human.
AI Code Reviews - Automated code reviews (as an extension of human judgement) supporting consistency, style, and requirements alignment.
Telemetry - Aggregation and visualization of telemetry data: metrics, logs, and traces.
Failure Prediction - Collect logs from your devices in one place and analyze them looking for anomalies before they become incidents.

4. Multitarget Firmware Development

Eliminate hardware restrictions from your firmware. Your firmware must be portable, testable, and resilient to unexpected hardware changes.

Managed Environments - Ensure every member of the development team uses the same tools and environment configurations. Use the same configuration across your CI/CD pipelines for consistent builds and releases.
Multi-target Build Systems - One build configuration for multiple platforms and architectures.
Multi-target Firmware Architecture - Hardware-agnostic business logic, data-driven hardware abstraction, thinking in targets.

5. Automating Testing and Debugging Sessions

Build testing harnesses for AI agents and automation scripts. Automated testing and debugging is the foundation of fast iterations and continuous integration.

Testing Firmware on Host - Build your firmware architecture so you can test it on your development machine and in CI/CD pipelines - without real hardware.
Testing Firmware on Target - Use Hardware-in-the-Loop setups to automate firmware integration testing on real hardware.
Automating End-to-End Testing - Human-in-the-Loop automation, Robotic Process Automation.
Automating Debugging Sessions - Automated debugging scripts and AI agents supporting error analysis and problem reproduction.

6. Release Automation

Ensure consistent releases by always building and testing from the same centralized project configuration. Every release must be repeatable, reproducible, and aligned with requirements.

Centralized Repositories - You need a single source of truth for your project files and tool configurations.
CI/CD Pipelines - Make sure your product is always in a releasable state - or be aware of exactly why it isn't.
Factory Tests - Before sending a product to a customer, test every single unit.
Managing Firmware Updates - Gain full control over whether, when, and to which firmware version your product is updated.

This is a work in progress

I'll be honest with you, "pocketDevOps" is still taking shape. I don't have the full picture yet, and not everything is clear to me. Some of these concepts are still evolving. That's normal - every framework starts with intuition, a sketch, a few strong assumptions, and many unanswered questions.

That's exactly why I want to build this in public.

The best tools and methodologies are created together with the people who will use them. I'm counting on the embedded community - your comments, criticism, suggestions, real-world examples, stories of projects that succeeded and ones that didn't. Every signal like that helps me better understand what small embedded teams actually need.

So if something on this map doesn't make sense to you, or if you think something important is missing - let me know. This map is not finished. And I'd rather draw it together than guess on my own.

That's it for this newsletter. I'd love to hear what you think. Email me or catch me on LinkedIn.
I'm Jakub Zawadzki, and I hope to see you in the next one.

Quick note: English isn't my native language. I use AI assistance to help me write more clearly. But all the ideas, experiences, and opinions you read here are 100% mine. If you find any errors in this text, blame me directly, not AI.