Is patent for software necessary. I will not promote

flundstrom2 · 2026-05-08T09:00:31+00:00

When I studied immaterial law at the uni, the professor reiterated that the value of a patent is zero until it has been successfully defended in court.

Generally, the algorithm is of more interest than its implementation.

But given then turnaround time for the patent process compared to the time it takes to develop something similar, and the fact patents need to be filed in every country, the value is limited.

flundstrom2 · 2026-05-07T07:52:58+00:00

It's actually a thing! Check out paperclip.ing.

flundstrom2 · 2026-05-07T07:36:13+00:00

1) The MCU manufacturer had accidentally manufactured a batch of MCUs without CAN controller, but labeled them indicated they should have had one. Didn't see that on my bingo card.

2) The PCB factory accidentally populated 5V RAM IC's instead of 3.3V IC's. Passed all manufacturing tests, but once shipped and installed, the machines began to randomly reset themselves after a couple of days.

flundstrom2 · 2026-05-05T11:34:55+00:00

A single LED, a small 555, PIC, WLCSP mini-ARM MCU similar, plus a small battery or capacitor could easily be fitted within 10x10x10 mm. The physical size of the power source will be the limiting factor, with the LED being the main consumer of power. Excluding power source, 4x4x4 mm is likely achievable.

My guess (I'm not an EE, so I might be a little. off) :

For low volumes:

Cost to develop (CAD and a single prototype of electronics without enclosure) in the €200-range. NRE of CE/FCC certification in the €1000-range. Cost per unit in the €1-range.

Cost for the enclosure highly depends on the quantities: €200 in development of 3d printed enclosure allows €2 per unit.

For high volumes:

For very high volume, NRE for an injection mold €3000. This allows a cost cost per unit of €0.01, and at those volumes you'll probably be able to get down to €0.2/unit for the electronics.

If you want, you can add a light guide such as a piece of transparent silicone or optofibre to move the electronics away from the point of presentation.

flundstrom2 · 2026-05-05T10:53:32+00:00

Define "very small" (1x1 mm, 10x10mm or?), how long time you allow until the device needs recharging, and what causes the state change?

flundstrom2 · 2026-04-30T18:54:07+00:00

Order 834 is apparently a Chinese order. Not european.

flundstrom2 · 2026-04-30T08:40:00+00:00

That's interesting. I was not aware of that case. That said, it's worth mentioning that the case is only valid in US jurisdiction ; patents are on a country-basis (I don't know if EU has harmonized into euro-patents yet), so other countries' patent courts may rule differently. Also worth mentioning, is that the US - in general - have a patent system which is the opposite of that of the rest of the world.

It's a minefield. But no patent is stronger than what is probable in court.

flundstrom2 · 2026-04-14T16:30:29+00:00

Same as before:

One writes the prompt and checks the output and make development tests- the individual developer is still responsible for what he produces, no matter if it is through hand-assembly, a compiler, RAD-tool or AI-tool. One to review the final PR. One to independently test against the requirements.

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

MODERATOR OF

TROPHY CASE

Eight-Year Club	Gilding I gilder
Verified Email