Answers to the Management of Embedded Product and Software Development Projects

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!

And there is even evidence supporting this!

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.

How do I Manage External Projects Efficiently and Effectively?

If you outsource a project, then you are off the hook. Or maybe not completely?

Because there are always questions and decisions to be made about the goals and requirements of the project. Typical management tasks, in other words.

What does that Mean?

First of all, there must be enough time available for the management of the external project and also the corresponding professional skills.

Then the people who lead the external project should also be able to take back this professionalism. Because too much technical involvement, micromanagement leads to expensive additional loops. For example, if personal technical preferences are placed above project goals: "This software library is the best", "Only processors from this manufacturer are good". Especially if these passions are expressed only after some time has been spent developing with the unloved component.

And last but not least, the person managing the external project should also have the budget responsibility for the project. Otherwise, it's easy to ask for things that explode the costs, but for which someone else then has to take the rap....

Should I Buy Engineering and Consulting like Screws?

Services for development and consulting should be tailored to exactly solve your problem, to exactly achieve your goals. But which partner will do it best? The decision is difficult...

Is it possible to make the decision for a partner with a spreadsheet, e.g. a utility analysis? This should make incomparable things comparable. What about the weightings? Are they really objective? Are the goals of the project really evaluated (also long-term: TCO (Total Cost of Ownership))?

Or is it the case that costs dominate the evaluation as the only exactly comparable, short-term criterion? We are convinced that it is not possible to transform the decision in such a way into a pure choice (a decision is when an uncertainty remains; when the decision can be fully based on clear facts, it is a choice).

For tailor-made solutions, the most important point is a discussion of the goals and solution approaches also with the top decision makers. Otherwise, the overall cheapest or highest value solution, or the partner who can deliver it, may be missed, or the solution may disappear into the depths of a spreadsheet.

What does that Mean?

If you as management, as the top decision maker do not invest the time to align your goals in a discussion with your potential partners, then you may miss the best solution. Because not everything can be written down, a specification, an RFQ, an outsourcing checklist is never complete. And maybe one potential partner will ask you the important questions that you would need to discuss with the others as well?