Fuck Efficiency ! Why old companies fail on innovation and speed.

50 years ago products could be sold easily because there was little competition, so innovativeness and speed were less important than efficiency, and the return of investment (ROI) was mostly influenced by efficiency.

Magic triangle of innovation
Magic triangle of innovation

Today founding a company is easier than ever before and the worldwide competition demands a very high efficiency for having a competitive pricing. But … only the very attractivest value propositions and only the most innovative solutions have a chance to stand one’s ground against the ever growing competitors. Therefore focussing on efficiency alone leads to failure. A tradefoff has to be made between efficiency, innovativeness and the speed of rolling out innovations. So success means, that the magic triangle depicted above must be addressed strategically. (I never saw this triangle before, maybe it’s been discovered already, maybe I’m the first one, please add a comment below it there’s more about this approach to find anywhere allready).

And here’s why old companies fail on innovation and the speed of launching innovation sooner than other’s. Old companies are too efficient ! After years and years of optimizing every bit of the company for efficiency, the place in above’s magic triangle became inferior for today’s fast moving markets. And that’s why startup companies can beat bigger companies, why big companies found spin-off’s etc.

So, how you gonna solve this: Fuck efficiency !

In order to get a better place in above’s triangle, you need to sacrifice all what you achieved over the last decades. And this is difficult, because it can only be achieved by a cultural change. The most important dogma for all actions has to be changed and people will not understand what’s going on and why. Cultural change is one of the hardest and long-lasting challenge a company might ever face, and chances are high, companies will fail on that, keep their position in the triangle and go under.

So, don’t go under, follow the boy scout’s rule of innovation: Reduce one bit of unnecessary efficiency every day.

Careful, efficiency is still very important and the areas have to be selected very well.

Implementation Examples:

  • Plan 90% of the employee’s time, not 110%.
  • Allow all people to shape the products, not just some few responsibles.
  • Allow new technology. Some will fail, some will turn out being less efficient, but in the end you will have more options to move and you will focus more on customer value than on technology (see Blog: “Why not simply use the latest greatest ?”).
  • Allow job rotation
  • Let the people decide which task they love, don’t assign it as if they were cattle
  • Enforce disruptive innovation. Some will fail, which is less efficient, but one of it might eventually change the world and be the future foundation of your company.

Carefully crafted summary to remember: Fuck efficiency !

OO strategies for embedded systems

A lot of embedded software projects are implemented without modern techniques of object orientation. While in PC and server software theese are inevitable and state of the art, the embedded software industry is lacking behind. There is no justification for this on systems are driven by high speed ARM cores and hundreds of megabytes of memory.

Take your software to the next level by utilizing modern OO strategies as:
– S.O.L.I.D.
– Application Wiring
– Onion Architecture
– Code Generation

The following presentation gives you an overview to this productivity boosters:

All this is taken from real-world embedded projects. Once you utilized this, people will become more productive, mainly by writing and testing code mostly on the development PC and seldom in the lab/on the target.

Onion Architecture for the Internet of Things (IoT): The Protocol Translator

The Internet of Things (IoT) is on everybody’s lips these days. I’ve been confronted with IoT architectures since more or less 10 years now, and the biggest topics are:

  • Companies must react very fast. Windows of opportunity are opening and closing faster than ever. Today some IoT standard might be hot, and tomorrow it is superseeded by a bigger player.
  • Devices must support different and overlapping standards.
  • Testing becomes difficult when countless remote peer variants need to be compatible, and when thousands of simultaneous connections must be tested/simulated.
As a fan of SOLID, DDD and the Onion Architecture, I want to share with you, how to overcome this challenges. How to adapt new standards quickly – in the software itself and also in the test automation. And also, how to protect your core logic, your crown jewels, from an ever faster changing environment.
When using Onion Architecture one automatically regards the dependency inversion principle, and with proper application wiring, one stays automagically SOLID. It is a good idea to use DDD within the inner layers, which means (among other points) to use object instances that are named, and reflect, the Ubiqutious Language of the problem domain. The advantage of the Onion Architecture is that the Core Logic is protected (loose coupling and strong cohesion) and can easily be transferred to other environments. Furthermore all outer parts become software plugins that are easily exchangeable by e.g. unit-tests.
Onion Model
Onion Model
For an Internet of Things device, I recommend to use an abstract Protocol Translator inside the Glue Logic. This translator communicates to the outer layers by passing plain data buffers. To the core logic it communicates only by moving object instances with nice DDD Ubiqutious Language name and semantics. This way your core logic will not be polluted by the negligible details of the particular protocols, and it won’t be affected by the turmoil of IoT’s protocol wars. Such a translator can easily extended by other protocols, or just by dialects between vendors that share the same protocol.
Protocol Translator Example
Protocol Translator Example
This approach is ideal for test automation. For testing the core logic (e.g. high and concurrent traffic), the Protocol Translator can easily be replaced by a mock simulator. (Because we use the Onion model, the Protocol Translator is a replaceable plugin). And for testing the Protocol Translator itself, it can be easily surrounded by mock objects. (Again because we use the Onion model, which leads to SOLID, App-Wiring, replaceable Plugins etc.).
My Recommendation: Use a “Protocol Translator” in the middle layer of the Onion Model that speaks data buffers to the outside and DDD object instances to the core logic.
If you want to hear more details about SOLID, App-Wiring, DDD, Onion and the IoT Protocol Translator, visit my evening lecture at oose in Hamburg on January the 20th 2016. It is free of charge and there’s also free beer. Please be so kind to register at http://www.oose.de/abendvortrag/oo-muster-fuer-embedded-und-echtzeitsysteme.

Intrinsic motivation and company leisure programs

Are leisure programs compatible to a culture of intrinsic motivation?

More and more big companies offer leisure programs to their employees. But doesn’t a leisure program imply that work sucks ? Is it a modern mind set to assume, that work is so inconvenient, that courses like rowing, meditating or crocheting have to lessen the pain ?

It’s ok to have leisure programs, but we should focus more on courses that enable people, on courses that enliven our intrinsic motivation, like:

  • Sitting one day in the CEOs office and watch him work
  • Being one day in the marketing department – and being allowed to make as much suggestions as possible
  • Instead of group-rowing, group-meditation, group-crocheting (which can all be fun too): Meet in a group and define the next companies slogan (which is surely more fun, even for a passionated rower/guru/crochet master, because it’s so special and great)
  • Meet the customers/users for a whole day. Without any task, just for watching them work, while being allowed to chat about anything both like.
  • For the colleagues who are no programmers: Program a little feature. THAT will make them proud !

What else ? What would you offer that raises intrinsic motivation, instead of being a compensation for pain ? Because work IS NO PAIN, mankind LOVES playing/working/growing – LET OUR PEOPLE GROW !

Why not simply use the latest greatest ?

Since 1997 I’m a professional programmer and especially during my 12 years as freelance software development consultant I saw many, many projects, that all had one thing in common: Every technical innovation had to be justified. Usually such method innovations are pushed in an upwards direction from the engineers to the management. And almost never the other way round. Each innovation is a more or less intense struggle, a fight for trust and at last for budget.

We all witnessed this a lot of times, right ? I often wonder how it will be in the future, when software development will be as evolved as … let’s say the craftmanship of a mason. When it is clear that (and which) a unittest-framework with mock-generators and which application-wiring-framework for onion-architectured solid-code is used, for the code that is automatically generated from behavioral UML-charts with lambda-based DDD behavior injection into the microservice based active objects, that are 100%ly auto-tested, immediately deployed to the customers, continuously and immediately refactored up to every slightest change in the customers needs … and all that without any arguing, because it is so natural and everyone does so since hundreds of years. Maybe by using just one tool that covers everything from code-repo over requirements derivation up to the compiler and continuous-integration server with a perfect IDE that types everything by just pressing alt+return …

But today, when all new methods are so young, and I suppose, a lot of the future’s software methods even haven’t been discovered yet, a every slightest advancement needs so much fighting. For every advancement you propose, you reduce your management’s reputation, because if you’re right with your proposal, the question is, why the predecessor of your proposal had been chosen in the past. So the first management reaction is: “That proposal is not necessary. The status quo is an ideal environment. The accusation, our environment might not be appropriate is insulting and wrong.”

Well, I made the experience during my time as a consultant that software departments that use modern technologies are way faster. A project that uses c with printf-debugging on the target can be several times slower than a project that uses c++14 with statemachine-codegeneration and host-based unittests. In the old fashioned way the same feature might cost days and days, that costs only a few hours in a modern environment. If you ever made the experience of working in such different environments, you’d never ever doubt again, that better tools and methods pay off very soon. Unfortunately most good managers are promoted very soon, therefore have actual software developer working experience only in few (sometimes even only one) company, and then they miss this experience. But they decide, because they are responsible for the budget (usually).

And today I asked myself: Why does one has to justify every advancement so much to managers ? Why does every advancement, even the ones that all competitors are utilizing already, has to be discussed ? Why are there the usual amortization calculations, that have faked numbers, but become more than true in the result ? Wouldn’t it make sense, when the top-management simply would say: “Folks, just use latest-greatest, and keep up that level”. A company that would be so brave, would have hell of a lot more productivity/efficiency. And sure as hell, this – as a principle – would amortize. I know that from my experience when I changed between companies with different levels. I saw tasks lasting for months and months that I knew, in other companies would had been finished in weeks. This definitely would work.

This sounds so simple, almost naive, but I truly believe it will work. My vision is that every developer-team can just use latest-greatest technology without fighting for it. Everyone gets the permission to refactor, migrate, buy licenses just by saying: We need this, because it’s latest greatest, and our CTO gave the strategy ‘folks, use latest greatest, because we claim to be the greatest’.

What would be so bad in having the most efficient software development in the world ? What would be wrong in being the leader ? What is wrong about creating more customer value in less time ? At some point one has to be better than the competitors – and embedded software is where the USPs come from today !

The definition of an Embedded Software Architect

Some blog posts ago I philosophized about the definition of software architecture and gave some examples I found in the internet, that were truly excellent … but somehow didn’t match perfectly well to me. I thought about this topic for a while and now I want to give you my definition. Not for software architecture itself, but for the role of the software architect:

A software architect observes quality attributes, questions functional requirements and acts as an advocate of the longevity of a software product. She achieves this by communicating to a variety of stakeholders, like project, risk and product managers, and by being a technical leader for the software development team. She is responsible for documenting decisions and the high-level design.

And let me add for the role of the embedded software architect:

An embedded software architect does this in the context of an embedded system, which is a device that is not typically thought of being a computer, yet still has microprocessors inside that run embedded software. For this kind of projects typically computing resources are limited and special realtime or safety requirements must be met. The embedded software architect’s responsibility is to supervise the achievement of these special requirements. It is also typical for embedded software to run on special hardware, like a dedicated PCB (printed cirquit board) with specially taylored chips. The embedded software architect is involved in the hardware/software codesign and acts as an interface to the electronics department.

A very comprehensive collection of definitions for the term software architecture can be found at http://www.sei.cmu.edu/architecture/start/glossary/index.cfm (scroll down until ‘software architecture’).

Calling member functions is considered harmful

During the last decades a lot of technologies were identified of being harmful. Dijkstra began with identifying the Goto statement of being harmful in the 60s. Since then several other harmful technologies were identified. People understood that if-statements should all be replaced by polymorphism (I remember a professor who gave every exam a ‘fail’ that contained an if-statement in the late 90s). Also the new-statement is harmful in real-time systems and I remember an old boss who told the whole team not to use the new-statement in a 100.000 LOC server application written in C#, having – as it’s the nature of C# – new-operations splattered all over the place … challenging … 🙂

But that wasn’t all. Robert C. Martin interestingly mentioned the book ‘structure and interpretation of computer programs’ in one of his on-line lectures and the paradigm of a functional programming language to avoid assignment statements. Which makes perfectly sense in that context. So even an assignment can be considered as being harmful.

What else ? Recently plain threads were considered being harmful in a keynote of Hartmut Kaiser. Off course, no one likes threads in a context where it should be avoided, not to mention the thread-per-object anti pattern (which I first read in one of my most favored books, Utas “Robust Communications Software”). Once I saw an application that utilized three threads per instance of connected hardware. The original version was written for 30 remote devices, leading to 90 threads. A few years later the managers decided to use this software for a huge installation of 2000 devices, leading to 6000 threads, with 512 KB stack space for every thread, which is close to 3 GB RAM in total. That didn’t work out very well on a 32 bit processor 😉 OK, so plain threads are evil too.

Up to now several other technologies have been identified of ‘being harmful’. Things like ‘recursive make’ or static linking, csh programming … The identification of harmful technologies has even its own wikipedia page today: http://en.wikipedia.org/wiki/Considered_harmful

Well, and today is the day I will identify another harmful technology and introduce it to the whole world: Calling member functions is considered harmful !

We all know this situation. A perfectly functioning and bug-free piece of code is extended by a call to a member function of another object. It appears that this change introduces a big risk to the robustness of the function. In a significant amount of cases (as shown below) adding a function call will lead to a software failure. This is caused by the unpredictable nature of object orientated code that hides functionality in abstractions that are never able to fully reflect all underlying details (otherwise it wouldn’t be an abstraction, right ?).

Calling member functions significantly widens – and this way worsens – the fan-in and fan-out of functionality. The amount of overall system state is greatly increased because not only the local state (reflected by the local variables) is taken into account for the program’s execution at this place. Instead also the full state of the called function has to be regarded as well. This tremendously increases complexity, which this way easily rises beyond what a human brain is able to understand.

This technology becomes absolutely unrulable and high-risk, when the called member function itself again calls a member function. This increases the amount of state information even more, and the more state information is involved, the more software failures will appear, as can be shown easily by popular studies. Now imagine that this function also again calls more member functions and this functions call again other ones … Such practice renders a software totally unmanageable. Imagine what could happen if a function calls a function again, that was already part of the call-stack before. Or if a function calls itself again, leading possibly to a vicious recursion. Furthermore the same part of source code can be reached from virtually innumerable other functions, leading to a virtually random sequence of calling orders and a virtually unlimited number of possible different call-stacks. This situation is practically impossible to be tested. Such software is out of control.

It is obvious that the only way to cope with this situation is to prohibit all kinds of member function calls, and – which is most important – today is April the 1st 2015, and in our culture it is tradition to write funny articles at this date. So don’t take this text seriously and if you discover more technology to be harmful (e.g. variables, braces, objects, executables, for-loops, method parameters, void …) just let me know 🙂

New feature in limereg

I’m preparing to add a new feature for my Open Source project for image registration ‘Limereg‘, which was inspired by the ImageMagick community who asked me for a solution for the ImageMagick compare -subimage-search command that allows for more than only translation.

For searching such a smaller image inside a big one, that is not only translated, but also rotated (rigid registration) or stretched (affine registration), I will try to perform a series of image registrations on different starting positions.

Algorithm (with regard to the multilevel pyramid scheme, Limereg uses):

  • Create pyramid images of the big reference (R) and the small template (T) image.
  • On the coarsest level register the smaller image to be searched (T) on the bigger image (R)
  • Do this several times from different starting positions. E.g. by putting an equidistant grid of starting positions on R.
  • The best (resulting in the smallest SSD distance measure) n% (e.g. 20%) of positions may survive for the next run on the next finer pyramid level.
  • The next finer level should have a finer grid of starting positions. E.g. for each position that ‘survived’ above, create four new grid-positions (2×2) around the survived one.
  • Repeat this steps recursively until the finest level has been reached.
  • The best (smallest SSD) result points to the found subimage, if the resulting SSD is below a threshold.

I’m very curious how this will work out and how fast it will be.

Intercultural Communication (Germany, China)

Recently I had a training for intercultural competency in China. In the training also the characteristics of my own country (Germany) were explained. Let me share with you a short summary on how communication in Germany differs from communication in China. At first I want to emphasize that both ways are very efficient and I would never say that one of both ways is better than the other one. This blog is just about knowing the differences, without any rating.

The Germans were in a constant state of war and poverty over hundreds of years (until mid of the last century). They were always busy with rebuilding their country and that’s why craftsmanship became so powerful in Germany and a very direct language arose. “Give me the hammer !”, “Don’t put the stones so unorderly !”, “When will you be ready ?”, “No, this is wrong !”. Our trainer tought us that such direct sentences are uncommon in eastern countries, especially in cases where people would loose their face, when there is a chance that a person will be devalued. The concept of loosing ones face is less known to German people on the other hand. Ok, also in Germany people have a reputation, but it works diffently than in eastern countries (as far as I learned from our trainer):

– In Germany every word is filtered by being: The truth, spoken with good reason and efficient.

– In eastern countries it is ok for supporting social relationships or to avoid that someone looses the face to void this rules. It is ok not to tell the truth, for saving others reputation. It is ok to begin with smalltalk (which has a good reason more indirectly, not directly). And – what German people would sometimes regard as inefficient communication – it is advisable to paraphrase problems with much words or even stories that have a message hidden in between.

This was said coming from the different social structures of monochromatic and polychromatic societies. In monochromatic structures each individual deserves total freedom and wants to make it to the top alone. At the end of a work day the amount of identified and solved problems defines the success of the day. In polychromatic structures each person is part of a group, everyone has to serve the group. At the end of a work day the amount of strengthened (or even created) social bounds defines the day’s success.

Let me make an example:

Two German people are sitting in a German lunchroom at lunch, a server administrator and his boss. A lot of people can hear them talking. The server of the administrator is terribly slow each morning when everyone comes to work. Two workers come to both, say short greetings, don’t do any smalltalk and come directly to the point: “Hi Paul, I’m Bernd, did you notice that your server is so slow in the morning, sometimes I have to wait 15 minutes until I can logon”.

You find here the German communication pattern again: Truth, efficient, spoken with a good reason.

Now how would a German react and how could the reaction be if this were Chinese people:

Germany: Paul is very grateful that someone gives him potential for identifying and solving a problem. Paul would ask many questions about the nature of the problem and about how bad the situation is. Paul would not feel personally critisized. Bernd would tell the full truth and would explain every single detail he worries about. The boss of Paul would listen interestedly and would think good of Paul, because Paul is so motivated in asking for every detail. Also Bernd’s behavior would be regarded as being very valuable, he is so motivated that he invests time for giving all details to Paul, this is highly appreciated.

If it would not happen this way, if someone would depict the situation less worse than it is (Paul or Bernd), everyone would think that this is not an honest person (see above: truth) and the reputation of this person would be lowered because he did not stick to the facts.

China: Now imagine the same setting but Paul and his boss are from China. If the German Bernd would then talk so directly about the problem, Paul, his boss and also Bernd would all loose their face (if I understood the training correctly), which might put the Chinese colleagues at high stress. Paul would maybe try to depict the situation less worse to calm down the situation, which the German Bernd would then decode as not telling the full truth. This makes Bernd even more upset because Bernd feels to get tricked and then everything proceeds into total chaos …

So how to avoid this situation:

For western people: According to our trainer the best way is to understand that in China building relationships is more important than solving problems/tasks. And this worked very good for 5000 years now, we should appreciate this as a very effective pattern.

Bernd could begin the communication with smalltalk, and he could express how proud he is being a member of the community and how good the community is interacting which each other, that it is a great pleasure to work together. Everything that refers to the group is perfect. If some German colleagues asked for the Chinese ones before Bernd traveled to there, Bernd can transmit their greetings and he can underline how satisfied the German colleagues are with the relationship in between the whole family of German and Chinese colleagues. Pitfall: Don’t mention anything negative. This is hard for Germans as it is not uncommon in German smalltalk to philosophize about things that went wrong, and to draw lessons-learned from it. Also don’t refer to anything negative that has been solved in the wrong assumption this would be positive smalltalk. Like “I’m so happy that the new CEO is so much better than the old, retired one. He’s so wonderful and has so much youth and power.”. In Chinese ears this might be no positive smalltalk at all, usually the former CEO has to be honored.

As a German, one has to understand that this procedure is no waste of time. That there’s no need of getting nervous when it feels like inefficient communication (see above: efficient, truth, good reason) or when it feels like not being the truth, e.g. when one says that the relationship between the teams is so wonderful when this isn’t fully the case. Being patient and polite here is the key and most recommended.

After Bernd created a good atmosphere he wants to mention that the server is slow each morning. It would be best to tell the Chinese Paul about it under 4 eyes. If this isn’t possible for some reason, the communication has to be as subtle as possible (well, under 4 eyes one would still be more suble than in Germany). I’m no expert here, but if I’d be Bernd, I’d maybe mention that the server is such a valuable contribution to the team and that its speed is so good at noon and in the evening when people work longer for their customers. A Chinese Bernd would understand this, if he’s aware of the slowdown in the mornings. Maybe I would tell a story (a lied one maybe – which is very difficult for Germans who’s reputation is tightly bound to telling the truth, as explained before) where the speed of a server saved the team from trouble and helped an important customer who was calling in the morning. It is important here to emphasize the impact to other people (the team, the customer) and not to emphasize only on factual problems.

For the German the success of this communication is measured in the first place in whether the server will become faster later on. The communication’s success for the Chinese might be measured in the first place in whether the relationships could be tightened and all people are satisfied. A Chinese Paul will help Bernd for strengthening the relashionship to him and because Bernd needs Pauls help. A German Paul on the other hand would help Bernd for strengthening the companies processes and would care less about the relationships. Ok, this is a bit overdrawn, also a Chinese Paul would care for the companies processes and also a German Paul would try to have a good relationship to Bernd. But according to my training the focus is either more on facts or more on relations, this is importand to be understood.

If I had to give the same kind of advice to Chinese people (how to communicate to the other party), it would be to talk about facts and to talk very clearly. Germans like when negative facts are directly mentioned with their full impact. They care less abour who is responsible for the fact, they concentrate more on the situation itself and on how to overcome it. You can call a German and come right to the point (however as Chinese people are so good in smalltak, and also in Germany smalltalk is part of business communication, it is not an error to start with it, if kept reasonably short. (see above: efficient)).

After the (optional) small talk the following would be ok: “Hi Franz, in the specification you gave us unfortunately the whole power train is missing. We need this, is it allready available ? And if not, when can we expect it ? Thanks a lot.”. The latter question would in most cases (not allways) not be understood as making pressure, but as asking for an information, which should be as realistic as possible. Another example: “Hi Franz, there’s a little error in the software requirements you wrote. Req 234 seems to be contratictrary to Req 259, would you agree or haven’t we understood it ? Please explain, thanks.”.

Furthermore, if something is not possible, tell it a German like you would tell a small child or a golden retreiver. “It is not possible”. Be prepared for giving the true reason, like “sorry, doing this in Hong Kong is not very wise, Chinese authorities want this to happen on the mainland”. Give the reason without caring wether the German would look stupid, he will apreciate hearing the truth and as the concept of loosing ones face is less known to him, he probably will not notice at all that your answer doesn’t let him look good.

The same topic  for Germans, because it is so important: If a colleague from China tells you “this would be a challenge” or “I’m not sure, that …” what he really means is: This isn’t possible at all, in no way this will ever work out, find another way. I heard of several situation where tasks didn’t succeed and the Chinese people said from the very beginning that this is impossible (in the encoded words above) and the German people just didn’t understood the meaning and answered: “A challenge ? Great, we love challanging tasks, go and try your best ! When can we expect this to be ready ?” When a German hears “challenge” he hears that it is tough but probably possible …

So far for today. It’s a tremendously complex and wide topic. If you need further details, I can recommend the seminar from Susanne Kilian called ‘The Cina Code’ and she would probably also travel to other countries and give you a ‘The German Code’ lesson (see http://www.english-code.de).

Also nice: https://www.google.de/search?q=east+meets+west+yang+liu&tbm=isch