Our blog: creating a new product in a new domain

And so it starts… a few embedded software professionals embarking on a technical product development journey. We are going to create something, a device, a product… which requires domain knowledge entirely new for us. But then again, the idea is to leverage the knowledge we do have, to attain the knowledge we don’t have, to outsource what we cannot do, to bang our heads against the wall (as we undoubtedly will), to shout eureka (really?) when we reach a small milestone, and finally to achieve our objective.

The idea behind it all is to show our methodological approach for creating a new product in a new domain. Lots and lots of books have been written about the (embedded) software development process and mythologies – I meant methodologies (funny how spelling suggestions are truth seers) of software development. We will use some of them, most of the time, but we want to depict the practical side of it all.

There you have it: a wonderful concept has been born in someones your brain, you saw it, you stole invented it. It is great, it is fantastic, but it involves mechanics, hardware, and more and more software… Now, how to build it? How to build it so it is robust and easily maintainable and adaptable? How to build it to minimize time to market? How to minimize development costs?

Usually, we – the embedded software development professionals – are the guys brought in much too late in the process. There already was a hardware design because the inventor likes to put everything on a PCB and is convinced anything should only take 8 bit. Some marketeer insisted on that button and led there. The investor insists it should always be connected to the WWW and must have Facebook interaction. Of course, it takes too long, costs too much, and as a result corners were cut. Then, we have to fix it and work with badly chosen tools, badly chosen implementation routes and crippled hardware from a software viewpoint. Error in the hardware design? Fix it in software, please. We all have been there, done that.

Nowadays, we need to pay close attention, act immediately on new input, be a scrum master, play with cards, talk about the Kanban and adhere to the WIP rule¹, redirect and steer development in such a way as to minimize the time to market! And that last part is the bottom line, is it not? Get qualitative products onto the market in the shortest time possible. But every now and then, an innovative new idea or concept (or a new business opportunity in a new market) – which has never been implemented by you or the company you work for – comes along. You already know it: all normal procedures won’t work as expected, because companies are usually focused on optimizing output for similar products, which are normal genetic evolutions of its predecessors. Now, people need to start thinking out of the box. Panic erupts… “We cannot do that, get rid of it, outsource it!!”.

We do have a practical way of handling old and new things in embedded software and system architecture. And that is where we will focus on. The product, which should be the most important aspect of any development, is only illustrative in this regard. But since we cannot show or demonstrate how it is done without a practical example – and we do not want to dust off old use cases – we take the risk, plunge in, and will be building an at-first-sight trivial but eventually not-so-trivial product.

1 If you do not know what this means, and lived under a rock for the past decennial, do not worry, all will be revealed, or not…