Hello and welcome to another blog entry. Today I take up a question, the answer to which often leads to heated discussions about who is the better one.

What is the difference between an embedded software developer and an IT software developer?

In essence, a software developer creates concepts, designs programs and ends up writing the source code in a programming language. These tasks are completely independent of the platform on which the software will later run. Of course, each platform has its specific features and tools that need to be used, but aren’t the general way of working and the required skills the same everywhere?

When I ask like this, you will immediately realize that “the answer is no”. But why and where exactly the main differences are from my point of view, I would like to show you in the following sections.

The “hard ware”

The first big difference comes from the necessary knowledge about the hardware. A developer in the embedded area should know the hardware used well. After all, he writes his source code to control it or use it for a specific purpose. He must be able to interact with it and communicate at a much deeper level of abstraction.

The IT software developer, on the other hand, focuses exclusively on his application. He is hardly interested in the hardware because it does not differ significantly on all end devices.

Mass = Class?

Therefore, the latter usually underestimates the effort required to get the hardware working. This brings us to the next difference. IT software developers often judge their work by the length of their source code. They also write more lines in direct comparison. This is because they can only build their product virtually as code.

An embedded developer lets the physical device work with his software. The complexity here results less from the amount of source code, but rather from the configuration and the behavior in the case of sensor or key inputs, for example.

The closeness to hardware is also readily apparent in debugging. Developers for embedded systems often use oscilloscopes, analyzers and multimeters for this purpose. Errors are often not found in the source code, since only the implementation of the code reveals the incorrect behavior.

This is in contrast to the capabilities of the integrated development environment for debugging or profiling the program code, which are usually used in the development of application software.

Attention, control!

In general, it can be said that an IT software program either performs some calculations using algorithms or processes, stores, moves, deletes or displays data. This also results in the two core areas of computer science, algorithms and data structures.

The embedded software developer, of course, also deals with these topics, but to a much lesser extent. He focuses more on the management and control of the entire system. His goal is to exploit the full potential of the hardware and create an advantage for the user from it.

No, PCB is not a narcotic!

For software development, he uses a desktop PC like any other software developer, but the programs later run on circuit boards with microcontrollers or microprocessors. He uses special cross development toolchains and hardware-dependent compilers to create and transfer his application for an embedded system.

An IT software developer does not know these detours. No matter what kind of application he writes, the target system is a desktop PC.

Now I’m sure you’ll interject, “Wait, wait! And what about mobile devices like smartphones or tablets? Surely I don’t have to deal with hardware-specific peculiarities there either!” In principle, the objection is valid, but from an embedded developer’s perspective, mobile platforms are designed for general use. There are enough mature tools that they are comparable to a desktop PC today.

A comparison of the forces…

In conclusion, I do not want to make a comparison of strengths. That would not be fair to either type of developer. Each of them has expertise in certain fields and is superior to the other.

I find the figurative comparison of an axe with a saw good for illustration. Both tools are suitable for working with wood, but cutting down a tree with an axe is easier and goes faster. So to make firewood, I would prefer the axe any day. The saw leaves a clean cut surface for it, which leaves smooth and even boards cut from the wood.

Here it depends in the end, just as with software, on the intended use.

Now you know my ideas about how software developers differ in the two technology fields. How do you see this? Do you have similar views or should I have missed something?

Just write a comment. It would make me very happy, and I hope you’ll also check out my next blog entry. There I want to show you the different roles a developer can take in an embedded product team.

Until then, I wish you maximum success!