ABC Company Conference
Unsubscribe
Banner_VXW_Text

„Der Unterschied zwischen Theorie und Praxis,
Ist in der Praxis größer als in der Theorie.
(Entwicklerweisheit)

Newsletter im Oktober 2018:

- Gigabytes drehen sich nutzlos im Kreis
- A Fool with a Tool is still a Fool
- Learning by Doing oder „Trial and Error"
- Gute Vorbereitung ist der halbe Sieg
- Investition in Wissen und Zukunft
- Eine wahre Fundgrube an wertvollen Informationen
- Wie sag’ ich’s meinem Kinde (Pardon: Chef)


Liebe Kundin, Lieber Kunde,

Jedem Entwickler in einem Embedded Projekt sollte klar sein, dass letztendlich nicht die Kosten der Entwicklungs-Werkzeuge entscheidend sind, sondern die Produktivität und Qualität, die sich damit erzielen lassen – auf einen Nenner gebracht: der Nutzen, den die eingesetzten Tools bieten. Dabei spielt es letzten Endes keine Rolle, ob das Tool kostenlos war oder einen Preis hatte.

Softwareprojekte sind meist unwirtliche und unübersichtliche Land-schaften, die in vergleichsweise kurzer Zeit und unter enormen Druck von allen Seiten durchquert werden müssen. Improvisationen mit auf den ersten Blick kostenlosen Lösungen können da leicht ins Auge gehen. Doch auch professionelle Tools stellen den Entwickler vor die Qual der Wahl und vor Herausforderungen bei der richtigen Anwendung. Entschieden ist schnell, die Reue kann aber lang sein.





Gigabytes drehen sich nutzlos im Kreis
Die Anschaffungskosten für ein Tool sind, verglichen mit den Folgekosten einer falschen Wahl, wie Projektzeitverlust, Qualitätseinbußen, Verkaufs-einbußen durch falsche Marktplatzierung und schließlich die Unzu-friedenheit der Mitarbeiter, meist zu vernachlässigen.

Den Preis am Anfang kennt jeder – die Folge- und Gesamtkosten über-schauen nur wenige, manche gar nicht – und so wird schnell klar, dass Konsequenzen-reiche Entscheidungen oft auf unzureichender Grundlage getroffen werden.

Gibt es in Ihrem Unternehmen auch für viel Geld angeschaffte Tools, die ungenutzt in Büroschränken liegen? Wieviel Gigabytes teurer Software fahren auf Ihren Festplatten im Kreis, ohne tatsächlich (und richtig!) genutzt zu werden? Scheinbar ist es leichter, Geld für Tools bewilligt zu bekommen, als fundiertes Wissen für deren Auswahl und Nutzung zu finanzieren.

Es ist ein weit verbreitetes Phänomen, dass der Wert des Wissens in den Köpfen der Mitarbeiter zwar überall betont wird, aber die Bereitschaft vom Management, in dieses Wissen zu investieren, dazu häufig im krassen Widerspruch steht.

Das Besondere am Investitionsgut Wissen ist, dass es in den Köpfen verschwindet und kein materieller Gegenwert sichtbar ist. Hardware kann man sehen und anfassen. Auch bei Software gibt es immerhin ein paar CDs und manchmal noch ein dickes Handbuch.

Dummerweise kann der Mitarbeiter sein Wissen in seinem Kopf mitnehmen, wenn er das Unternehmen verlässt. Seine eigene Leistung wird der Mitarbeiter in der Regel sich selbst zuschreiben, wenn er vom Unternehmen gut ausgebildet wurde.

Umgekehrt wird er der mangelnden Ausbildung die Schuld geben, wenn es Probleme gibt. Diese paradoxe Einstellung zum Thema Weiterbildung ist ein Grund dafür, dass häufig falsche Tools gekauft werden oder richtige Tools falsch genutzt werden.



 



A Fool with a Tool is still a Fool
Fenstertechnologie, Mausklickerei und simple Quick-start Demos erzeugen die Illusion, dass Tools uns die Denkarbeit abnehmen. Dies ist aber ein gewaltiger Irrtum. Je mächtiger das Tool, desto mehr ist der Bediener als kompetenter Beobachter und kritischer Hinterfrager gefordert.

Gute Tools machen aus dem Handarbeiter einen Kopfarbeiter. Er muss die Methode hinter dem Tool verstehen, um nicht vom Tool in die Irre geführt zu werden. Unumstösslich gilt: A Fool with a Tool is still a Fool.

Gute Tools können wie ein Kompass schneller zum Ziel führen – voraus-gesetzt, man setzt den Kompass richtig ein und kann seine Hinweise inter-pretieren.

Die Anschaffung eines neuen Tools sollte in erster Linie einen plausiblen Nutzen haben, der die Investition rechtfertigt. Und diesen gilt es zunächst einmal zu verstehen. Hinterfragen Sie die Potentiale an Geldeinsparung und Zeitgewinn, sowie Qualitätssteigerung und Risikovermeidung.

Wenn Sie ein Tool in Betracht ziehen, dass eine neue Methode oder Arbeitsweise unterstützt, stecken Sie sehr wahrscheinlich in einem weiteren Dilemma: Wie sollen Sie ein Tool auswählen, wenn Sie weder die Methode, die es unterstützt, noch das Tool selbst aus der Praxis kennen?
  • Können Sie einen C/C++ Compiler oder ein graphisches Entwurfs-Werkzeug auswählen, ohne den objektorientierten Ansatz der Programmierung verstanden zu haben? Wohl kaum.

  • Können Sie ein RTOS richtig auswählen, ohne die Mechanismen eines Echtzeitbetriebssystems verstanden zu haben. Auch nicht.

  • Können Sie komplexe Tools ohne fundierte Einweisung testen, und darüber einen aussagefähigen Evaluierungsbericht formulieren? Sicher nicht.








Learning by Doing oder „Trial and Error"
Weit verbreitet ist der Irrglaube, das aus einem Junior-Programmierer mit ein paar Klicks an einem Profi-Tool ein erfahrener Programmierer wird. Welcher gestandene Entwickler gibt schon gerne zu, dass er ohne Weiterbildung mit der Mächtigkeit eines neuen Tools überfordert ist? „Irgendwie werde ich mich da schon reinfinden“ ... oder im Englischen „Learning by Doing“ und „Trial and Error“. Sicher kein Problem, wenn man genug Zeit hat und Fehler keine Rolle spielen. Aber dieses paradiesische Umfeld gibt es in der realen Praxis unseres Berufsalltags leider nicht.

Deswegen empfehle ich, dass wenigstens eine Person in Ihrem Team vor einer Tool-Evaluierung eine einschlägige Methodenschulung und vor dem Kauf eine Toolschulung macht. Sie kommen so nicht nur schneller, sondern vor allem auch sicherer zu einer fundierten Entscheidung, die Sie später nicht (teuer) bereuen müssen.

Bei mir läuten immer spätestens dann die Alarmglocken, wenn ein Kunde zum zweiten, oder gar dritten Anlauf für eine Tool-Evaluierung ansteht, und eine weitere Demo-Lizenz registrieren möchte. Das zeigt mir deutlich, dass hier viel Zeit verschwendet wurde und wird und jemand auf dem Weg zur Entscheidungsfindung ziemlich im Dunkeln tappt.

Gut, dass die Tool-Hersteller kostenlose Evaluierungsversionen anbieten. Damit braucht kein Entwickler die Katze im Sack zu kaufen. Bei dem vielfältigen Angebot kostenloser Downloads kann der Entwickler aber leicht der Versuchung erliegen, mal eben etwas Neues herunterzuladen und ausprobieren zu wollen.

Dass Sie mich bitte nicht falsch verstehen: ich will Ihnen das Evaluieren von Tools bestimmt nicht ausreden – ganz im Gegenteil.

Wenn ein solcher Download aber planlos und ohne konkretes Ziel ge-schieht, wird der Nutzen auch nicht nennenswert sein.



Gute Vorbereitung ist der halbe Sieg
Es ist unverzichtbar, eine Tool-Evaluierung richtig vorzubereiten und zeitlich fest einzuplanen. Dazu zählen fundiertes Wissen über Methode und Nutzung des Tools – und wenn notwendig, die entsprechende Schulung vor der Evaluierung.

Dazu zählt auch unverzichtbar die für die Tool-Evaluierung fest reservierte Zeit mit einem konkreten Evaluierungs-Plan und -Ziel:
  • Welche Kriterien möchte ich mit welchem Ziel betrachten?

  • Wie bewerte ich diese verglichen zu Konkurrenzprodukten?

  • Welchen Nutzen bringt das neue Tool für mich bzw. für das Unternehmen?

  • Welche Risiken können vermieden werden?

  • Wieviel Geld muss zunächst ausgegeben werden?

  • Wie hoch sind die Folgekosten für technischen Support und Software-Updates?

  • Wie viel Geld kann über die Projektlaufzeit eingespart werden?

  • Welche Qualitätssteigerung kann erreicht werden? etc.
Ihnen fallen bestimmt noch mehr Fragen ein!

Die Antworten zu einem Fragenkatalog führen schließlich zu der Entscheidung über Eignung oder Nichteignung für das anstehende Projekt. Neben dem Tagesgeschäft mal eben etwas mit dem neuen Tool Herumklicken führt zu keinem Ergebnis, außer dem, dass wirklich sinnlos Zeit vertan wird. Ich bin mir voll bewusst, dass es sehr viel Konsequenz erfordert, dem Druck der kurzfristigen Aufgaben nicht nachzugehen, sondern das langfristige Ziel zu verfolgen.

Disziplin ist bei einer Tool-Evaluierung unverzichtbar – auch aus Sicht des Managements, das die nötige Vorbereitung und den nötigen Freiraum bereitstellen muss.



Investition in Wissen und Zukunft
Eine einschlägige Methoden- bzw. Werkzeugschulung kann durch persönliche Teilnahme an Schulungs-Kursen erfolgen, aber auch durch die Teilnahme an Online-Webinaren und die Bereitstellung von qualifiziertem Trainingsmaterial auf Webseiten zum Selbstunterricht.

Nachfolgende Trainingskurse für die Embedded Software-Entwicklung mit C++ und den dabei eingesetzten Entwicklungswerkzeugen sind eine gute Basis für Ihre Mitarbeiter und für die Zukunft Ihres Unternehmens.
Wir bieten in Zusammenarbeit mit unserem Partner SKT Nieratschker professionelle Training- und Consulting-Dienstleistungen für die Embedded Softwareentwicklung mit C++ in Form von mehrtägigen Kursen an:
Unsere Kunden buchen diese Kurse für mehrere Entwickler bevorzugt im Rahmen von In-House Kursen. Gerne sage ich Ihnen mehr hierzu.




Eine wahre Fundgrube an wertvollen Informationen
Neben der direkten Teilnahme an Trainingskursen bieten auch die Internet-Seiten unserer Partner ungeahnte und oft ungekannte Informations-Quellen und damit Möglichkeiten, sich über die angebotenen Werkzeuge ein fundiertes Bild zu machen, bzw. sich bei der Arbeit mit diesen Tools anleiten zu lassen.

Die meisten Interessenten, die www.percepio.com besuchen, tun dies, um den Tracealyzer herunterzuladen und zu evaluieren. So sehr uns das freut, gibt es doch viele weitere Gründe, die Seite zu besuchen. Im Laufe der Jahre hat Percepio viele Informationen über die Entwicklung von Embedded Software im Allgemeinen und die Software Tracing im Besonderen gesammelt und bereitgestellt.

Ein gutes Beispiel ist aus der ernüchternden Realität der Entwicklungsarbeit: Es gibt nicht wenige Embedded Softwareentwickler, die Echtzeitanwend-ungen erstellen, und nicht wissen, ob ihre Anwendungen die gestellten Zeitanforderungen erfüllen werden.

Zu Beginn der Entwurfsphase besteht eine gute Chance, dass die meisten Entwickler eine Rate Monotonic Analysis (RMA) durchführen, um abzuschätzen, ob die Anwendung planbar ist oder nicht.

Aber sobald die Implementierungsphase einmal begonnen hat, werden die tatsächlichen Ergebnisse selten durch Verifizierung in die ursprünglichen Designannahmen zurückgeführt.

Das erste Tool, das zur Überprüfung des Task-Timings verwendet werden kann, ist der Actor Statistics Report. In diesem Blog-Beitrag erfahren Sie, wie hilfreich der Tracealyzer von Percepio bei der Überprüfung des Timings und der Planung von Tasks mithilfe des Amazon FreeRTOS-Trace sein kann.

Die neue Version 4.2 des Tracealyzer verfügt über eine komplett neu geschriebene Trace-Hauptansicht und bietet unter anderem Unterstützung für Wittenstein SafeRTOS und Tracing über ST-LINK Debug-Probes. Das Tool bietet auch offizielle Unterstützung für Linux, sodass Embedded-Entwickler, die Linux-Hosts verwenden, jetzt auf die neue Generation des Tracealyzer aktualisieren können. Hier erfahren Sie mehr.

Percepio geizt auch nicht mit Referenzen zu anderen Usern und deren Anwendungen (wie diese über Watchdog-Timer),

Sie finden Whitepaper und eine Reihe von Artikeln, die erklären, wie man mit Embedded Softwareproblemen wie Deadlocks umgehen kann. Last but not least bietet Percepio detaillierte Installations- und Build-Anweisungen für die Verwendung von Tracealyzer mit den meisten unterstützten Echtzeit-Betriebssysteme.

Percepio hat dieses Material auf den Webseiten "Erste Schritteund "Debug-Portalgesammelt, die beide auf der Startseite verfügbar sind und regelmäßig mit neuen Artikeln aktualisiert werden. Sie sind zu Stunden des kostenlosen Lesens eingeladen!




Wie sag’ ich’s meinem Kinde (Pardon: Chef)
Man mag noch so sehr vom Nutzen eines Werkzeuges für die eigene Arbeit überzeugt sein, es wird immer eine Instanz geben, die zu überzeugen ist, die letztlich das Geld dafür locker machen muss.

Nehmen wir an, Sie müssen jemanden in Ihrem Management davon überzeugen, dass Software-Tracing von Nutzen ist und sich bezahlt macht. Percepio hat eine eigene Seite für genau dieses Thema!

Eine „auf-den-Punkt“ Präsentation ist ebenso ein guter Anfang für Ihre Überzeugungsarbeit. Oder sind Ihre Kollegen vielleicht besorgt, dass all dieses Tracing zu viel Aufwand verursachen würde? Wir haben die Zahlen:
Overhead ist in der Regel auf 1-2% begrenzt.




Gute Vorbereitung ist der halbe Sieg – auch in unserem Business. Nutzen Sie die vorgestellten Informationen unserer Partner und unser Trainingsangebot zur Vorbereitung für Ihr anstehendes Projekt und für die Auswahl der geeigneten Entwicklungswerkzeuge.

Herzlichst,  Ihr
Marian A. Wosnitza


„Fehler machen ist keine Schande,
Die Erfahrungen daraus zu ignorieren, eine Dummheit.“
(Unbekannt)