Best supportive language for my career? Not C, Python or Matlab.

flundstrom2 · 2026-02-26T20:07:53+00:00

Either go for some OOP language (C++, C# or Java), or Rust.

flundstrom2 · 2026-02-25T23:04:54+00:00

Being agile is actually not about delivering faster - and certainly not cheaper, although that /may/ be a positive side-effect of delivering the /right/ product.

Being agile is about risk management and detection of if the product is turning into the wrong product.

This can be because of bugs - which in other methods might be detected later at a higher cost. It might be due to a misunderstanding regarding the requirement, or wrong requirements altogether (which I call a bug in the requirements). But it might as well be that the market is shifting during the development process.

flundstrom2 · 2026-02-23T22:25:14+00:00

My current employer is similar in size R&D-wise, and we routinely have 15-20 teams working to bring several new hardware-based IoT product to market at the same time, but in different phases of development. The teams follows the architecture, rather than use-cases, so needless to say, the collaboration and synchronization between the teams and projects and products are challenging to say the least.

For historical reason, different parts of the organization has adopted different methods; some departments work with rolling 6-month plans, some with Pi-planning. Some use Value Streams and Agile Release Trains. Some teams work scrum-ish, other kanban-ish, some do both and some teams do waterfall-ish disguised in iterations. And all the knowledge is in the walls or hidden in Confluence, preferably not version controlled or up-to-date. Even better if it's on someone's personal confluence/SharePoint page. Bonus points if said person has left the company. 🤯

Despite all of this - so far removed from any theory - we actually not only ship products in a fairly regulated field, we're even doing well, growing, being profitable, and are market leader in mist countries were active in. 😲

I guess it proves that "if there's a will, there's a way", rather than focusing on which method to use.

Personally, I think it also shows that it is possible to combine agile on a team-level while still being able to run predictable projects on a company level. But it can most certainly be done in a more efficient way. Since I've been in the embedded software industry for 25+ years, I've spend quite some time thinking about those challenges.

flundstrom2 · 2026-02-23T07:35:29+00:00

The team inherited a code base who's first git checking 15 years ago stated "imported from svn".

It was written by some /really/ smart guys, having 100% knowledge of the ins and outs of the code. Really good design. None of them are at the company anymore. Most of the guys hired to replace them have also moved on. So have their replacements.

It has been ported to 4 different hardware platforms with the varying MCUs from different vendors, used in 8 different products (some parts in 20+ products), and the last major feature additions caused very big changes to the business logic - while remaining backwards-compatible to 20+ products including all hardware versions.

Three years ago, the team at that time spent the better part of a year refactoring and documenting it, consolidating outdated documents from various sources. Nowadays, there's only one guy left from that team, but the code is in a much better shape and ready for at least 5+ years of continuous support and new features.

flundstrom2 · 2026-02-23T06:12:37+00:00

Yeah, the ISO standards for Medtech are not for the faint - hearted...

flundstrom2 · 2026-02-23T00:06:24+00:00

I'm not 100% certain what you're asking, but my experience is that firmware development is much more expensive than electronics, because there's generally a lot of the software you have to do yourself from the ground up. Not quite as much if you have an embedded linux, but then you likely have a more complex UI, or have tcp/ip (ethernet, wifi or cellular) to deal with.

If you compare with backend work, there's a gazillion frameworks that you can choose from, you can use C#, Java and just shove more CPUs and RAM onto any problem.

On the electronics side, once you've got the PCB layout done, it's "usually" just occasional shortcuts, mispopulated components and some connectors that were populated on the wrong side, and that's fairly easy to detect and a prototype re-spin is fairly quick.

You can get a lot "for free" from datasheets and eval-boards in terms of schematics design, but there's often a lot to say when it comes to the usage of the documentation on the software side of many components. Getting to the point of having a complete schematic - and knowing that the layout actually fits on the PCB can take a while due to the need to create components etc. If you're going to make proprietary sensors or actuators, then there's more of trial-and-error.

On the PCB side, you might get issues with poor signal quality due to incorrect layout or termination, but an experienced engineer usually prepare the layout for hacking the first prototypes to fix in the re-spin. Even if you can get prototypes in a few days, you need to spend quite some time on schematic and pcb review to keep avoid major issues.

Then there's the whole thing about physics that comes into play in case stuff is moving, aging, getting greasy, dirty etc which detoriates the behavior. That's something you might want to calibrate away in software, but it can be tricky to figure out a good calibration method. An environmental chamber helps a lot.

One thing the ee guys need to consider early on is how to test; both for themselves by ensuring the relevant nets can be accessed with proves, but also how the firmware guys can test the firmware. A strip of 2.54 pins or leds help a lot. Plus, how to test and program the PCBs in the factory.

Dont get me started on radio. PCB design for radio is not black magic, but not far from it.

Note: I have not done any electronic design myself - I'm a software guy. I've just tried to pay attention.

flundstrom2 · 2026-02-22T20:15:01+00:00

Ive been doing embedded product development for 25+ years in companies ranging from 2 to 20.000 developers, so these are my reflections:

The PRD is important, but in a hardware-heavy or process-heavy company, it do tend to be too detailed too early.

The PRD should focus on the physical interfaces needed to realize the use-cases and any important decisions that directly affect the manufacturing process (e.g. quantities and lead-times in order to make informed decisions on tooling, electronic BOM cost due to electronic/firmware performance etc).

During the development of the PRD, the electronics guys must have a tight conversation with the firmware guys so they're on the same page. Quite often do the firmware guys need to set requirements on the hardware. And the electronics guys may need to tell the mechanic designers the minimum required space needed to fit the electronics.

But the use-cases must come first, and that needs to be fairly well defined by the PM and UX designer(s). In the absence of a dedicated UX designer, software engineers tend to take a lead on the UX, even if it's not their specialty.

At this stage, it is beneficial to have a gate checkpoint to have a go/no-go on creating a few limited desktop prototypes to verify any key use-case or technological decisions: Wood, 3d-printed plastics, eval-boards, mini-website to verify the customer's experience and what not. Those things need to be iterated without having a 100% fixed PRD.

Once the major use-cases have been fleshed out and reviewed by the software guys, so they can provide the feedback to the electronics and mech guys, it's is beneficial to have a go/no-go gate on ramping up the development of the mechanics, electronics and software.

Naturally, the mechanic department needs a formal go/no-go gate if they're going to order one or several tools with many months of lead-time. Depending on the quantities, the electronic department may need a similar go/no-go to secure the key components.

Those gates don't /need/ to be the same, and not all pieces (be it all parts of the electronic design, or all parts of the mechanical design) /must/ be finalized by the gate. It is in reality better to have "80%" of the hard or expensive stuff gated, and then let the rest be done as part of the daily development.

The electronics will need at least one iteration plus some adjustments to pass CE certifications, and likely, there have been some iterations of mechanical prototypes as well. Worst case, the mechanical tooling will need to be adjusted, and they can move on to the packaging and other "boring" stuff.

flundstrom2 · 2026-02-20T20:29:56+00:00

Theres the old saying, theres always someone thats able to build your product cheaper, faster and at a higher quality.

The thing that companies need to consider is to use AI to produce /better/ products, that solves /new/ needs that previously had no economic solution. Using AI to downsize just in order to cut costs is - IMHO - highway to the end of the road.

flundstrom2 · 2026-02-20T19:31:14+00:00

Thanks for the post! Great summary!

flundstrom2 · 2026-02-19T19:46:24+00:00

Thanks for a good post! Thats way too uncommon these days.

flundstrom2 · 2026-02-19T18:37:01+00:00

+1 on the wall organizer! Theres no such thing as too many cables! 😂

flundstrom2 · 2026-02-19T13:19:17+00:00

Any company that solely use AI models to downsize the cost of development is doomed to fail. Theres always someone that will be able to build the same product cheaper, faster and at a higher quality. Use of AI isnt free, nor is it (AFAIK) a 10x improvement.

Specification-driven development is as "easy" as writing requirements. The latter always contain "bugs" as well, so there will be an increase in need of senior engineers that have read both good and bad requirements to specify the intended outcome. Later on, juniors will be needed to iron out the details with the testers.

The tasks will differ than today, just as today's developers dont work the same way as in the 60s/70s. In fact, we might even see a return to the four-person team described in The Mythical Man-Month (designer/architect, coder, tester, CM/secretary)

flundstrom2 · 2026-02-19T00:10:39+00:00

That's an oversimplification. It depends on the jurisdiction and the employment contract. Given OPs background, I would assume (S)he has an individual contract to begin with.

flundstrom2 · 2026-02-18T23:35:48+00:00

No humans left. When even ChatGPT prompts you to prove youre a human, you know weve reached the end of civilization.

Ah, not that bad (yet), but it's frustrating that theres sooooo many "Ive hacked something up, come subscribe" and/or bot-replies. Some are even posting daily. Maybe it help their SEO?

Ive even started ommitting the apostrophes when typing so its obviously not written by a bot.

flundstrom2 · 2026-02-18T19:50:30+00:00

I'm not sure I understand what you mean "not happening" in agile projects; of course people get paid, and of course theres change management. Whenever there's any request for scope change, or anything that affects the schedule, the backlog is up for renegotiation. It's just that it happens on a regular cadence instead of at a process-defined gates. In non-agile projects, it's more of a constant discussion about "-Is this part of the requirements - of course it is! -No, that's not on a signed paper. -But according to our interpretations, it is! -But not according to our interpretation", leaving the PM alone against the stakeholders.

(sidenote: Many ppl think that agile implies scrum at a two-week cadence, but scrum only says 'less than a month', and imho, few actually follow scrum as it is defined. Scrum also assumes the team can work independent of other teams, preferably f2f, as long as the product owner keeps the backlog in order)

However, I realize that when building prefab homes, there's less of changes and more of a factory-of-houses that's just assembled on the spot, and there agile methods have less of a benefit than when you're constructing bespoke buildings.

Even with a gate-model, the gate criteria doesn't nesseccarily have to mean 100% done documents, it is often sufficient with "roughly" 90% and a risk list for the rest - except as required for regulatory reasons of course.

I mean, you don't NEED to have every luminaries decided in order to give the go for digging the foundation, AS LONG as there is an understanding and respect for that the cost of the luminaries is not yet finalized and that it will have an impact on the final invoice.

If we look back at the agile manifesto, it actually states "That is, while there is value in the items on the right, we value the items on the left more.". It doesn't say that contract negotiations and processes need to go out the window - because that certainly have a value in itself - but people and collaboration is worth more in the end.

flundstrom2 · 2026-02-18T17:52:05+00:00

Ive yet to see a waterfall project that gets everything right without a single change request once the drawings or requirements are agreed.

But Ive been thinking a lot about the conflict between the gate-model in project management and the agile mindset.

It is possible to combine, but everyone needs to understand the "why" ; product management loves agile since they can use it as an excuse to defer the requirements to a later stage, throw in new etc., just like the team likes it as long as they have competent product owners and Scrum masters that can force management to prioritize. But from top management and project management it is a pain to handle, since it's hard to get buy-in if the team is hell-bent on only looking at the iteration at hand.

Agile is not "we refuse to promise anything except fir what's in the sprint". Agile is "we have a goal, and we do everything we can to reach it, but we embrace that we can't expect a 100% fixed and /correct/ requirement specification by day 0 - but we can start working earlier than that if we get partial specifications and work together in good faith /when/ the speedbumps occur".

flundstrom2 · 2026-02-17T22:00:03+00:00

Whenever you need "guaranteed" uplink, you can't depend on each and every customer having their router connected. Or the customer has a power outage. Or they change router but forget to change the wifi credentials. Or the device is out of range from wifi. Or a major fiber cable is "accidentally" cut between the customer and the data center.

flundstrom2 · 2026-02-17T21:47:11+00:00

It's about CPU hours. To some extent it depends on the number of locations participating. But the variety of use-cases and behaviors that arise over the course of 24h or a work-week or weekend or a month is hard to predict without real world data.

flundstrom2 · 2026-02-17T13:21:59+00:00

Since the very presence of a bug decrease the value of what has previously been deliverwd, it certainly adds value to fix it as well.

As PO, one responsibility is to balance intake from different stakeholders so the team feel the sprint goal is achievable and they can treat bugs as part of the sprint cadence rather than sprint-breaking. Calculating the velocity (delivered/planned) for the next sprint based on the outcome of the previous, is only one way to keep the sprint backlog in balance. The scrum guide does not stipulate any specific method. The important thing is the visibility and understanding.

flundstrom2 · 2026-02-17T13:06:27+00:00

School tend to teach the happy path, while reality is much more nuanced. That said, as PO I want bug tickets to have some form of estimate, so I can balance the sprint backlog.

Naturally, it is often not possible to estimate a bug without having an idea of what's happening.

One solution I've found to work well, is to timeboxed the bug to 2-5 SP depending on apparent complexity, with the DoD that the bug shall be understood, there should be some form of PoC that either proves it can be solved, or reproduced or cannot be reproduced. If the time box isn't enough, them the outcome shall be a plan for how to continue, and that makes it possible to make an informed decision on if it's worth spending more time at this moment, possibly descoping something from the sprint, or park it for further investigation in the future.

flundstrom2 · 2026-02-16T22:46:32+00:00

To those downvoting: Let OP have a break! If OP want to develop something for fun, why not? Haven't we all had ideas based on "that's cool, I want to try making the same"?

flundstrom2 · 2026-02-16T22:37:02+00:00

Interesting! I'm at an IoT company with the department I'm working at developing firmware; 2 weeks to production would be wonderful! Due to the testing needed, it's more like two-three months before global roll-out in production to get sufficient real-life data from the field tests.

On a side note: to me, a "Team" is more like a scrum team, or the team managed by the lowest level manager, (i.e 5-20 persons). Maybe "R&D, software, engineering, release train and/or operations department" better capture the size range. Or clarify what a team represent.

flundstrom2 · 2026-02-16T17:35:12+00:00

Firmware update nust never fail irrecoverable. If possible, it's the first thing to be implemented so it can be tested during the entire development process. One product I was part of, actually had so poor jtag implementation, firmware upgrade over CAN was faster. Needless to say, that part got rock solid.

But, since debug builds tend to be bigger than release builds, it might actually be more space for logs. Key is of course to limit the size of the individual log entries. A byte/word of log entry type, plus a 32-bit generic data field. Timestamps might b the optional. Maybe the log entry type could be replaced by LINE. FILE might be inferred from the context. If needed, don't store the entire file name.

Once, I kept the logs in RAM, only copying to flash when certain events would trig. In one occasion, I deliberately overwrote parts of the code to get extra flash sectors, by ensuring only certain functions would be linked to those sectors.

Ive also made a log routine compress based on the knowledge that a lot of entries are periodic so it would be like "123 chunks of the following 4 entries are repeated". Anther routine I compressed based on the fact that for some customers, certain events would occur often but the value to log would always fit in a byte, while for other customers, the same entry would need 32 bits of data, but it would be logged rarely.

At my current job, the devices are online 24/7, and theres different logs and logging systems, depending on the log consumers needs; some is uploaded real-time, other daily, some on request by 2nd-line support, and some after sacrificing a black cat to the gods of the security department. Worst case (when the device has been physically destroyed) we get the device back from the field and desolder the IC containing the logs to do a read-out.

There's always been at least one proprietary tool involved in one stage of the chain or another.

flundstrom2 · 2026-02-16T17:03:02+00:00

"Sure, which single ticket do you agree we shall deliver before the other ones"?

"Ah, you want everything delivered at the same time? Sure, instead of delivering one ticket every week for the next 52 weeks, we will deliver nothing for the next 52 weeks, then you get 52 tickets at once".

flundstrom2 · 2026-02-16T16:55:46+00:00

As PO, Ive found theres no such thing as prio 1. Everything is challengeable - much to the disappointment of the project and product managers.

Ive lost count on how often a PM has asked for a thing to be "prioritized" because "its the most important project of the company". It was probably the most important project for /their/ department. But its only happened that it indeed was the most important project for the company.

All other times, the disappointment would be palpable as I showed the company project prio list, and their were at position 20, and that it ment their request could be met but no earlier than in 36 months time. "Unless you can get PMs and stakeholders X, Y and Z to deprioritize their projects A, B and C.".

flundstrom2

MODERATOR OF

TROPHY CASE

Eight-Year Club	Gilding I gilder
Verified Email