a man asking questions

Questions about Embedded Product and Software Development

Time to Read 6 min

There are a few basic questions about embedded development and software development that come up again and again.

As an engineering company, we do exactly such embedded and software development. Bringing in an engineering firm doesn't have to be the best solution for your embedded development. Nor does the way we do our development have to suit you.

Nevertheless, we try to answer the questions as honestly as possible, so that you can make the best choice for you.

Find the answers to the following questions here:

In addition, there are more detailed articles on these topics:

Contact me if you have other questions and I will answer them here.

Can One Person do Everything, Really Everything?

"...develops C++ software and VHDL programmable logic. Creates schematics and layouts and then commissions the hardware itself. Additionally performs EMC and CE certification and handles functional safety and IoT security certification..." This is the not atypical job description for a developer or the self-description of one-man development vendors.

Is that even possible? Sure, there was a time when it was possible. But: that was in the last millenium: 8-bit processors, no EMC regulations worthy of the name, 1K EPROM, 256 byte RAM, the language was called assembler, the development environment was called "monitor"... This time is definitely over!

If one or two persons alone take over all these tasks today, then often disaster is pre-programmed. The result is a control system that actually works. But then shortly before the start of production, it fails the EMC tests because the layout- and EMC-basics were not observed. During the production ramp-up, it becomes apparent that the soldering yield is subterranean because the footprints are poor. The first prototype at the customer's site crashes, and nobody knows why (the first parameter the customer changed had no error handling, like all the others...). The safety check requires a complete redesign. And so on...

Why is it like this today? Why was it possible in the past? There are three reasons:

  • Increased complexity: In electronics and software, systems are in use today that would have passed for servers a few years ago. Their inherent complexity ensures that only specialists who work well together can efficiently carry out such developments.
  • Time-to-market: How fast did new products have to be on the market? There were projects that took ten years. Would that be accepted today? The components would already be obsolete when production starts....
  • Non-functional requirements: Most product specifications think in terms of functional requirements, in the straightforward case. That was enough with the 8-bit microcontroller, everyone was happy if you were able to squeeze the function into the available memory. Thirty years later, the functional requirements of a system are fulfilled within 20% of the development time. Then come the non-functional requirements: certification for CE, EMC, operational safety, functional safety. Most devices have graphical interfaces with touch operation, resulting in demands for usability and multilingualism. And Industry 4.0 also demands IoT functions, which immediately entail cyber security...

Giving all the work to only one generalist is probably one of the most widespread and for the project success most momentous decisions. And unfortunately the one that puts all embedded developers in a bad light: "It always takes much longer and doesn't work anyway".

What does that Mean?

We think that embedded development is team work. No one can do everything, put together a team for the project in which all embedded disciplines are represented by a real specialist.

Is the Effort for a Specification not a Waste?

Isn't it a waste to create more or less detailed requirements for a product or even more for a software? Wouldn't it be better to just start with the development to bring the product to the market as fast as possible?

Even though in times of "agile" this is not necessarily popular, a clear goal helps to speed up development. This is because, especially in embedded systems, subsequent changes and the correction of false assumptions can be very costly, more costly than a good specification.

The value of good requirements becomes also apparent when it comes to estimating and planning a new development, when the profitability of the product is to be assessed. At the latest during the further development of the product, a clear specification is then the solid basis for the discussions about new features or features to be omitted.

The alternative is specification on demand, sometimes " masquerading " as agile development. These projects are often "open ended" and thus no estimate of development costs is possible for a return on investment consideration.

What does that Mean?

We think creating specifications and requirements makes sense and is worth the effort. Invest in your requirements. And if you work with external parties, keep all rights to this asset!

Does the Tool make us Much Faster?

The provider of the software told us that we will develop faster by a factor. The new language promises an increase in productivity...

Do these miracle cures, these "silver bullets" exist? Unfortunately, after 34 years, the answer is still: "There Is Still No Silver Bullet", an article which refers to Brooks from 1987... Software projects can still turn into werewolves without warning, devouring resources, deadlines, money and careers.

Tools, pragmatically applied and understood, bring progress in the quality of development and have the potential to reduce effort. Except that these tools do not solve all problems in one fell swoop, they can also create new problems. Among other things, because they must first be trained, understood and properly applied.

What does that mean?

Understand us correctly, we also use many software tools and the latest languages. But we believe in using only what makes sense for the project and the product, in pragmatically choosing what brings real benefits from the large range on offer.

Can Agile Methods Save us?

The Agile consultant said that everything is much easier and all problems disappear. If we follow his method exactly! Is that really the case?

The agile processes and working methods of generating specifications during the project were developed for a type of (IT) problems where they have their justification. It is often about adapting solutions to customer requirements, where both the basic platform and the basic function (web presence, web store...) are already known.

In embedded product development the resources (computing power, power consumption...) are always limited. Exactly how many are available is determined at the beginning of the project when designing the electronics. When the specifications change and more are needed, the increase of resources is usually a very expensive exercise.

So generating specifications during the project is not the cheapest or fastest option. For critical systems, it is even blocked by the standards. And here, as with the tools: "There Is Still No Silver Bullet"!

What does that Mean?

It does not mean that "agile" processes have no justification. We too do iterative delivery and integration, automated testing etc., even on critical projects, for others full agile execution, if desired.

Try the methods that are the best solution for your problem. Have the courage to use only parts of them and adapt your approach if necessary. And expect no quantum leaps, especially if they were promised by quasi-religious zealots.

Do Freelancers Save the Specification Effort?

One argument for having all developers on site and/or working with freelancers is that then the work does not have to be specified. This is seen as the opposite of development as a project at an engineering firm: "There you have to specify everything."

Is that really the case? We believe that the constant and unstructured definition of work during the development causes a greater effort for the team. The only advantage of this is that the effort simply disappears in the overall project effort, it is smeared over the whole project.

What does that Mean?

On the one hand, it means that a project becomes more efficient if the whole team has clear goals from the beginning, e.g. a specification. On the other hand, if this is not possible, an iterative, "agile" project execution allows to keep the specification effort low at the start.

Do you have additional questions? Do you have a different opinion? If so, contact us directly or comment your thoughts below!

Are you ready for a project that answers all your questions? Contact me!

Keywords/ Tags

Questions & Comments

No Comments

Do You have Additional Questions?

* These fields are required

Let us discuss your idea/ your project