[0:01] Hi, hier ist Stefan. In dieser Podcast-Episode geht es ums Fachgespräch.

[0:05] Wenn du noch mehr Informationen zum Fachgespräch von mir haben willst,

[0:08] dann schau doch mal auf meiner Website vorbei, dasperfektefachgespräch.de.

[0:14] Und jetzt wünsche ich dir viel Spaß mit der Podcast-Episode.

[0:20] Herzlich willkommen zum Anwendungsentwickler-Podcast,

[0:23] dem Podcast rund um die Ausbildung zum Fachinformatiker für Anwendungsentwicklung.

[0:27] In dieser Episode gibt es einen Rückblick auf die IHK-Sommerprüfung 2019.

[0:32] Viel Spaß!

[0:37] Hallo und herzlich willkommen zur 139. Episode des Anwendungsentwickler-Podcasts.

[0:44] Mein Name ist Stefan Macke und heute gibt es meine jährliche Rant-Episode zur Sommerprüfung, zur IHK-Prüfung.

[0:52] Ich habe mal wieder einige Sachen mitbekommen, während ich Dokus gelesen habe,

[0:56] Präsentationen mir angehört habe und Fachgespräche geführt habe oder mitgeführt habe.

[1:00] Ich mache das ja nicht alleine.

[1:01] Und ja, meine Liste, die ich mir dabei so zusammengestellt habe, die gehen wir heute mal durch,

[1:05] in der Hoffnung, dass ich dann im nächsten Jahr nicht mehr ganz so viele solche komischen Sachen sehen, lesen oder hören muss.

[1:11] Und ja, ich habe es einfach mal gruppiert nach den drei Artefakten,

[1:15] nach der Projektdokumentation, der Präsentation und dem Fachgespräch.

[1:19] Und ganz am Ende aber habe ich auch noch eine Kleinigkeit.

[1:21] Und zwar, ich habe das mal Lichtblicke genannt.

[1:23] Ich habe noch mal so ein paar Sachen zusammengestellt, die ich tatsächlich dieses Jahr auch ganz gut fand

[1:27] und die ich auch mal positiv hervorheben will.

[1:30] Es gab also auch so ein paar Sachen, die Prüflinge wirklich irgendwie anders oder besonders gemacht haben.

[1:35] Und da habe ich auch mal ein paar zusammengestellt, damit das nicht alles immer nur hier so ein Prüflingsbashing wird.

[1:40] Das ist ja auch doof. Viele Prüflinge haben das ja auch gut gemacht, keine Frage.

[1:44] Und ich spreche natürlich heute nur über die negativ auffälligen Sachen.

[1:48] Es gibt natürlich auch einen ganzen Haufen Prüflinge, die eine gute Prüfung gemacht haben oder sogar eine sehr gute.

[1:53] Und über die reden wir heute nicht.

[1:55] Heute geht es mir halt darum zu zeigen, was man besser nicht machen sollte in Prüfungen.

[1:59] Und ich würde sagen, da ich glaube, ich eine ziemlich lange Liste habe, fangen wir einfach mal direkt an mit der Projektdokumentation.

[2:06] Das ist auch gleich meine längste Liste.

[2:08] Da habe ich auch immer am meisten zu meckern.

[2:09] Da kann ich mich auch immer am längsten mit beschäftigen.

[2:11] So Präsentation und Fachgespräch sind ja nur jeweils 15 Minuten.

[2:14] Aber so eine Doku, da liest man schon mal ein bisschen länger dran.

[2:17] Und vor allem hat man auch Zeit, die Eingehende zu prüfen.

[2:20] Und da fallen einem natürlich noch mehr Sachen auf, als wenn man einfach nur eine Viertelstunde da irgendwie was sieht oder sich anhören muss.

[2:26] Also dann steigen wir direkt ein ins Thema Projektdokumentation.

[2:29] Was ist denn da mir dieses Jahr aufgefallen, was nicht so toll ist und was man besser anders machen sollte, könnte, wie auch immer.

[2:36] Vielleicht vorweg noch einmal ganz kurz ein kleiner Disclaimer, was ich hier sage.

[2:39] Das ist meine persönliche Meinung.

[2:41] Das ist übrigens auch nicht die Meinung der IHK Oldenburg oder sonst irgendwas.

[2:44] Das ist meine persönliche Meinung.

[2:45] Weder der meinen Prüfungsausschuss noch die IHK, für die ich da tätig bin, hat irgendwas damit zu tun.

[2:50] Und alles, was ich sage, das kann ich nur dir mitgeben.

[2:53] Falls du deine Prüfung noch vor dir hast, das vielleicht nicht so zu machen.

[2:56] Es kann Prüfungsausschüsse und andere Prüfer geben, die das komplett anders sehen.

[3:00] Ich kann hier nur natürlich meine Meinung vertreten.

[3:03] Das ist mir noch mal ganz wichtig, das zu sagen.

[3:05] Nicht, dass hier so eine Idee aufkommt, so das, was der Typ da im Internet erzählt, das machen alle IHK so und alle Prüfungsausschüsse wollen das so.

[3:11] Nein, das ist nicht der Fall.

[3:13] Das ist meine persönliche Meinung.

[3:15] Aber ich hoffe, du kannst dir selber dein Bild daraus machen.

[3:18] Du kannst meine Meinung dir anhören.

[3:20] Und wenn du sagst, ja, da ist was Wahres dran, das finde ich irgendwie bekloppt, dann machst du es besser nicht.

[3:24] Und wenn du es gut findest, was du hier hörst, dann machst du es halt, dann kann ich es auch nicht ändern.

[3:28] Gut, fangen wir mal mit meinem ersten Punkt an.

[3:30] Die sind jetzt irgendwie nicht nach Gewichtung oder so sortiert.

[3:32] Ich habe die so ein bisschen gruppiert, weil viele Sachen kann man so ein bisschen zu einem Oberpunkt zusammenfassen.

[3:37] Aber die sind jetzt nicht irgendwie nach Wichtigkeit aufsteigend oder sonst irgendwas.

[3:40] Ich habe die mal einfach so, wie es passt, gerade runter geschrieben.

[3:42] Und das erste, was ich habe, ist, verwende doch bitte einfach natürliche Sprache in der Doku.

[3:47] Und nicht so ein hochgestellstes, komisches Deutsch, was du auch nicht in der Praxis benutzen würdest.

[3:52] Ich lese so oft so ausformulierte Sachen wie bei dem, statt einfach beim zu schreiben.

[3:58] Bei dem Server ist das so.

[4:00] Wieso nicht einfach beim Server? Wo ist das Problem?

[4:02] Da merkt man manchmal irgendwie, dass die Leute so irgendwie einen auf den Finger kriegen und irgendwo mal gehört haben,

[4:07] oh, man muss aber ganz hochgestochen schreiben.

[4:09] Das ist ja hier wissenschaftliche Arbeit.

[4:11] Das darf kein Mensch mehr verstehen.

[4:13] Das ist jetzt ein bisschen übertrieben, aber du darfst auf keinen Fall so schreiben, wie du sprichst.

[4:16] Das ist Schrott.

[4:17] Also beim und so weiter, das kannst du auf jeden Fall schreiben.

[4:21] Oder was ich auch immer häufig lese, so was wie welches.

[4:24] Der Server, welcher unter anderem auch für irgendwas benutzt wird.

[4:28] Also tut mir leid, so spricht niemand in der Praxis.

[4:31] Warum willst du das in deiner Dokumentation machen?

[4:33] Das ist völlig künstlich und das liest sich auch so.

[4:36] Genauso wie diese Substantivierung von bestimmten Sachen.

[4:39] Wie zum Beispiel statt, ich habe die Datenbank gelehrt, wird dann sowas geschrieben, wie bei der Lehrung der Datenbank.

[4:45] So, das sind solche hochgestellten Sachen.

[4:47] Das ist einfach völlig unnatürlich.

[4:49] Bitte lass das so einfach.

[4:50] Schreib doch einfach vernünftig deine Sätze und mach da nicht so einen komischen Heckmack draus.

[4:55] Also, weiß nicht.

[4:56] Finde ich ganz schrecklich, sowas zu lesen.

[4:58] Gut, dann kommen wir zum nächsten Punkt schon.

[5:00] Der war ganz kurz.

[5:01] Der nächste Punkt ist ein ganz häufiger Kreditpunkt, was wir leider, leider, leider immer wieder jetzt sehen.

[5:05] Und zwar habe ich da ja so eine Vorlage online.

[5:07] So eine LaTeX-Vorlage, die man sich ja kostenfrei runterladen kann.

[5:10] Bei GitHub, wo man auch mitmachen kann.

[5:12] Und wo auch schon ganz schön viele Beispielkapitel drin sind, die ich alle bereitgestellt habe.

[5:15] Und es ist auffällig, dass viele Dokumentationen, zumindest die, die ich gelesen habe, sich sehr, sehr stark an dieser Vorlage orientieren.

[5:24] Was potenziell ja auch erstmal nicht schlecht ist.

[5:26] Dafür habe ich sie ja online gestellt.

[5:27] Wenn aber wirklich jedes Kapitel der Reihe nach exakt identisch vorkommt wie in der Vorlage und dann aber überhaupt nicht mit sinnvollem Inhalt gefüllt wird, ist das einfach Schrott.

[5:37] Tut mir leid.

[5:38] Die Vorlage soll dir die Arbeit erleichtern und soll dir zum Beispiel die ganze Formatierung und Seitenzahlen und Inhaltsverzeichnis und so weiter erleichtern, dass du dich damit nicht beschäftigen musst.

[5:47] Aber es ist nicht einfach eine 1 zu 1 Vorlage, wo du nur jeweils einen Satz in die Kapitel schreiben musst und bist fertig mit der Doku.

[5:53] Nein, das ist nicht der Fall.

[5:55] Du musst dir Gedanken machen zu diesen Kapiteln.

[5:58] Und zum Beispiel haben wir häufiger mal gelesen, ich habe glaube ich irgendwo Kapitel 3 Punkt, was weiß ich, irgendwo eine Nutzwertanalyse.

[6:05] Einfach nur als Beispiel, dass man irgendwo mal eine Nutzwertanalyse vielleicht einbauen könnte in so eine Dokumentation.

[6:10] Das machen jetzt anscheinend ganz viele Prüflinge einfach so, dass sie das Kapitel einfach ausfüllen und dann sowas hinschreiben wie, eine Nutzwertanalyse war für mein Projekt nicht sinnvoll.

[6:18] Deswegen habe ich darauf verzichtet. Punkt.

[6:20] So, und dann ist das Kapitel beendet.

[6:22] Dann frage ich mich, warum gibt es dieses Kapitel denn dann überhaupt in Dokumentation?

[6:25] Wenn das nicht sinnvoll ist, dann mach es nicht.

[6:27] Du musst mir nicht begründen, was du nicht gemacht hast.

[6:29] Du musst begründen, was du gemacht hast und warum du dich für irgendwas entschieden hast.

[6:32] Aber du musst nicht eine Vorlage aus dem Internet runterladen und sie einfach dumm von oben nach unten ausfüllen.

[6:37] Das ist nicht deine Aufgabe.

[6:40] Muss ich nochmal ganz drastisch sagen, denn das habe ich auch schon von anderen IHKen gehört, dass es da wohl Probleme gibt.

[6:45] Dass die Vorlage einfach 1 zu 1 ausgefüllt wird und letztlich alle Dokumentationen irgendwie gleich aussehen.

[6:51] Und das muss nicht per se schlecht sein.

[6:53] Aber wenn halt die Inhalte überhaupt nicht passen oder einfach viel zu kurz sind, völlig nichts sagen sind, dann lass sie einfach weg.

[6:59] Das ist einfach Schwachsinn.

[7:00] Auch vor allem, wenn die Reihenfolge nicht zu deinem Projekt passt.

[7:02] Du darfst diese Kapitel umstellen.

[7:04] Du musst das nicht so abarbeiten, wie es in der Vorlage steht.

[7:07] Das ist einfach Quatsch.

[7:08] Und genau das gleiche Problem mit diesen Kapiteln, die ausgefüllt werden, habe ich jetzt auch ganz offensichtlich in einer Dokumentation gelesen,

[7:15] wo einfach in drei Kapiteln fast Wort für Wort dasselbe stand.

[7:19] Das war, glaube ich, sowas wie Projektdefinition, Projektbegründung und Projektziel oder so.

[7:23] Das habe ich in meiner Vorlage bewusst so getrennt, weil man da unterschiedliche Inhalte reinpacken kann.

[7:28] Die Person, die das dann gefüllt hat, war sich aber nicht so richtig sicher, was denn jetzt wohl in welches Kapitel muss,

[7:33] und hat einfach überall das Gleiche reingeschrieben.

[7:35] Und zwar wirklich fast Wort für Wort kopiert.

[7:37] Und da kommt da locker mal eine Seite überflüssiger Text zustande, den ich genau so schon mal gelesen habe.

[7:42] Habe ich auch übertragen geschrieben. Wiederholung, Wiederholung, Wiederholung.

[7:44] Und das ziehe ich persönlich dann auch einfach von der Seitenzahl am Ende ab, weil da einfach keine neuen Informationen dazukommen.

[7:49] Also bitte nutz die Vorlage, wenn du willst, um dir das Leben einfacher zu machen.

[7:53] Aber bitte schalt das Gehirn an, wenn du die einzelnen Kapitel ausfüllst.

[7:57] Das ist einfach total dämlich, wenn du das Ding stumpf der Reihe nach runter leiherst einfach.

[8:02] Auch wenn das gar nicht zum Projekt passt. Also völlig Banane.

[8:05] So, andersherum haben wir dann das krasse Gegenteil.

[8:07] Es fehlen einfach super viele Inhalte.

[8:09] Also für Leute, die überhaupt nicht wissen, was in die Doku gehört, ist die Vorlage ja genau gedacht.

[8:13] Da sind ja auch im Anhang ganz viele Beispiele.

[8:15] Ich weiß nicht, was ich drin habe. Programmablaufplan oder ein UML-Diagramm oder irgendwie was.

[8:20] Super wichtig. Das bewerten wir ja auch.

[8:22] Und wenn sowas dann fehlt in der Doku, dann gibt es einfach Punktabzug.

[8:26] Also das krasseste, was ich dieses Jahr hatte, war statt 15 Seiten, die bei uns in Oldenburg Vorgabe sind, 8 Seitentext.

[8:32] Das ist ja fast die Hälfte.

[8:34] Jetzt müssen wir einfach mal überlegen.

[8:36] Wenn ich fast die Hälfte abgebe, dann kriege ich auch vielleicht einfach nur fast die Hälfte der Note.

[8:40] Das ist dann einfach noch eine 4.

[8:42] Also da kann nicht mehr viel bei rumkommen.

[8:44] Wenn 15 Seiten Vorgabe sind und 8 Seiten werden abgegeben.

[8:47] Sorry, ist einfach viel zu wenig.

[8:49] Was in ganz vielen Dokus komplett gefehlt hat dieses Jahr, war sehr auffällig.

[8:53] Benutzer- und Entwicklerdokumentation.

[8:55] War scheinbar nicht gewünscht, benötigt, wie auch immer.

[8:59] Eine hat so eine Drittelseite Screenshot von einem PHP-Doc-Blog.

[9:03] Also das ist ungefähr das, was Java-Doc in Java ist, gemacht.

[9:06] Aber da war nicht mal was drin.

[9:07] Da stand einfach ein leerer PHP-Doc-Blog mit so ein paar Ad-Tags drin.

[9:11] Aber da stand nichts hinter.

[9:12] Und das war dann seine Entwickler-Doku.

[9:14] Also das war völliger Schrott.

[9:16] Und je nachdem, wie man bewertet.

[9:18] Ich habe einen Bewertungsbogen gesehen von der IHK.

[9:20] Wo es 15% Abzug für die gesamten Note gibt, wenn eine Benutzer- und Entwickler-Doku fehlt.

[9:26] Das heißt, ich kann schon keine 1 mehr kriegen.

[9:28] Ich bin schon satt in einer 2.

[9:30] Nur weil ich diese beiden Artefakte nicht erwähnt habe.

[9:33] Und übrigens, was auch nicht gilt, jedenfalls nicht bei mir ist.

[9:36] Irgendwo zu schreiben, ja, ich habe eine Benutzer-Doku erstellt.

[9:40] Und das aber nicht nachweisen.

[9:41] Das heißt, im Anhang finde ich keinen Screenshot oder sonst irgendwas.

[9:44] Also ein Screenshot der Benutzer-Doku, vielleicht ein Druck oder wie auch immer.

[9:47] Ein Screenshot zum Beispiel von echten Entwickler-Dokumentationen, die mit Java-Doc generiert wurden.

[9:51] Alles super.

[9:52] Muss man mir aber auch beweisen.

[9:54] Ich kann nicht einfach in einem Satz schreiben, ja, ja, ja, habe ich alles gemacht.

[9:56] Aber dann sehe ich es nicht.

[9:57] Also sowas gehört in den Anhang, um nachzuweisen, dass das gemacht wurde.

[10:01] Und wenn das fehlt, ich kann jetzt nur nochmal sagen, für den Benutzer- und Entwickler-Doku-Part werden bei uns 15% der Note abgezogen.

[10:08] Wenn das fehlt.

[10:09] Das ist ganz schön viel.

[10:11] Dann hatten wir noch einen Experten.

[10:13] Dem haben wir schon im Projektantrag als Kommentar reingeschrieben.

[10:17] Ich übertreibe jetzt mal.

[10:18] Kollege, du musst mehr dokumentieren.

[10:21] Du musst mehr Methodik zeigen.

[10:23] Du musst UML-Diagramme machen oder ein EPK oder sonst irgendwas.

[10:26] Haben wir ihm im Antrag schon reingeschrieben.

[10:29] Wir haben, also da waren wirklich mehrere Kommentare drin, genau hingewiesen, was uns wichtig ist.

[10:35] Und da war er aber wohl schlauer und hat gesagt, nö, das brauche ich nicht.

[10:38] Und hat dann stattdessen in der Doku geschrieben, ja, hier hätte ich jetzt ein Diagramm xy erstellen können, aber das fand ich nicht so sinnvoll.

[10:45] Und dann war das seine Entscheidung.

[10:47] Muss er ja nicht machen.

[10:48] Aber dann wundert er sich auch am Ende nicht drüber, wie dann die Note ausfällt.

[10:52] Denn wir haben ihm explizit gesagt, mach das.

[10:54] Er macht es nicht.

[10:55] Das ist seine Entscheidung.

[10:56] Okay.

[10:57] Aber dann fällt die Note entsprechend aus.

[10:59] Also das ist einfach dämlich.

[11:01] Wenn man schon das Feedback von Prüfern bekommt, bevor man die Dokumentation schreibt, dann sollte man sich einfach auch daran halten.

[11:07] Alles andere kann ich persönlich einfach nur als dumm bewerten.

[11:11] Wir wollen die Leute ja nicht absichtlich durchfallen lassen oder irgendwas.

[11:15] Wir geben denen jede Hilfestellung, die irgendwie möglich ist.

[11:18] Und wenn wir vorab sagen, Mensch, Kollege, guck mal hier, das und das und das wollen wir sehen und dann kommt es nicht.

[11:23] Ja, dann kann ich es auch nicht ändern.

[11:25] Dann ist das einfach Pech.

[11:28] Ja, und was dieses Jahr auch ganz häufig fehlte in Dokus, war die Qualitätssicherung.

[11:31] Komplett.

[11:32] Einfach gab das Kapitel nicht oder das Kapitel war irgendwie ein Satz.

[11:35] Ja, wir haben ein Code Review gemacht.

[11:36] Das macht auch jeder jetzt.

[11:38] Ich glaube, das steht auch irgendwo in meiner Vorlage.

[11:40] Total dämlich.

[11:41] Also anstatt zu sagen, ja, ich habe ein Code Review mit meinem Ausbilder gemacht und wir legen hier super viel Wert auf Code Qualität.

[11:46] Auch ein bisschen beweisen.

[11:48] Da fehlt dann zum Beispiel Quelltext im Anhang, wo da mal ein Test drinsteht oder irgendwas.

[11:51] Oder überhaupt zu erwähnen, was denn gemacht wurde außer so einem Code Review.

[11:55] Es gibt noch so viele andere Sachen, um Qualität zu sichern.

[11:58] Anforderungen vernünftig aufnehmen.

[12:00] Einen vernünftigen Entwicklungsprozess definieren, der auch abgearbeitet wird.

[12:03] Schreibtisch-Tests durch den Kollegen meinetwegen.

[12:06] Unit-Tests natürlich.

[12:07] Integrationstests.

[12:08] Das volle Testprogramm und so.

[12:10] Und da war ganz häufig einfach nichts vorhanden.

[12:12] Und da muss ich heutzutage einfach Punkte abziehen.

[12:15] Das geht nicht.

[12:16] Ich kann eine Software nicht ungetestet oder ungequalitätssichert oder wie auch immer auf den Markt bringen.

[12:21] Das geht einfach nicht.

[12:24] Ich vergleiche das auch immer.

[12:25] Oder nicht nur ich.

[12:26] Ich weiß gar nicht, aus welchem Buch das kommt.

[12:27] Ich glaube, von Ken Beck kommt es.

[12:28] Dem Erfinder von Test Driven Development.

[12:30] Er sagt, Ärzte haben sich früher auch nicht die Hände gewaschen, nachdem sie einen Patienten behandelt haben.

[12:36] Bis man dann irgendwann mal rausgefunden hat, Mensch, da gibt es so kleine Viecher.

[12:39] Das sind die Bakterien.

[12:40] Und die werden von A nach B transportiert und verursachen Krankheiten.

[12:42] Und seitdem man das weiß, ist es einfach Pflicht, dass Ärzte sich die Hände waschen, nachdem sie jemanden behandelt haben.

[12:47] Punkt.

[12:48] Und wer das nicht macht, der handelt grob fahrlässig.

[12:50] Und wer heute Software entwickelt ohne Test, der handelt meiner Meinung nach auch grob fahrlässig.

[12:54] Das ist einfach Standard.

[12:55] Das gehört dazu.

[12:56] Und wenn ich das dann in so einer Projektdokumentation einfach weglasse, ja, dann werden einfach Punkte abgezogen.

[13:01] So einfach ist das.

[13:02] Also dieses Mal ist mir wirklich extrem aufgefallen, Qualitätssicherung oder und Benutzerentwickler-Doku.

[13:09] Beides nicht in der Dokumentation.

[13:11] Und da kann man sich schon ausrechnen, das wird dann fast schon in Richtung 3 gehen müssen.

[13:17] Einfach, weil so wichtige Teile fehlen.

[13:20] Ganz kurz, was ich hier nochmal sage zur Notenberechnung und so.

[13:22] Völlig individuell.

[13:23] Es kann sein, dass der Rest der Doku super perfekt war und nur zwei Teile fehlen.

[13:27] Dann kann das trotzdem noch eine 1 sein, eventuell.

[13:30] Das muss man immer im Verhältnis sehen.

[13:32] Also man kann nicht pauschal sagen, Benutzer-Doku, Entwickler-Doku fehlen.

[13:35] Also ist das automatisch 85%.

[13:38] So geht das auch nicht.

[13:39] Wir müssen schon das Gesamtbild bewerten.

[13:41] Das ist klar.

[13:42] Also wenn ich sowas sage, dann ist das immer mit einem…

[13:44] Man muss das immer ein bisschen abwägen, auf jeden Fall.

[13:47] Ich will nur mal deutlich machen, dass es solche Listen gibt, wo drin steht, wenn das fehlt, x% Abzug.

[13:52] Und dann halten sich auch einige Prüfer daran.

[13:57] Nächster Punkt, Qualitätssicherung.

[13:59] Habe ich gerade schon gesagt, fehlt ganz häufig.

[14:01] Aber gab es auch dann ab und zu.

[14:04] Und dann habe ich ein paar lustige Sachen gefunden, wo ich mir dachte, das ist aber interessant.

[14:08] Und zwar Nummer 1, was mir aufgefallen ist, Qualitätssicherung.

[14:11] Also das war in der Doku.

[14:12] Man muss das immer im Kontext sehen.

[14:13] Die Doku hat sehr, sehr, sehr stark Wert auf Qualitätssicherung gelegt.

[14:16] Das wurde 7.000 Mal gesagt.

[14:17] Oh, wir machen Clean-Code drauf und runter.

[14:19] Und wir machen dies und das und jenes.

[14:21] Und unsere Methoden werden auf Komplexität geprüft, bevor wir es einchecken dürfen und so weiter.

[14:26] Also wirklich ein mega Fass aufgemacht, wie toll dadurch die Qualität gesichert wird.

[14:30] Und dann gucke ich den Code-Beispiel im Anhang an und sehe eine Methode, die über 70 Zeilen geht.

[14:36] Also über zwei Seiten hinweg.

[14:38] Mit If und verschachtelten Vorschleifen und Switchcase und ich weiß nicht, was da alle drin war.

[14:42] Also wirklich fast zwei Seiten Code, eine einzige Methode.

[14:45] Und da muss ich einfach im Kopf schütteln und sagen, Leute, sorry, du kannst mir vorne viel erzählen,

[14:50] aber wenn ich hinten deinen Code sehe, weiß ich, dass du nicht ein einziges Mal irgendeine Komplexität geprüft hast.

[14:54] Das ist einfach völlig lächerlich.

[14:56] Und das geht so ein bisschen in die Richtung inhaltlich-stimmig.

[14:59] Wenn ich vorne irgendwas sage und im Anhang finde ich raus, dass es überhaupt nicht stimmt,

[15:03] so das passt einfach nicht zusammen.

[15:05] Und das geht auch wieder so ein bisschen in Richtung, ich muss die Vorlage füllen.

[15:08] Hier gibt es ein Kapitel Qualitätssicherung.

[15:10] Also sage ich da, was die hören wollen.

[15:11] Oh, Clean-Code und bla und blub.

[15:13] Und wenn ich mir dann aber meinen Code hinten angucke, dann merke ich, da ist überhaupt gar nichts.

[15:16] Also wirklich nichts mit Clean-Code.

[15:18] Da waren so viele Sachen drin in dem Code, der einfach Schrott war.

[15:21] Da waren Magic Numbers drin.

[15:22] Da war doppelter Code drin.

[15:24] Harte Pfade und irgendwelche URLs für Download-Adressen und so weiter.

[15:27] Superkomplexe Switch-Anweisungen.

[15:29] Und ich weiß also wirklich, megabeschissener Code.

[15:32] Ich sage es mal ganz deutlich.

[15:34] Und da hat der Prüfling vorne ein mega Fass aufgemacht und gesagt, wir machen nur Clean-Code.

[15:38] Also ich wäre fast aus dem Fenster gesprungen.

[15:41] Ich habe es im Garten auf dem Stuhl gelesen.

[15:43] Also ist nichts passiert.

[15:44] Aber bei sowas, da denke ich mir, das passt einfach hinten und vorne nicht zusammen.

[15:47] Also ein bisschen darauf achten, dass das auch ein stimmiges Gesamtbild ergibt,

[15:51] was ich da so verzapfe in meiner Dokumentation.

[15:54] Nächstes Beispiel, was ich hatte, ist dann sowas wie die Übertragung muss verschlüsselt erfolgen.

[15:58] Da wurde dann ganz viel Wert auf Sicherheit gelegt.

[16:00] Auch in der ganzen Doku.

[16:01] Nicht nur an der einen Stelle.

[16:02] Das stand da irgendwo auch im Pflichtenheft.

[16:04] Komplette Übertragung zum Server muss verschlüsselt erfolgen.

[16:07] Ist ja gut.

[16:08] Dann guckt man sich später auch wieder im Source-Code die Sachen an

[16:11] und sieht sich die URLs an, die da aufgerufen werden.

[16:13] Fangen alle mit HTTP an.

[16:14] Also wird alles unverschlüsselt über die Leitung geballert.

[16:16] Teilweise auch sogar mit Passwörtern, die im Klartext im Code standen.

[16:19] Und ich weiß nicht was.

[16:20] Also auch hier wieder.

[16:21] Passt überhaupt nicht A zu B.

[16:23] Was vorne erzählt wird und hinten im Code, das passt überhaupt nicht zusammen.

[16:26] Das geht einfach nicht.

[16:28] Dann hatten wir noch einen Kollegen, der gesagt hat, ja, wir haben ja so tolle Code-Coverage und so.

[16:33] Wir achten immer darauf, dass mindestens 90% unseres Codes mit Tests abgedeckt ist.

[16:38] Da habe ich mir gedacht, oh jetzt wird es spannend.

[16:40] Da gucke ich mal den Code hinten an.

[16:41] Und was sehe ich da im Anhang?

[16:43] Gar nichts.

[16:44] Nicht einen einzigen Test gezeigt.

[16:45] Kleinen Code-Ausschnitt.

[16:47] Das war aber eine Void-Funktion.

[16:49] Das heißt, konnte ich keinen Test für schreiben.

[16:51] Und den habe ich dann auch im Fachgespräch gefragt.

[16:53] Ja Mensch, hier, 90% Code-Coverage.

[16:54] Da ist eine Void-Funktion hinten drin.

[16:56] Wie hast du den getestet?

[16:57] Der hat gesagt, ja, das war es dann auch.

[17:01] Also von wegen 90% Code-Coverage.

[17:02] Der hat wahrscheinlich nicht einen einzigen Test geschrieben.

[17:04] So, und das geht natürlich auch nicht.

[17:06] Du kannst nicht einfach irgendwas behaupten in der Doku, was einfach nicht stimmt.

[17:09] Also wir kriegen das so schnell raus.

[17:11] Jetzt habe ich im Fachgespräch explizit nachgefragt sogar.

[17:14] Aber auch in der Doku selber, wenn du es nicht gemacht hast.

[17:18] Du musst an so vielen Stellen darauf achten, dass du auch korrekt vorgibst, es getan zu haben.

[17:23] Das geht einfach nach hinten los.

[17:24] Wenn du was nicht gemacht hast, dann tu auch nicht so, als hättest du es gemacht.

[17:27] Das ist einfach Quatsch.

[17:28] Wir kriegen das sowieso raus.

[17:30] Und das gibt auf jeden Fall einen Punktabzug.

[17:32] Weil es einfach nicht stimmt, was du gesagt hast.

[17:34] Das ist einfach Schrott.

[17:36] Und letzter Punkt zur Qualitätssicherung.

[17:38] Habe ich auch mehrfach gelesen und auch im Fachgespräch gehört.

[17:41] Der Debugger, beziehungsweise Konsolen-Ausgaben sind auch eine Form von Tests.

[17:46] Das heißt, da wird der Code getestet, indem er im Debugger durchlaufen wird.

[17:51] Beziehungsweise indem auf der Konsole, es stand wirklich wörtlich drin, Konsolen-Ausgaben produziert werden.

[17:55] Und da wird einfach geguckt, ob die stimmen.

[17:57] So, das passt natürlich auch hinten und vorne nicht zusammen.

[17:59] Also Debuggen und Konsolen-Ausgaben haben mit Tests nichts zu tun.

[18:02] Bei Tests denke ich an Unit-Tests, Integrations-Tests, System-Tests, Smoke-Tests, Regressionstests.

[18:08] Ich weiß nicht, da gibt es 57 verschiedene Testgeschichten.

[18:10] Ich glaube, ich habe dafür schon mal eine Podcast-Episode aufgenommen.

[18:13] Zwinker Zwinker.

[18:14] Und Debugging hat wirklich überhaupt gar nichts mit Tests zu tun.

[18:17] Debugging ist der Vorgang, Fehler in meinem Code zu finden und die dann zu fixen.

[18:21] Das hat aber nichts damit zu tun, zu zeigen, dass der Code korrekt funktioniert.

[18:24] Das sind zwei unterschiedliche Paar Schuhe.

[18:26] Also bitte nicht durcheinanderwerfen und vor allem nicht im Kapitel Qualitätssicherung schreiben,

[18:31] ich habe mit dem Debugger meinen Code getestet.

[18:33] Das ist einfach Banane.

[18:36] Gut, weiter geht's.

[18:37] Nächster Punkt, Qualitätssicherung abgehakt, kommen wir zur Wirtschaftlichkeit,

[18:41] beziehungsweise der Amortisationsrechnung.

[18:43] Auch da habe ich wieder so viele schöne Sachen dieses Jahr gefunden.

[18:46] Ich muss die Liste ein bisschen zusammenstreichen, damit es nicht die ganze Zeit nur über die Wirtschaftlichkeit heute geht.

[18:50] Ich habe mal so ein paar Sachen, die mir einfach aufgefallen sind.

[18:53] Und zwar, da wird dann munter so eine Pauschale angerechnet für die Ressourcennutzung.

[18:57] Hm, woher kommt das wohl aus meiner Vorlage?

[18:59] Ich bin mir nicht ganz sicher.

[19:01] Auf jeden Fall machen viele Prüflinge das heutzutage so, dass sie einfach sagen,

[19:04] ich habe einen Stundensatz, ich darf den nicht rausgeben.

[19:06] Ach übrigens, der Betracht trägt 25 Euro rein zufällig, so wie er in der Vorlage steht.

[19:11] Und wir müssen ja auch noch so ein bisschen die Ressourcennutzung einplanen.

[19:14] 10 Euro rechnen wir da drauf.

[19:16] Seltsam, dass diese Zahlen in meiner Vorlage stehen.

[19:18] Ja, ich weiß auch nicht.

[19:19] Sehr ähnlich wohl ist das Unternehmen zur alten Oldenburger.

[19:22] Nun ja, kann ja sein, dass die eine sehr ähnliche Kostenstruktur haben.

[19:25] Denken wir uns nichts dabei.

[19:26] Wenn dann allerdings diese 10 Euro Ressourcenpauschale gar nicht in die Kostenrechnung einfließen,

[19:31] dann ist da wohl ein grober Schnitzer passiert.

[19:33] Das heißt, wenn ich 25 Euro Stundensatz annehme für den Azubi, also für den Prüfling,

[19:38] und dann aber die 10 Euro, die eigentlich noch pro Stunde oben drauf hätten gerechnet werden müssen,

[19:42] das sind dann bei 70 Stunden auch mal eben 700 Euro,

[19:45] bei vielleicht so Gesamtkosten von 2.000 bis 3.000 Euro für so ein Projekt schon eine ganz schöne Menge.

[19:52] Das wird dann einfach nicht mit eingerechnet.

[19:54] Also einfach ein handwerklicher Rechenfehler.

[19:57] Und die Amortisation verzögert sich dann natürlich auch enorm, wenn man das dann wirklich noch mit einrechnet.

[20:02] Auch bei ganz vielen Projekten dieses Jahr wieder falsch gesehen, laufende Kosten

[20:06] gibt es bei den Projekten grundsätzlich mal gar nicht. Das heißt, ein Projekt wird

[20:09] umgesetzt, das kostet dann x 1.000 Euro. Das geht übrigens so von von 1.000 Euro

[20:14] bis 7.000 Euro, habe ich alles schon gesehen. Also Azubis, die irgendwie 3,40 Euro

[20:18] die Stunde angesetzt bekommen, bis hin zu, ich glaube, 120, weil der höchste

[20:22] Stundensatz, den ich für einen Azubi gelesen habe, ich mir auch gedacht, Leute, das kann

[20:24] nicht wahr sein. Aber egal, auf jeden Fall, das ist also, die Kosten gehen von

[20:30] 1.000 bis 7.000 Euro, aber laufende Kosten für so ein Projekt eigentlich nie.

[20:33] Das heißt, wenn ich die Web-Anwendung erst mal auf dem Server deployed habe,

[20:36] ja, der Server ist ja eh da. Ich glaube, da hatte ich schon öfter darüber geredet,

[20:40] über diese eh-da-Kosten. Es gibt keine Kosten, die eh da sind und die ich nicht

[20:44] anrechnen muss. Wenn meine Applikation auf dem Server läuft, dann braucht der

[20:48] Server irgendwelche Ressourcen, um meine Anwendung auszuspielen und das kostet

[20:51] Geld und das muss ich einrechnen. Da kann ich nicht einfach sagen, hier, Admin,

[20:54] nimm die Anwendung und ich will nie wieder was davon hören. Das geht so

[20:57] einfach nicht, ja. Also, ein Projekt ohne laufende Kosten, es mag sein, dass es so

[21:02] was mal gibt, habe ich sehr selten gesehen. In den meisten Projekten fehlt

[21:05] diese Berechnung einfach. Ganz häufig hatten wir auch einfach fachliche Fehler

[21:10] bei der Amortisationsrechnung. Da wurde ganz individuell ausgerechnet, wie die

[21:14] Kosten der Anwendungserstellung zusammengesetzt wurden. Überhaupt keine

[21:18] Frage, Stundensatz. Teilweise auch sogar alles richtig berechnet. Aber bei der

[21:21] Amortisation wird dann die Einsparung des Kunden da gegenüber gerechnet. Das

[21:26] heißt, ich rechne meine Kosten als Unternehmen aus und gucke dann, wann der

[21:29] Kunde meine Kosten amortisiert hat. Das passt einfach nicht. Also, wenn ich meine

[21:35] Kosten ausrechne, dann muss ich auch für das Unternehmen ausrechnen, wann sich das

[21:39] Projekt für das Unternehmen rentiert. Das heißt, ich muss vielleicht

[21:42] gegenüberstellen, Verkaufserlöse zu erwartende Kunden, die irgendwas kaufen

[21:46] oder ich weiß es nicht, meinetwegen noch eine Nutzwertanalyse mit irgendwelchen

[21:49] weichen Faktoren. Ich weiß es nicht. Aber ich kann nicht meine Kosten mit der

[21:54] Zeitersparung des Kunden gegenrechnen. Das passt einfach nicht. Wenn ich es beim

[21:59] Kunden rechnen will, dann stelle ich seine Zeitersparnis gegen seine Kosten.

[22:04] Also zum Beispiel seinen Einkaufspreis, den er für unser Produkt gezahlt hat. Ich

[22:08] kann nicht Äpfel mit Birnen vergleichen. Ich muss auf einer Seite mir die

[22:12] korrekten Kosten und Ersparungen angucken und nicht beides durcheinander

[22:16] mischen. Gefühlt hatte ich das in der Hälfte aller Dokumentationen,

[22:19] dass das komplett durcheinander gewürfelt wurde. Wenn wir jetzt

[22:26] gerade noch bei der Kostenplanung sind. Es gibt auch einige Projekte, wo einfach

[22:29] mal so ein paar Kosten vergessen wurden. Da wurde zum Beispiel so eine

[22:33] Plattform gebaut, ein bisschen Software entwickelt. Da mussten auch noch Inhalte

[22:37] in diese Plattform rein und die wurde von den eigenen Mitarbeitern erstellt.

[22:40] Zum Beispiel Texte oder Audioaufnahmen, Videos mussten auch produziert werden.

[22:44] Kostenersparnis tritt ein, wenn die Plattform online ist mit allen Inhalten.

[22:49] Leider wurde nur eingerechnet, die Plattform zu erstellen. Das Erzeugen der

[22:52] Inhalte wurde nicht mit eingerechnet. Oder es hätte die Projektkosten bestimmt

[22:55] um das x-fache noch überstiegen und dann wäre die Amortisationsrechnung auch

[22:58] ganz schön kläglich gescheitert wahrscheinlich. Also ich weiß nicht, ob es

[23:01] absichtlich vergessen wurde, in Anführungszeichen. Auf jeden Fall wurde

[23:04] ein großer Batzen nicht mit eingerechnet und ich vermute, um das ein

[23:08] bisschen schön zu rechnen, in Anführungszeichen. Das fällt natürlich

[23:10] auch auf, wenn man sich das ein bisschen anguckt, das Projekt. Denn gerade bei der

[23:14] Kostenkalkulation gucken wir ja immer drauf, ob da nicht vielleicht irgendwie

[23:17] ein bisschen, zum Beispiel Äpfel mit Bieren verglichen wurden jetzt, wo wir es

[23:20] gerade gehört haben. Oder halt irgendwas vergessen wird, falsch kalkuliert wird

[23:23] und so weiter. Ja auch was schön ist, was ich dieses Mal gesehen habe, da wollte

[23:27] wohl jemand eine App entwickeln und hatte überhaupt gar keine Ahnung, was er denn

[23:30] überhaupt an Kosten ansetzen soll. Und hat dann einfach so eine Website bemüht

[23:34] und dort irgendwie ein paar Klicks gemacht und dann kam raus, so eine App,

[23:37] wenn du sie extern entwickeln lassen würdest, kostet dich x-tausend Euro.

[23:41] Und mit dieser Kostenrechnung oder Kostenvoranschlag kann man fast sagen,

[23:47] die man wahrscheinlich in 30 Sekunden auf der Website zusammenklicken kann.

[23:50] Damit hat er dann seine Amortisationsrechnung gemacht. Da habe ich

[23:52] auch gedacht, wie kommen die Leute auf so was? Ich kann es einfach nicht

[23:56] nachvollziehen. Aber ja, mein kleines Kostenhighlight aus Projektdokumentation.

[24:01] Nun denn, okay, das war die Wirtschaftlichkeit, Amortisationsrechnung.

[24:04] Wir gehen mal weiter zum nächsten Punkt und zwar Diagramme. Ich mag Diagramme, ich

[24:08] will Diagramme in Projektdokumentation unbedingt. Das muss da drin sein, das

[24:12] ist für mich ganz ganz wichtig und auch vielen anderen Prüfern ist das wichtig.

[24:15] Da sollte man aber darauf achten, dass man die auch korrekt benutzt. Wir hatten

[24:19] zum Beispiel dieses mal ein ER-Modell, Entity Relationship Model und da waren dann

[24:22] M zu N Tabellen aufgelöst. Also das heißt, beides munter durcheinander

[24:27] gemischt. ER-Modell und Tabellenmodell. Ich nehme einfach aus jedem

[24:30] Modell so ein bisschen das, was mir am besten gefällt und mache mein eigenes

[24:33] draus. Ich habe zwei Episoden aufgenommen zum ER-Modell und zum

[24:36] Tabellenmodell, was die Unterschiede sind und wofür man welches benutzt. Und das

[24:40] sollte jedem Prüfling klar sein. Das wird so oft auch in den schriftlichen

[24:44] Prüfungen abgefragt. Und dann kriege ich in der Dokumentation trotzdem so ein

[24:47] Mischmasch mit Sachen, die einfach nicht zusammengehören. Also in einem

[24:50] ER-Modell gehören keine M zu N Tabellen. Das gibt es dort einfach nicht.

[24:54] Und wenn es dann da eingezeichnet wird, dann ist das leider einfach falsch und

[24:58] dann müssen wir einfach Punkte abziehen. Ganz klassischer Fehler übrigens auch,

[25:01] was wir ganz häufig hatten in Use-Case-Diagrammen. Use-Case hat fast jedes Projekt,

[25:05] was ich auch sinnvoll finde, so als abstrakte Sicht auf das Projekt. Völlig

[25:09] in Ordnung. Aber diese zwei Syntax-Elemente, die es da gibt, include und

[25:13] extend, dass man die ständig durcheinander bringt. Ich kann es nicht

[25:17] nachvollziehen. Das Use-Case-Diagramm ist eins der einfachsten Diagramme meiner

[25:20] persönlichen Meinung nach. Dann male ich ein Strichmännchen, dann male ich einen

[25:23] Kasten und ein paar Blöppel rein und da sind dann Use-Cases und da mache ich Striche

[25:26] dran. Und dann gibt es zwei Sachen, wie ich Use-Cases miteinander kombinieren

[25:29] kann. Include und extend. Include bedeutet, der inkludierende Use-Case kann nur

[25:36] erfüllt werden, wenn auch der, der inkludiert wird, mit erfüllt wird. Das

[25:40] heißt, eine Pflichtbeziehung. A includes B bedeutet, ich kann nur A durchführen,

[25:46] wenn auch B mit durchgeführt wird. Das ist includes. Und das extends ist

[25:51] optional. Das heißt, wenn ich A habe und B extends A, dann kann es sein, dass

[25:57] zusätzlich zu A auch noch B ausgeführt wird. Aber das muss nicht. Also include

[26:01] ist obligatorisch, extend ist optional. Und beim extend muss man auch so kleine

[26:06] Extension-Points einzeichnen und so weiter und so fort. Auf die Richtung der

[26:09] Pfeile sollte man auch achten. Das ist ein ganz, ganz häufiger Fehler, den wir

[26:13] in vielen Diagrammen dieses Mal gesehen haben, dass einfach überall

[26:16] includes benutzt werden. Und dann hatte ich hier sowas geiles wie zum Beispiel, ich

[26:21] weiß nicht mehr, was es war, ich sage jetzt einfach mal Antrag anlegen und Antrag anlegen

[26:25] includes Antrag löschen. Also einfach völlig Banane. Wenn ich den Antrag anlege,

[26:29] muss er auch gelöscht werden. Das Diagramm ist wirklich

[26:33] sehr, sehr einfach zu zeichnen und diese beiden einzigen Syntax-Elemente, die es

[26:38] da noch gibt, die sollte man drauf haben als Prüfling und die einfach nicht

[26:40] durcheinander bringen. Gut, nächster Punkt. Ein einzelner.

[26:44] Aktionen werden nicht in der Zeitplanung berücksichtigt. Da haben wir auch ein

[26:47] paar Experten, die dann irgendwo noch mal gehört haben, ich muss ja noch

[26:50] Qualitätssicherung machen, weil das in so einer Vorlage steht. Also brauche ich noch

[26:52] drei Stunden Code Review. Und Schulung müssen wir auch noch machen. Ja gut, Mitarbeiter müssen

[26:56] auch noch geschult werden. Hier noch mal vier Stunden, zack. Und dann tauchen diese

[26:59] Stunden aber leider nirgendwo in der Ressourcenplanung auf. Es gibt ja diese 70

[27:03] Stunden, die aufgeteilt werden müssen. Da findet man das dann einfach gar nicht.

[27:06] So Code Review, da wird dann auch noch sogar geschrieben, ja, ich habe ein Code Review mit

[27:09] meinem Ausbilder gemacht und der Ausbilder hat mir auch Feedback gegeben und

[27:12] lalala. Diese drei Stunden zum Beispiel finde ich aber nirgends in der Zeitplanung.

[27:15] Und auch diese vier Stunden Schulung zum Beispiel. Am Ende, zur Einführung, wurde

[27:18] noch eine Schulung durchgeführt von mir, dem Autor. Aber diese vier Stunden

[27:22] stehen auch nicht in der Zeitplanung. So, das sind natürlich, wenn ich jetzt mal

[27:24] vergleiche, drei und vier Stunden, wenn ich die beiden addiere, sind schon sieben.

[27:27] Das heißt, zehn Prozent der Projektzeit sind offensichtlich unverplant irgendwie

[27:31] durchgeführt worden, beziehungsweise on top gerechnet. Davon muss ich ja

[27:35] ausgehen. Wenn der Autor schreibt, Mensch hier, ich habe die Schulung

[27:37] durchgeführt, vier Stunden lang, aber die vier Stunden stehen nicht in den 70

[27:41] Stunden drin, dann hat er wohl 74 Stunden für das Projekt gebraucht. Und das war

[27:44] nicht erlaubt. Also da ist man schon ganz hart an der Grenze von, ich habe die Zeit

[27:48] nicht eingehalten. Naja. Okay, also sollte man auf jeden Fall

[27:52] darauf achten, alles was gemacht wurde, muss auch in der Zeitplanung stecken.

[27:56] Ich kann nicht sagen, ja, ich habe dann auch nochmal irgendwie zusätzlich so

[27:59] einfach nice eine kleine Schulung gemacht über zehn Stunden. Habe ich zwar

[28:02] nicht eingeplant, aber das macht man ja so. Nein, das geht nicht. Du darfst nur

[28:05] 70 Stunden für dein Projekt benutzen und alles, was du in der Zeit machen willst,

[28:09] hat auch in der Planung zu stehen. Fertig. Gut, nächster Oberpunkt für mich,

[28:14] uninteressante Inhalte. Das liebe ich. Wenn ich mir eine Doku angucke und ich sehe

[28:19] schon, über Seiten wird ein völlig trivialer Algorithmus beschrieben oder

[28:23] irgendwie, wenn ich auf den Button klicke, passiert das und das und das wird dann

[28:25] über zwei Seiten ausformuliert mit Screenshots und ich weiß nicht was.

[28:28] Oh man, da weiß ich schon, die Doku hat einfach nicht genug Tiefgang. Da ist

[28:32] die fachliche Tiefe einfach sehr stark in Frage gestellt. Und ich habe jetzt

[28:36] einfach mal so ein paar Stichpunkte mitgebracht, um zu zeigen, woran ich so

[28:38] was festmache. Ich habe wieder über mehrere Seiten im Anhang völligst

[28:43] langweiligen Source-Code gesehen. Getter, Setter, rauf und runter. Irgendwelche

[28:47] Struct-Definitionen ohne Methoden oder sowas. Einfach nur Felder, also wirklich

[28:52] teilweise Klassen mit 30 Attributen, die einfach stumpf hinten im Anhang standen.

[28:56] Wirklich über mehrere Seiten. Das ist einfach so, ja weiß ich nicht, was soll ich

[29:00] damit anfangen? Was soll mir der Code sagen? Der sagt mir nichts.

[29:03] Da kann ich nicht ansatzweise daraus ablesen, ob die Person

[29:07] programmieren kann oder nicht. Also dieser Code ist für mich als Prüfer

[29:09] völlig wertlos. Und so bewerte ich das auch. Ich streiche einfach durch, das ist

[29:14] für mich verschenkter Platz. Highlight dieses Jahres, ungelogen, ich habe es

[29:18] nachgezählt, acht Seiten Mockups im Anhang. Das heißt, von jedem einzelnen

[29:24] Screen, der, ich sage jetzt mal Web-Anwendung, ich weiß es nicht mehr,

[29:27] war da ein Mockup zu sehen. Die Mockups waren nett, keine Frage, aber acht Seiten

[29:32] Anhang, sorry, also das ist einfach viel zu viel. Eine einzige Seite hätte locker

[29:36] gereicht, um ein Mockup zu zeigen. Und zusätzlich dann auch noch sechs Seiten

[29:40] Quelltext. Also deshalb manchmal frage ich mich, haben die Leute nichts

[29:43] anderes zu zeigen? Also ich weiß auch nicht. Bei einigen Dokus hatten wir es

[29:47] dann so, dass teilweise sogar der komplette Quelltext im Anhang stand. Und

[29:51] da wird es dann kritisch, wenn man dann sieht, dass der komplette Anhang nur zwei

[29:55] Seiten lang ist. Und das ist der komplette Quelltext. Na gut, also langweilige

[30:00] Sachen nicht auf 1000 Seiten aufblasen und in den Anhang packen. Bitte, bitte,

[30:03] bitte. Ihr habt so viele oder du hast so viele interessante Sachen, die du noch

[30:07] zeigen kannst. Also ballert den Anhang nicht mit so einem Schrott voll, bitte.

[30:11] Was ich auch gesehen habe dieses Jahr zum ersten Mal so bis ins letzte Detail

[30:15] der Arbeitsplatzrechner vorgestellt. Es gibt ja auch in meiner Vorlage ein

[30:18] Kapitel Ressourcenplanung. Muss man ja auch machen. Was habe ich eingesetzt? PC,

[30:22] Software, tralala. Aber dass dann wirklich bis auf den RAM-Riegel runter erklärt

[30:26] wird, wie der Arbeitsplatzrechner aussieht. Mit DDR3-RAM. Und dann habe ich

[30:30] noch den Typ der Grafikkarte mit NVIDIA XY tralala. Also sorry, das interessiert

[30:35] mich einfach überhaupt nicht. Mich interessiert vielleicht, ob ich einen

[30:38] Rechner habe oder ein Thinclient oder ein MacBook oder weiß der Geier was. Aber

[30:41] ich will jetzt nicht noch, keine Ahnung, die, ich wollte schon sagen,

[30:44] Fahrgestellnummer der Netzwerkkarte haben oder so. Das ist mir völlig Wumpe.

[30:48] Es geht hier um eine grobe Planung und ich möchte sehen, dass der Prüfling

[30:52] weiß, was er alles einkalkulieren muss und dass diese Hardware, wie wir in der

[30:55] Prüfung immer so schön sagen, nicht einfach vom Himmel fällt, sondern dass

[30:58] irgendwer die bezahlen muss. Aber ich will wirklich nicht wissen, welche

[31:02] Bauart der RAM-Riegel hat. Das interessiert mich einfach nicht. Und diesen Platz kann

[31:04] man echt für bessere Sachen nutzen. Dann hatten wir noch einen Experten, der die

[31:09] Zeitplanung etwas übertrieben hat. Der hat seine komplette Zeitplanung auf drei

[31:12] verschiedenen Arten und Weisen dargestellt. Einmal als Gantt-Chart, einmal

[31:14] als Tabelle, die üblichen 70 Stunden aufgeteilt, wie in meiner Vorlage, und

[31:18] nochmal als Projekt-To-Plan. Also wirklich exakt das Gleiche auf drei

[31:21] verschiedene Varianten dargestellt. Hat natürlich auch dann drei Seiten im

[31:24] Anhang geklaut, die man hätte vielleicht sinnvoller nutzen können.

[31:27] Nun denn, was haben wir noch? Lächerlich einfache Abläufe mit Diagrammen

[31:30] darstellen, habe ich mir aufgeschrieben. Also ohne Scheiß. Ich hatte jetzt

[31:34] wirklich mal ein Sequenz-Diagramm mit zwei Lebenslinien. Da ging ein Pfeil nach

[31:38] rechts und ein Pfeil wieder zurück nach links. Und das war das gesamte

[31:41] Sequenz-Diagramm. Also einmal hin, her. Ja, so Ping, Pong. Das war das komplette

[31:45] Sequenz-Diagramm. Ein Aktivitäts-Diagramm mit einer einzigen Verzweigung und

[31:49] danach war Schluss. Ja, das ist ein Witz. Also sorry, das sind einfach

[31:54] diese Methodiken angewendet, weil irgendwer gesagt hat, ich muss sie

[31:57] anwenden. Dann mache ich es für eine Verzweigung mal ich ein

[32:00] Aktivitäts-Diagramm und für einen Methodenaufruf mal ich ein Sequenz-Diagramm.

[32:03] Das ist einfach völlig lächerlich. Das erfüllt den Zweck dieser

[32:07] Diagramme überhaupt gar nicht. Entweder will ich damit meine Software-Methode

[32:11] planen, dann baue ich da rein, wer mit wem wie kommuniziert. Habe ich auch super

[32:15] gemacht gesehen dieses Mal. Frontend ruft Backend auf, ruft Server auf, ruft hin.

[32:20] Also richtig gut gemacht, um das Problem darzustellen. Aber nicht einfach hin, her

[32:23] und das war es, weil irgendwer gesagt hat, ich muss ein Sequenz-Diagramm malen.

[32:25] Das ist Quatsch. Also entweder zur Planung mache ich das oder zur

[32:29] Dokumentation. Vielleicht habe ich ja so einen komplexen Ablauf, dass ich das im

[32:32] Source-Code nicht gut nachvollziehen kann. Dann male ich es mal einmal auf.

[32:35] Das ist der zweite Zweck. Entweder ich nutze zum Beispiel jetzt die UML zur

[32:39] Planung meiner Software, bevor ich anfange zu programmieren. Oder im

[32:42] Nachhinein, um sie zu dokumentieren, weil es so einfacher zu verstehen ist, als wenn

[32:46] ich ins Source-Code gucke. Aber ich mache das nicht einfach nur als Mittel zum Zweck,

[32:49] weil ich gerade eine IRK-Dokumentation schreiben muss. Das ist einfach bekloppt.

[32:53] Und dabei kommen dann solche Sachen raus, wie ein Sequenz-Diagramm, was einmal von

[32:56] links nach rechts geht. Was ich dann auch gesehen habe, sind

[33:00] teilweise Dinge, die einfach überhaupt nicht zum Rest des Inhalts passen.

[33:03] Also da kommen dann einfach mitten in irgendeinem Kapitel Ausschnitte von

[33:06] irgendwelchen Artefakten, ohne Verweis, ohne Erklärung, ohne irgendwas. Da hatte

[33:11] ich dann, ich weiß gar nicht mehr, was das war. Da war, glaube ich, irgendwie so ein

[33:12] Auszug aus so einer POM-XML. Also ein Java-Projekt mit Maven gebaut und in der

[33:16] POM stehen ja die ganzen Abhängigkeiten drin. Hier, keine Ahnung, ich brauche die

[33:20] Guava-Bibliothek in Version XY. Das steht dann in der POM. Und da waren dann

[33:23] irgendwie fünf Zeilen Ausschnitte aus der POM, einfach mitten im Text. So ohne

[33:27] irgendeiner Leitung. Und das passte auch gerade gar nicht. Also vielleicht ist das

[33:29] da irgendwie hingerutscht. Aber ich habe durchsucht in der Dokumentation an

[33:33] keiner anderen Stelle, wo das Ding überhaupt irgendwann mal erwähnt. Also

[33:35] völlig sinnfrei irgendwie. Das ist auch keinem aufgefallen offensichtlich. Da

[33:39] habe ich auch gedacht, wie kann das sein? Und mein persönliches Highlight dieses

[33:43] Jahr, wo ich dachte, das kann einfach nicht wahr sein. Wir sind immer noch beim

[33:46] Oberpunkt uninteressante Inhalte, nicht vergessen. Da war es tatsächlich im

[33:50] Anhang eine Seite CSS-Code, wo ich mir dachte, ja Mensch, CSS ist ja okay, wenn

[33:54] er es selber geschrieben hat, ist ja auch eine Leistung, finde ich gut. Aber dann

[33:58] hat er tatsächlich das Minified-CSS gezeigt. Es gibt ja heutzutage bei Web

[34:03] Frameworks, so kleine Prä-Kompilierer zum Beispiel, die auch gerade bei CSS und

[34:08] JavaScript und so, das, was man wirklich geschrieben hat, minifizieren. Das heißt

[34:12] alle Leerzeichen raus, alle Zeilenumbrüche raus, Variablen durch

[34:15] einen Buchstaben ersetzen und so. Dass es einfach nicht so viele Bytes groß wird,

[34:18] der Code. Weil das muss ja alles zum Browser übertragen werden, die Beleitung.

[34:21] Also minifizieren nennt man das. Und da hat er tatsächlich in seinem Anhang das

[34:25] minifizierte CSS gezeigt. Da konnte keine Sau was mit anfangen, weil alle

[34:30] Bezeichner gekürzt waren, ja. Keine Zeilenumbrüche drin, keine Leerzeichen,

[34:34] gar nichts. Alles aneinander geklatscht. Das kann man sich wirklich vorstellen,

[34:36] wie eine riesig lange Zeile CSS und dann aber auf einer Seite ausgedruckt.

[34:41] Also sowas habe ich auch noch nie gesehen. Ich weiß nicht, wie man auf

[34:44] solche Ideen kommt. Keine Ahnung. Auf jeden Fall war es, ja, mein persönliches

[34:48] Highlight von absolut sinnlosen Inhalten in der Produktdokumentation dieses Jahr.

[34:53] Okay. So, absolut uninteressante Sachen. Damit sind wir jetzt fertig. Jetzt kommen

[34:58] wir zum nächsten Punkt. Overkill habe ich den mal genannt. Es gibt auch immer so ein

[35:01] paar Experten, die meinen, sie formulieren hier gerade ihre Dissertation und so

[35:06] liest sich dann, ich hatte es ganz am Anfang gesagt, eine hochgestochene Sprache

[35:09] und so. Das haben wir abgehakt. Aber jetzt kommen noch so ein paar Sachen, wo ich

[35:11] gedacht habe, Leute, das ist einfach viel zu viel für so eine Projektdokumentation.

[35:14] Nummer eins auf meiner Liste, persönliches Highlight dieses Jahr für

[35:17] mich, eine Kostenkalkulation, die über drei Seiten ging. Also da übertreibe ich

[35:21] jetzt wirklich nicht. Die ganzen Seiteneingaben, die ich hier mache, die

[35:24] habe ich wirklich nachgezählt, weil ich das für mich auch immer mache. Also auch

[35:27] 15 Seiten sind vorgegeben. Wenn drei Seiten davon Kostenkalkulation ist, weiß

[35:30] man, es ist nicht mehr viel Platz für den Rest. So, also wirklich drei Seiten

[35:33] Kostenkalkulation mit intensivsten mathematischen Formeln, mit verschiedenen

[35:38] Indizes. Also nicht einfach Kosten des Kunden gleich, sondern sowas wie K von

[35:43] Kunde und Kunde steht dann so im Index eingerückt unten drunter und so. Also

[35:47] die wildesten Sachen und dann auch ganz über mehrere Zeilen irgendwelche

[35:50] komplexen Formeln, wobei so komplex waren die gar nicht. Das war einfach nur

[35:53] Addition. Sowas wie meine Kosten plus Kosten des Kunden plus irgendwas, aber

[35:57] hoch wissenschaftlich gemacht mit Indizes und tralala. Und darunter dann

[36:01] jeweils noch eine Legende, so nach dem Motto K Kunde heißt Kosten des Kunden

[36:05] und so weiter. Und deswegen ging das Ding auch über drei Seiten. Also wirklich

[36:08] einfach mega aufgepumpt, aufgeblasen, ohne wirklichen Inhalt zu liefern. Und

[36:13] das war einfach völliger Overkill. Ich glaube, der Kollege hat zum ersten Mal

[36:16] mit LaTeX Formeln gesetzt und sich gedacht, boah geil, dann mache ich jetzt nochmal richtig was

[36:20] raus. Aber sinnvoll war das definitiv nicht. Mega Seitenverschwendung war das

[36:24] einfach nur. Dann hatten wir noch einen, der eine komplette Seite typografische

[36:29] Konventionen gezeigt hat. Ich meine, wenn ich eine Bachelorarbeit, eine Masterarbeit

[36:31] schreibe, mag das ganz nett sein, zu sagen, hey, alles was kursiv ist, ist ein

[36:34] Klassenname oder so. Okay, hier sind noch Projektdokumentationen über 15 Seiten, war

[36:39] das einfach Overkill. Also ich muss nicht sagen, hier alle

[36:42] Klassennamen werden in Monospace-Font geschrieben, alles was mit grauem

[36:46] Hintergrund ist, ist eine Tabelle oder sonst was. Das ist einfach, das kann

[36:50] ich aus dem Kontext erschließen. Dafür brauche ich keine typografischen

[36:52] Konventionen. Also es ist einfach, wir schreiben hier keine wissenschaftliche

[36:55] Arbeit. Das ist eine Projektdokumentation. Da müssen wir immer mal die Kirche im

[36:58] Dorf lassen. Der gleiche Experte hat übrigens in seiner Dokumentation, ohne

[37:03] Scheiß, fünf Überschriften-Ebenen benutzt. Also Überschriften meine ich,

[37:07] Überschrift 1, 2, 3, alles im Inhaltsverzeichnis und so dann gegliedert ist.

[37:11] 15 Seiten hat er es hingekriegt, bis zur fünften Überschriften-Ebene runter zu

[37:16] gehen. Das heißt, so ein Kapitel 3.1.1.4.a, ja, das war dann, glaube ich,

[37:23] ein Unterpunkt der Kostenkalkulation und irgendwas. Also sorry, das ist einfach viel

[37:27] zu detailliert. Das ist Quatsch. Ich habe mal den Spruch gehört, dass man

[37:31] selbst für eine Dissertation maximal drei Überschriften-Ebenen braucht, denn

[37:35] ansonsten hat man einfach viel zu lange Kapitel und zu, ja, zu aufgeblasene

[37:39] Kapitel und die Gedanken passen einfach schon gar nicht mehr zusammen. Und in

[37:42] diesem Fall war das genauso. Also ich übertreibe es mal, aber für jeden

[37:45] Absatz hat er fast eine eigene Überschrift gemacht. Und dann komme ich

[37:48] auch irgendwann auf fünf Überschriften-Ebenen, habe nur das Problem, dass

[37:50] die ja auch ganz viel Platz verbrauchen, denn die sind ja immer schön groß und

[37:53] haben Abstand. Das heißt, wenn man da mal die Seiten durchzählt, stellt man fest,

[37:56] huch, vielleicht war das auch nur ein Mittel, um auf 15 Seiten zu kommen. Aber

[37:59] okay, das hat sich jetzt mal dahingestellt. Auf jeden Fall, ganz klarer

[38:02] Tipp, deine Projektdokumentation braucht nicht mehr als drei

[38:06] Überschriften-Ebenen. Ich würde sogar so weit gehen, zu sagen, du brauchst maximal

[38:09] zwei bei 15 Seiten. Ja, alles andere ist overkill und völlig unsinnig. Dann haben

[38:17] wir noch einen, ich glaube, es war auch der gleiche. Der hat seine Amortisationsrechnung

[38:21] in irgendeinem mathematischen Software geplottet, also

[38:25] richtig mit so Rasterlinien im Hintergrund und so einer komischen

[38:28] Schrift und so. Da habe ich mir gedacht, man kann es auch einfach übertreiben. Warum nicht

[38:32] einfach mit Excel machen und fertig. Wir schreiben hier keine Dissertation, wie

[38:35] gesagt, es ist nur eine Projektdokumentation. Ja, ansonsten hatten wir auch noch jemanden,

[38:40] der schön mal ein bisschen wissenschaftlich was zitieren wollte und dann auch tatsächlich

[38:44] über mehrere Zeilen ein wörtliches Zitat auch sogar korrekt zitiert hat. Völlig okay,

[38:50] aber zu etwas, was mit seiner Projektdokumentation gar nichts zu tun hat,

[38:54] nämlich einfach beschrieben, wie das Wasserfallmodell, glaube ich, funktioniert.

[38:57] Ja, das muss man mir nicht erklären als Prüfer und auch den anderen Prüfern nicht,

[39:00] das wissen wir. Aber wenn man das dann tut, dann sollte dieses hochwissenschaftliche

[39:05] Zitat bitte nicht aus der Wikipedia stammen. Und so war es leider. Ja, das heißt, ein Fakt

[39:11] erklärt, der den Prüfern sowieso bekannt ist, mit einem wörtlichen Zitat mit Quellenangabe,

[39:17] wo man schon denkt, das ist ein bisschen overkill und dann steht in der Quellenangabe aber auch

[39:21] einfach nur Wikipedia. So und das ist einfach völlig Banane. Also hier, wie wirkt das auf

[39:27] mich? Das wirkt wie, irgendwer hat mir gesagt, ich muss mega hochtrabend hier diese Dokumentation

[39:31] schreiben, aber so richtig verstanden habe ich es nicht. Ich weiß auch gar nicht genau,

[39:34] warum ich das hier eigentlich gerade zitiere, weil jede Sau weiß eigentlich,

[39:37] was das Wasserfallmodell ist. Ist aber egal, ich nehme das einfach mal. Und weil ich noch

[39:42] nie was von Literaturrecherche gehört habe, nehme ich einfach die Wikipedia als Quelle an,

[39:45] geben wir davon aus, dass es okay ist. Also sorry, damit macht man niemanden glücklich.

[39:50] Wenn ich wissenschaftliches Arbeiten erwarten würde als Prüfer in der Dokumentation,

[39:55] dann würde ich die Hände über dem Kopf zusammenschlagen, wenn ich Wikipedia lese.

[39:58] Und wenn ich das nicht tue, was wahrscheinlich die Mehrheit der Prüfer macht,

[40:01] dann schlage ich sowieso schon mal die Hände über dem Kopf zusammen bei solchen wörtlichen Zitaten,

[40:05] die mir irgendwas erklären, was ich sowieso schon weiß.

[40:07] Das ist einfach unsinnig.

[40:08] Und dann kommt auch noch hinzu, dass das Zitat so lang war,

[40:11] in der Zeit auf dem Platz hätte ich einfach meine Arbeit darstellen können,

[40:16] anstatt eine allgemeine Formulierung oder Definition des Wasserfallmodells darzustellen.

[40:20] Das ist einfach an so vielen Stellen falsch.

[40:23] Das ist einfach, ja.

[40:25] Deswegen habe ich es hier auf der Liste der schlechten Beispiele.

[40:28] So.

[40:29] Ich merke gerade so ein bisschen, wie ich mich selber in Rage rede.

[40:32] Also manchmal, wenn ich die Dokus lese, also manchmal will ich sie echt aus dem Fenster schmeißen.

[40:38] Ich weiß nicht, wie die Leute auf sowas kommen.

[40:39] Wer rät denen solche Sachen?

[40:42] Du musst unbedingt ein Zitat in deine Dokumentation einbauen.

[40:46] Und dann aber bitte eine Wikipedia-Quelle nehmen.

[40:48] Also ich frage mich, wie kommen die Leute darauf?

[40:50] Ich kann das immer nicht nachvollziehen.

[40:52] Gut.

[40:53] Ich komme jetzt mal ein bisschen runter.

[40:54] Wir kommen jetzt zum vorletzten Punkt, zur Projektdokumentation.

[40:57] Und zwar nervige Kleinigkeiten.

[41:00] Das konnte ich nirgendswo anders einsortieren.

[41:01] Deswegen habe ich das hier mal drin.

[41:02] Das habe ich auch gefühlt bei der Hälfte der Leute angestrichen.

[41:05] Abkürzungsverzeichnis, sinnvolle Sache.

[41:09] Manchmal auch Glossar genannt.

[41:10] Ja, kann ich durchaus nachvollziehen, dass man das haben sollte.

[41:14] Gerade wenn man mit Fachbegriffen hantiert, die nicht jeder kennt.

[41:16] Oder auch mit Abkürzungen, die unterschiedliche Bedeutung haben können.

[41:19] Mein Beispiel ist immer DSL.

[41:21] Domain Specific Language.

[41:23] Könnte aber auch Digital Subscriber Line, also der DSL-Anschluss, zu Hause sein.

[41:27] Was meine ich jetzt?

[41:28] Dafür brauche ich ein Abkürzungsverzeichnis.

[41:29] Absolut richtig.

[41:31] Aber das dient mir als derjenige, der das liest, ja auch dazu, die Abkürzung schnell zu finden.

[41:37] Weil dafür ist das Abkürzungsverzeichnis ja da.

[41:39] Ich gehe dann da rein und gucke, was heißt es denn.

[41:41] Wenn dann das Abkürzungsverzeichnis nicht sortiert ist, dann habe ich irgendwie einen Fehler gemacht.

[41:45] Weil dann erfüllt das Abkürzungsverzeichnis nicht seinen Zweck.

[41:47] Ich möchte schnell die Abkürzung finden.

[41:50] Wenn ich dafür in einer unsortierten Liste über eine Seite suchen muss, wo es denn steht, Ziel verfehlt.

[41:55] Also bitte, bitte, bitte sortier doch einfach das Abkürzungsverzeichnis.

[41:58] Das ist überhaupt kein Problem.

[41:59] Das ist dein Job als Autor, ja.

[42:01] Nächster Punkt, der einfach immer wieder falsch gemacht wird.

[42:03] Seitennummerierung.

[42:04] Ja, da fängt der Inhalt irgendwie auf Seite 6 an.

[42:06] Weil vorher sind ja auch noch Verzeichnisse drin und alles mögliche.

[42:09] Warum kann man es nicht hinkriegen, den Fließtext ganz normal auf Seite 1 beginnen zu lassen?

[42:14] Damit ich nicht, und das muss ich leider dann tun, jede Seite durchzählen muss

[42:19] und gucken muss, ob die Leute auch auf 15 Seiten kommen.

[42:21] Das ist einfach nur, ja, nervig.

[42:23] Deswegen habe ich es unter nervige Kleinigkeiten hier drin.

[42:26] Dafür würde ich jetzt keine 10% abziehen von der Note, ja.

[42:29] Aber es nervt mich als Prüfer.

[42:30] Und glaube mir, genervte Prüfer sind nicht die besten Prüfer im Sinne deiner Note, ja.

[42:35] Also bitte, macht doch solche Kleinigkeiten. Einfach vernünftig.

[42:39] Ansonsten haben wir auch Experten, die irgendwo gelesen haben, in so einer Vorlage im Internet vielleicht,

[42:43] dass man auch so ein Quellenverzeichnis haben muss.

[42:45] Weiß aber nicht genau, wofür das eigentlich da ist.

[42:47] Also macht man einfach irgendwelche Links da rein.

[42:49] Quellenverzeichnis, wo einfach fünf Links drin stehen.

[42:51] Ohne leere Erläuterung, ohne Autor, ja oder sonst irgendwas.

[42:55] Einfach nur die Adressen. Einfach nur URLs, ja.

[42:58] Ein Experte hat ins Quellenverzeichnis sogar die Website seiner IHK reingemacht.

[43:01] Keine Ahnung, was das soll. Ich weiß es nicht, ja.

[43:04] Aber wenn schon Quellenverzeichnis, dann bitte vernünftig und im Text referenzierte Quellen.

[43:09] Und nicht einfach nur, ach übrigens, für meine Doku habe ich folgende Bücher benutzt.

[43:13] Java ist auch eine Insel und das IT-Handbuch für Fachinformatiker.

[43:16] Geil, 3000 Seiten hat er für seine Doku benutzt. Hammer.

[43:19] Dann gucke ich jetzt mal nach, wo er denn wo seine Infos her hat.

[43:22] Das ist einfach Quatsch, ne.

[43:23] Also bitte, Quellennachweis.

[43:25] Wenn du nicht weißt, wofür der da ist, dann lass ihn bitte einfach weg, ja.

[43:30] Okay, letzter Punkt. Handwerkliche Fehler, habe ich es mal genannt.

[43:34] Das sind zwei Sachen, die mir aufgefallen sind in zwei Projekten.

[43:37] Das hat jetzt mit der Dokumentation per se nichts zu tun, sondern einfach fachlich im Projekt falsch umgesetzt.

[43:42] Da gab es dann zum Beispiel jemanden, der einfach Passwörter im Klartext in der Anwendung hinterlegt hat, also im Source-Code.

[43:47] Und Passwörter für die Anmeldung an seine Web-Anwendung sogar auch im Klartext übers Netz geschickt hat.

[43:53] Mensch, das geht doch nicht.

[43:54] Also bitte, ja, wer heutzutage Passwörter im Klartext übers Netz schickt, ja, der darf eigentlich nicht auf die Menschheit losgelassen werden.

[44:01] Der müsste eigentlich allein deswegen schon durchfallen.

[44:03] Ich bin ganz ehrlich, ja, sowas geht nicht.

[44:05] Wenn schon übers Netz wegschicken, dann bitte gehashed, am besten noch gesaltet, ich weiß nicht was, und bitte per HTTPS überschlüsselt übertragen.

[44:14] Und nicht einfach mit HTTP unverschlüsselte Benutzerpasswörter übers Netz schicken.

[44:18] Das geht doch nicht. Bitte.

[44:21] So, und dann kommen wir zum Thema MVC, Model-View-Controller.

[44:25] Sehr beliebtes Architekturpattern, finde ich auch völlig okay.

[44:29] Wenn man dann aber die Geschäftslogik in den Controller packt, dann hat man irgendwas nicht richtig verstanden.

[44:33] Die Geschäftslogik gehört nicht in den Controller und auch nicht in den View, die gehört ins Model.

[44:38] Denn der Sinn bei MVC ist, dass ich die einzelnen Komponenten austauschen kann.

[44:42] Und wenn ich den Controller rausnehme, in dem meine Geschäftslogik ist, was habe ich dann mit den anderen Komponenten noch?

[44:48] Da ist ja nichts mehr drin, das ist Quatsch.

[44:50] Also, bitte. Ich weiß, das kann man jetzt auch so und so interpretieren.

[44:53] Ich interpretiere das MVC jetzt mal, wie es klassisch gedacht war.

[44:56] FAT Model, da sind meine Daten drin und auch die dazugehörige Geschäftslogik.

[45:01] View ist die reine Anzeige und Controller ist ein ganz dummer Verdrahter, der einfach nur beides zusammenstöpselt.

[45:07] Das verstehe ich unter MVC.

[45:09] Das kann man auch anders interpretieren, es gibt auch nicht das FAT Model, es gibt auch FAT Controller oder sonst irgendwas.

[45:14] Aber die Geschäftslogik gehört bitte nicht in den Controller.

[45:17] Das ist einfach falsch und das möchte ich einfach nicht sehen.

[45:20] Und wenn man das macht, sollte man das auch besser gut begründen können.

[45:23] Und wir haben einen, der das gemacht hat, auch im Fachgespräch danach gefragt.

[45:26] Er konnte es nicht begründen. Ja, und dann gab es halt Punktabzug.

[45:29] Nee, so ist das dann.

[45:31] Okay, nächster Punkt. Projektpräsentation.

[45:33] Und keine Angst, jetzt wird es auch nicht mehr ganz so lang.

[45:35] So viele Punkte habe ich hier jetzt nicht.

[45:37] Projektpräsentation gehe ich jetzt einfach mal schnell durch, denn ich gucke mal auf die Uhr.

[45:40] Dreiviertelstunde haben wir schon voll.

[45:43] Okay, gehen wir mal ein bisschen schneller.

[45:44] Also Projektpräsi hat einen Experten, der hat was mit JavaScript gemacht.

[45:47] Völlig okay.

[45:48] Hat dann dementsprechend auch 57 verschiedene Frameworks eingesetzt.

[45:52] Hat die dann auch alle in seinen Folien gezeigt.

[45:54] Hat nur leider nicht die Namen drunter geschrieben, sondern einfach nur die Logos.

[45:57] Und die Logos von JavaScript Frameworks, die alle irgendwie, keine Ahnung, ich glaube der hat Vue.js benutzt.

[46:02] Und noch drei andere Frameworks, die irgendwas damit zu tun hatten.

[46:04] Die sahen alle sehr, sehr ähnlich aus.

[46:05] Also die Logos, ich konnte sie nicht auseinanderhalten.

[46:07] Ich hatte sie noch nie gesehen und kein Mensch, also wir haben alle im Ausschuss.

[46:10] Wir haben es alle nicht verstanden, was welches Framework macht, wenn man die Namen nicht daneben schreibt, sondern nur die Logos benutzt.

[46:15] Das ist wieder so ein Fall von, weiß doch jeder, was Vue.js ist und was es da sonst noch so für Frameworks gibt.

[46:22] Ich meine, hallo, das macht man doch den ganzen Tag als Entwickler.

[46:25] Nee, macht man nicht.

[46:26] Das machst du vielleicht den ganzen Tag.

[46:28] Aber alle anderen und insbesondere die Leute, die im Prüfungsausschuss sitzen, machen das nicht.

[46:33] Also bitte erklär uns das.

[46:34] Und schreib wenigstens die Namen der Frameworks daneben und zeig nicht nur völlig nichtssagende Logos.

[46:40] Ich meine Logos wie Oracle, wo Oracle drin steht.

[46:43] Okay, geschenkt.

[46:44] Aber ein Logo, wo einfach nur ein komisches, stilisiertes V in blau auf gelbem Hintergrund ist oder so, da kann kein Mensch was mit anfangen, wenn er das nicht kennt.

[46:52] Also bitte ausformulieren.

[46:53] Dann haben wir noch Experten gehabt, jetzt in der Doku und auch in der Präsentation habe ich es gesehen, wo einfach To-Dos noch im Code standen.

[47:00] Und Quelltext-Beispiele gezeigt wurden, wo noch dicke, fette To-Dos drin standen.

[47:03] Oder so eine gelbe unterstrichene Linie aus der IDI.

[47:06] So nach dem Motto, hier hättest du noch eine Variable dir sparen können oder so, war wirklich ein Screenshot aus der IDI aufgenommen, wo noch die Hinweise zur Optimierung des Codes quasi deutlich sichtbar standen.

[47:18] Und ich habe die ganze Zeit gedacht, wieso hat er das nicht heile gemacht?

[47:21] Warum hat er das nicht gefixt?

[47:23] Da werde ich völlig wahnsinnig bei sowas.

[47:25] Das muss man doch sehen.

[47:26] Rechtschreibfehler auf den Folien hatten wir auch.

[47:29] Wir hatten tatsächlich dieses Mal, ist mir extrem negativ aufgefallen, einige Präsentierende, die mega winzige Schrift benutzt haben.

[47:36] Ich dachte, das gäbe es gar nicht mehr, dass man nur noch Textfolien macht.

[47:39] Und dann auch noch wirklich mit echt winziger Schrift.

[47:41] Also vielleicht Schriftgröße 12 oder so.

[47:43] Das habe ich auch schon ewig nicht mehr gesehen, aber dieses Jahr gleich mehrfach wieder.

[47:47] Ganz schrecklich.

[47:48] Dann haben wir natürlich noch wild platzierte Grafiken gehabt.

[47:51] Teilweise Clip-Arts auf den Folien.

[47:53] Och, das geht gar nicht.

[47:55] Und dann haben diese Elemente aber auch noch den Text überlagert.

[47:58] Das ging auch überhaupt nicht.

[47:59] Also waren wirklich Punkte, die eingeblendet wurden.

[48:01] Da kam eine Grafik, die Grafik hat diese Punkte überlagert.

[48:03] Oh, ganz schrecklich.

[48:05] Dann klassischer Fehler, habe ich schon mehrfach erzählt.

[48:07] Das Unternehmen ewig lange vorgestellt mit 7000 Standorten.

[48:10] Und ach, wir sind so toll.

[48:11] Und hier kann man auch dies und das machen.

[48:12] Und da waren schon fünf Minuten rum, der Präsi.

[48:14] Das war jetzt übertrieben.

[48:15] Das waren meistens nur ein, zwei Minuten.

[48:17] Aber auch das ist viel zu lang.

[48:18] Ich sage es nochmal ganz deutlich.

[48:20] Keine Sau interessiert sich für dein Unternehmen.

[48:22] Du sollst deine Projektarbeit darstellen.

[48:24] Deine Leistung.

[48:25] Dazu gehört auch, dass du kurz vorstellst, wo du arbeitest und was das Unternehmen macht.

[48:29] Und vielleicht auch, in welchem Kontext dein Projekt umgesetzt wurde.

[48:32] Alles gut.

[48:33] Aber wir wollen nicht, ich sage mal, stundenlang hören, was ihr für tolle Produkte herstellt.

[48:38] Das ist keine Werbeveranstaltung.

[48:40] Du sollst deine Projektarbeit darstellen.

[48:42] Deine Prüfungsleistung.

[48:43] Andersherum geht das aber auch.

[48:45] Wir hatten auch einen Experten, der hat seinen Namen nicht genannt.

[48:48] Und den auch nirgendwo auf der Folie gehabt.

[48:51] Dann sitze ich da als jemand, der die Doku nicht gelesen hat.

[48:53] Und nicht auswendig weiß, wer um 13 Uhr an Tag X dran ist.

[48:56] Und konnte mir keine Notizen machen.

[48:58] Beziehungsweise den Namen nicht daneben schreiben.

[49:00] Das habe ich auch noch nie gesehen.

[49:02] Das war auch das einzige Mal, dass ich das jemals gesehen habe.

[49:04] Dass jemand nicht seinen Namen, wenigstens irgendwo auf der Folie hat.

[49:07] Und sich dann aber auch nicht vorstellt in der Präsentation.

[49:09] Also das geht gar nicht.

[49:11] Ich sage ja immer, man soll nicht mit etwas langweiligem starten.

[49:14] Völlig okay.

[49:15] Würde ich auch nicht machen.

[49:16] Ich würde mich auch nicht als erstes vorstellen.

[49:17] Ich mache immer einen coolen Einstieg.

[49:19] Nur wenn ich Leute quasi gecatcht habe.

[49:21] Und die mir zuhören.

[49:22] Dann stelle ich mich vor.

[49:23] Finde ich völlig okay.

[49:24] Aber dann stelle ich mich auch vor.

[49:26] Dann nenne ich meinen Namen.

[49:27] Und ich zeige meinen Namen auch auf der Folie.

[49:29] Denn es gibt auch Menschen, die nicht alle Vor- und Nachnamen dieser Welt vernünftig fehlerfrei schreiben können.

[49:34] Nur wenn sie sie hören.

[49:35] Es gibt ja auch viele Namen, die man eben nicht so schreibt, wie man sie hört.

[49:38] Von daher bitte den Namen irgendwo einmal zeigen.

[49:41] Das wäre schon ganz nett.

[49:42] Und dann zur Präsentation noch ein letztes Schmankerl.

[49:47] Da hatten wir dann eine Zeitplanung gesehen, die auch über mehrere Zeilen ging.

[49:50] Also im Prinzip so wirklich eine schön ausformulierte Tabelle.

[49:53] Und da hat der Prüfling dann wirklich jede Zeile einzeln vorgelesen.

[49:57] Also das klassische Beispiel, wie man es auf keinen Fall machen sollte.

[50:01] So was habe ich in der Präsi gesehen.

[50:02] Da habe ich auch gedacht, Mensch, das kann nicht wahr sein.

[50:04] Das habe ich so lange schon nicht mehr gesehen.

[50:06] Wo kommt das jetzt auf einmal her?

[50:07] Naja, nun.

[50:08] Also bitte diese Dinge nicht machen.

[50:10] Und dann kommen wir schnell zum Fachgespräch, weil wir nicht mehr so viel Zeit haben.

[50:14] Erster Hinweis.

[50:15] Fachgespräch.

[50:16] Wir hatten dieses Jahr wirklich sehr viele Prüflinge,

[50:18] die sich einfach mit GA1 die Note komplett versaut haben.

[50:22] Ich weiß nicht, wie viele Leute leider eine 4 wirklich in GA1 geschrieben haben

[50:27] und damit insgesamt sich eine 1 oder sogar 2 teilweise versaut haben.

[50:31] Das war extrem auffällig.

[50:32] Also irgendwas war da dieses Jahr los.

[50:34] Ganz, ganz schlechter Schnitt in GA1.

[50:35] Das tat uns auch sehr, sehr leid.

[50:37] Wir haben unser Bestes gegeben, bei einigen wirklich richtig guten Prüflingen,

[50:40] die noch irgendwie hochzuziehen.

[50:41] Aber das hat dann rein rechnerisch einfach auch nicht mehr klappen können.

[50:44] Also bitte achtet drauf.

[50:46] Deine Gesamtnote hängt auch von der schriftlichen Prüfung ab.

[50:49] Meistens muss ich dir nicht extra sagen.

[50:51] Aber dieses Jahr war es wirklich sehr extrem.

[50:53] Viele richtig, richtig gute Prüflinge haben echt eine mega schlechte GA1 gehabt

[50:57] und dadurch dann insgesamt sich die Note versaut.

[50:59] Das war echt mega schade.

[51:01] Das war so mein persönlicher Eindruck.

[51:03] Ja, ansonsten wieder die Klassiker wie eigentlich immer.

[51:05] Dazu habe ich auch schon viele Podcast-Episoden aufgenommen.

[51:07] Wirtschaftsfragen haben die meisten Leute komplett runtergerissen.

[51:11] Stundensatz, Gehaltsabrechnung brutto netto.

[51:14] Also wirklich die absoluten Basics.

[51:16] Einzelgemeinkosten kommt auch so oft dran.

[51:19] Und das müssen die Leute doch wissen.

[51:22] Spätestens bei der Stundensatzberechnung muss man doch Einzelgemeinkosten unterscheiden.

[51:25] Betriebsabrechnungsbogen, das Werkzeug, um die Gemeinkosten,

[51:28] Schlüssel zu ermitteln und die Gemeinkosten zu verteilen.

[51:31] So dieses ganze Konstrukt aus, wie komme ich zu einem Stundensatz

[51:34] und wie verteile ich meine Kosten in der Softwareentwicklung?

[51:36] Das war bei so vielen einfach überhaupt gar nicht vorhanden.

[51:39] Schon an den Grundsätzen brutto netto.

[51:42] Das ist so schade, weil damit kann man sich echt die Note versauen,

[51:45] wenn man solche Basics nicht kann.

[51:47] Und ich habe es schon so oft gesagt.

[51:49] Ich habe auch schon Podcast-Episoden dazu aufgenommen.

[51:51] Ich habe es eben schon erwähnt.

[51:53] Zieh du dir das bitte rein.

[51:55] Gerade Stundensatzberechnung.

[51:57] Das musst du einfach können. Punkt.

[51:59] Da gibt es auch keine Diskussion.

[52:01] Dann haben wir natürlich immer den Klassiker Source-Code geschrieben,

[52:03] den man nicht erklären kann.

[52:05] Ich nenne einfach mal nur ein paar Punkte,

[52:07] die ich im Nachgespräch dann gefragt habe,

[52:09] weil die im Code so in der Doku standen oder in der Präsi.

[52:11] Das heißt, die Leute haben das benutzt

[52:13] und konnten dann aber nicht erklären, was es ist.

[52:15] Und da waren dieses Mal auch schon ein paar coole Sachen dabei.

[52:17] Also zum Beispiel Nullable Types.

[52:19] Structs hat jemand benutzt.

[52:21] Lambda-Ausdrücke sind schon älter.

[52:23] Generics natürlich in fast jedem Code.

[52:25] Typ-Inferenz, sowas wie in C-Sharp,

[52:27] das ich überall wahr hinschreiben kann.

[52:29] Oder jetzt in Java 11 auch.

[52:31] In PHP hatten wir einen, der Traits benutzt hat.

[52:33] Wow, hatte ich vorher noch nie in einer Projektdokumentation.

[52:35] Aber leider konnte er es nicht erklären. Schade.

[52:37] Die eigene Typisierung der verwendeten Sprache

[52:39] wäre vielleicht ganz gut zu wissen.

[52:41] Wenn ich PHP einsetze, sollte ich wissen,

[52:43] wie typisiert ist die Sprache.

[52:45] Denn ansonsten kann ich das nächste Feature,

[52:47] was ich da benutzt habe, nämlich Type-Hints, nicht erklären.

[52:49] Und das konnten auch viele nicht.

[52:51] Das heißt, sie haben PHP benutzt,

[52:53] haben aber überall Typen vor die Parameter geschrieben.

[52:55] Da fragt man sich ja schon,

[52:57] ist PHP nicht dynamisch typisiert?

[52:59] Warum stehen da Typen drin?

[53:01] Ja, das ist ein Feature in PHP, Type-Hints.

[53:03] Das sollte ich dann aber auch erklären können,

[53:05] was es damit auf sich hat.

[53:07] Konnten viele nicht.

[53:09] Ansonsten noch so ein paar Syntax-Geschichten.

[53:11] In PHP, der Klassiker, oder in JavaScript auch.

[53:13] Gleich, gleich, gleich.

[53:15] Das heißt, der dreifache Gleichheitszeichen, Operator,

[53:17] um zusätzlich zum Inhalt auch noch den Typ

[53:19] von zwei Variablen zu vergleichen,

[53:21] oder zwei Werten.

[53:23] Dann haben wir gesehen, ich glaube,

[53:25] das heißt Null-Coalescing-Operator,

[53:27] das doppelte Fragezeichen.

[53:29] Damit kann man so einen Null-Check etwas abkürzen.

[53:31] Jemand konnte das Schlüsselwort

[53:33] Static nicht erklären.

[53:35] Da sind wir aber schon ganz unten an den Basics angekommen.

[53:37] Also wenn man das nicht erklären kann,

[53:39] dann weiß ich es auch nicht.

[53:41] Dann haben wir ein Try-Catch-Finally.

[53:43] Finally wurde leider nicht erklärt.

[53:45] Und dann haben wir C-Sharp-Code mit Out-Parameter.

[53:47] Das war auch so la-la erklärt.

[53:49] Also,

[53:51] das heißt, die Features der Sprache,

[53:53] die ich jeden Tag benutze, die sollte ich

[53:55] besser erklären können.

[53:57] Warum benutze ich sie sonst?

[53:59] Weil ich sie nicht verstehe. Das geht einfach nicht.

[54:01] Und ich habe jetzt hier mal ein paar Beispiele genannt

[54:03] von Dingen, die wir gesehen haben.

[54:05] Das bedeutet jetzt nicht, dass ich als

[54:07] Wald- und Wiesenentwickler die Traits in PHP

[54:09] erklären können muss.

[54:11] Wenn ich PHP nie gemacht habe, warum soll ich das erklären können?

[54:13] Das meine ich nicht.

[54:15] Wenn ich in meiner eigenen Dokumentation Code benutzt habe

[54:17] und den nicht erklären kann,

[54:19] dann bin ich am Arsch, auf Deutsch gesagt.

[54:21] Darum geht es.

[54:23] Man muss nicht alle Programmiersprachen kennen,

[54:25] aber die eigene, die sollte man besser kennen.

[54:27] Das gleiche Problem nicht nur beim Code, sondern auch bei den Architekturen.

[54:29] Alle benutzen ja MVC.

[54:31] Oder, sagen wir mal, ganz häufig.

[54:33] Auch wenn mir nichts anderes einfällt,

[54:35] nehme ich einfach MVC, weil das macht ja jeder.

[54:37] Wenn man dann nicht erklären kann, wofür es da ist,

[54:39] was die Vorteile sind, was der Controller macht

[54:41] und was das Model und was der View

[54:43] oder zum Beispiel seine Geschäftslogik in den Controller packt,

[54:45] so wie ich es vorhin gesagt habe,

[54:47] dann macht man irgendwie was falsch.

[54:49] Was auch ganz häufig dieses Jahr dran war,

[54:51] dependency injection.

[54:53] Konnte aber auch nicht vernünftig erklärt werden.

[54:55] Man konnte nicht so hochgefahren werden.

[54:57] Also die absoluten Basics,

[54:59] eine Abhängigkeit per Konstruktor in eine Klasse reinzugeben,

[55:01] dass das auch schon dependency injection ist

[55:03] und dafür braucht man nicht ein einziges Framework.

[55:05] Das war dann einfach nicht bekannt.

[55:07] Und dann hatten wir auch noch einen Kollegen,

[55:09] der domain-driven-design gefühlt

[55:11] dreimal in seiner Präsentation gesagt hat

[55:13] und dann leider aber auch im Fachgespräch

[55:15] nichts dazu sagen konnte.

[55:17] Das ist dann einfach selber schuld.

[55:19] Ich sage es immer wieder, alles, was man erwähnt

[55:21] oder geschrieben hat oder sonst irgendwas,

[55:23] das kann man nicht so einfach erklären.

[55:25] Da kommen wir auch zum nächsten Punkt.

[55:27] Ich glaube, ich hatte es mal in meiner LaTeX-Vorlage drin,

[55:29] auf der ersten Seite, einen Urheberrechtshinweis.

[55:31] Ich weiß gar nicht mehr, warum ich den da drin hatte.

[55:33] Der ist da irgendwie reingerutscht

[55:35] oder ich hatte den von irgendeiner anderen Vorlage drin.

[55:37] Auf jeden Fall ist der völlig sinnlos.

[55:39] In Deutschland muss ich nicht das Urheberrecht einfordern.

[55:41] Ich habe das einfach.

[55:43] Ich brauche keinen Urheberrechtshinweis.

[55:45] Wenn ich aber auf meiner Projektdokumentation

[55:47] vorne einen Satz schreibe, auf dem Deckblatt,

[55:49] dieses Werk ist urheberrechtlich geschützt,

[55:51] dann sollte ich auch besser erklären können,

[55:53] was es mit dem Urheberrecht auf sich hat.

[55:55] Und zwar aber auch in allen Details.

[55:57] Und vor allem sollte man auch wissen,

[55:59] dass das Urheberrecht nicht einfach übertragbar ist.

[56:01] Das kann mir niemand wegnehmen oder abkaufen.

[56:03] Und das endet auch nicht einfach so irgendwann,

[56:05] sondern 70 Jahre nach meinem Tod.

[56:09] Das sind Dinge, die sollte ich als Prüfling können.

[56:11] Und die haben, laut Auskunft der Lehrer

[56:13] in unserem Ausschuss, die Leute auch in der Schule so besprochen.

[56:17] Aber wenn man es dann in der Prüfung nicht sagen kann,

[56:19] gibt es Punktabzug.

[56:21] Das klassische Trippel aus Datenschutz,

[56:23] Datensicherung und Datensicherheit

[56:25] konnte auch sehr häufig nicht abgegrenzt werden.

[56:27] Gerade beim Datenschutz

[56:29] hatten wir dieses Jahr wieder viele Prüflinge,

[56:31] die das nicht erklären konnten.

[56:33] Schutz personenbezogener Daten.

[56:35] Und dann wird alles munter durcheinandergeworfen

[56:37] mit Backup-Verfahren

[56:39] und Zugriffsverfahren.

[56:41] Und ich weiß nicht was.

[56:43] Also diese drei Begriffe müssen einfach

[56:45] sauber voneinander abgegrenzt werden.

[56:47] Und da darf man auch nicht einfach alles durcheinander schmeißen.

[56:49] Und gerade in Zeiten der DSGVO

[56:51] sollte man erwarten,

[56:53] dass jeder Prüfling rauf und runter

[56:55] sich mit dem Datenschutz beschäftigt hat.

[56:57] Und auch mit den Betroffenenrechten.

[56:59] Was darf ich denn machen,

[57:01] wenn ein Unternehmen

[57:03] meine Daten verarbeitet?

[57:05] Was habe ich für Rechte als betroffene Person?

[57:07] Das haben wir mehrfach gefragt

[57:09] und viele Prüflinge wussten das nicht.

[57:11] Aber wirklich gar nicht.

[57:13] Und das geht heutzutage einfach nicht mehr.

[57:15] Datenschutz ist so wichtig.

[57:17] Genau wie die Datensicherheit.

[57:19] Wenn ich als Softwareentwickler heute

[57:21] Passwörter im Klartext übers Internet schicke

[57:23] oder personenbezogene Daten

[57:25] in eine riesen Datenbank packe,

[57:27] obwohl ich das eigentlich nicht darf,

[57:29] dann handel ich grob fahrlässig.

[57:31] Ich vergleiche das wirklich mit dem

[57:33] fehlenden Händewaschen bei den Ärzten.

[57:35] Das geht so nicht.

[57:37] Und so jemanden dürfen wir nicht

[57:39] als Programmierer auf die Welt loslassen.

[57:41] Ganz einfach.

[57:43] Ich habe mal einen Fehler in einer Dokumentation hingewiesen

[57:45] und die Antwort war

[57:47] Was? Habe ich das so geschrieben?

[57:49] Ach Mensch, das weiß ich gar nicht mehr.

[57:51] Das macht keinen guten Eindruck.

[57:53] Also wenn man eine Dokumentation geschrieben hat

[57:55] und darüber seine Prüfung hat

[57:57] und dann nicht mehr weiß, was man geschrieben hat,

[57:59] das geht nicht.

[58:01] Das hört sich erstmal an wie eine richtig bescheuerte Ausrede.

[58:03] So kam das erstmal rüber.

[58:05] Und selbst wenn es keine war,

[58:07] dann ist das eigentlich noch schlimmer.

[58:09] Wenn ich nicht mehr weiß, was ich da geschrieben habe.

[58:11] Das erzeugt einfach von mangelnder Vorbereitung.

[58:13] Okay, wir kratzen an der Stunde.

[58:15] Ich habe es mir schon gedacht,

[58:17] dass es heute länger dauern wird,

[58:19] aber jetzt ziehe ich das noch durch.

[58:21] Ich habe ja noch so ein paar Lichtblicke.

[58:23] Noch mal kurz zusammengefasst.

[58:25] Das hört sich ja an wie der mega fette Rant.

[58:27] Und das ist es auch.

[58:29] Ich habe natürlich jetzt ganz viele Sachen schlecht gemacht,

[58:31] weil die mich einfach tierisch nerven.

[58:33] Ich sage immer, Mensch, die blöden Prüflinge.

[58:35] Und ich reg mich auch drüber auf.

[58:37] Und ich finde das auch blöd.

[58:39] Wir nehmen die da runter und hauen das alles um die Ohren.

[58:41] So sind wir ja nicht.

[58:43] Wir wollen denen immer das Beste.

[58:45] Und wir versuchen auch immer,

[58:47] die beste Note für die Prüflinge zu erreichen.

[58:49] Und alles, was ich heute hier erwähnt habe,

[58:51] ist einfach was.

[58:53] Das nimmst du jetzt mit für deine Prüfung.

[58:55] Und machst das bitte nicht oder anders,

[58:57] damit du eine gute Note bekommst.

[58:59] Ich würde dir nie in der Prüfung sagen,

[59:01] was hast du denn da für eine Scheiße produziert.

[59:03] Oder Mensch, das ist doch völlig bekloppt,

[59:05] wie du das gemacht hast.

[59:07] Ich würde dir nicht sagen,

[59:09] dass andere Prüfer das genauso wenig machen.

[59:11] Ich überspitze das hier nur.

[59:13] Ich sage dir nur, wie es bei mir ankommt,

[59:15] damit du verstehst, was die Probleme damit sind.

[59:17] Und dass du hoffentlich entscheidest,

[59:19] es dann anders zu machen.

[59:21] Natürlich finde ich es auch total nervig.

[59:23] Deswegen rede ich ja auch so.

[59:25] Aber ich hoffe, dass ich es so verschärft formuliere.

[59:27] Dadurch kommt es auch ein bisschen besser bei dir an.

[59:29] Und du machst die Fehler dann halt nicht.

[59:31] Das jetzt zum Abschluss.

[59:33] Aber jetzt habe ich auch noch,

[59:35] um zu den Positiven zu enden,

[59:37] ein paar Lichtblicke aufgeschrieben.

[59:39] Was ich z.B. dieses Jahr zum ersten Mal gesehen habe.

[59:41] Oder was mir besonders aufgefallen ist.

[59:43] Was ich besonders gut fand.

[59:45] Fangen wir mal direkt mit dem ersten Punkt an.

[59:46] Ich habe in einer Doku jetzt mal gelesen, dass so Lasten- und Pflichtenheft, was eigentlich

[59:49] eher so Pflicht-Dinge sind, weil die ja in irgendeiner Vorlage stehen, und die dann einfach

[59:54] so, ne, Auszug aus, sehe ich einfach immer, und dann stehen da nur drei Sätze oder sowas,

[59:58] das war dann der Auszug, ja, also da kann man auch so viel Müll produzieren, das ist

[1:00:02] unglaublich.

[1:00:03] Aber auf jeden Fall habe ich dieses Jahr mal jemanden gehabt, der sein Lasten- und sein

[1:00:05] Pflichtenheft auch in Bezug zueinander gestellt hat, das fand ich richtig gut.

[1:00:08] Er hat ein Lastenheft aufgestellt, zusammen mit dem Fachbereich, und dann hat er ein Pflichtenheft

[1:00:12] erzeugt, was auf das Lastenheft verwiesen hat.

[1:00:14] Da stand zum Beispiel drin, Mensch, hier, dieser Punkt setzt folgende Anforderungen

[1:00:17] aus dem Lastenheft um.

[1:00:18] Und da wurde sogar teilweise was gegenübergestellt, so, das ist der Punkt aus dem Lastenheft,

[1:00:21] das ist der Punkt aus dem Pflichtenheft.

[1:00:22] Mensch, da konnte man wirklich sehen, das baut aufeinander auf, da hat sich jemand Gedanken

[1:00:25] gemacht, da hat jemand diese Artefakte auch wirklich benutzt für seine Projektarbeit,

[1:00:29] und nicht einfach nur hingerotzt, weil die in irgendeiner Vorlage stehen, ja.

[1:00:33] Das fand ich richtig gut, das hat mir richtig gut gefallen.

[1:00:35] Dann hatten wir jemanden, der seine Mock-Ups für seine Web-Oberfläche oder sowas mal

[1:00:39] per Hand gezeichnet hat, ne, schön auf so einem Blatt Papier, und da konnte man auch

[1:00:42] sehen, hier ein bisschen was wegradiert, da was dazugemalt, also da konnte man wirklich

[1:00:45] sehen, das war eine echte Arbeit, da hat sich jemand mit dem Fachbereich zusammen Gedanken

[1:00:49] gemacht, was aufgezeichnet, das fand ich richtig cool, das hat er eingescannt und in

[1:00:52] seinen anderen gepackt.

[1:00:53] Fand ich richtig toll, im Gegensatz zu, ich male das alles pixelperfekt, ja nicht, dafür

[1:00:57] sind die Tools ja nicht ausgelegt, aber mit irgendwelchen Tools am Computer, sondern er

[1:01:01] hat das wirklich mal offline gemacht, auf einem Blatt Papier, das hat auf mich persönlich

[1:01:05] einen tollen Eindruck gemacht, ich fand das richtig gut.

[1:01:06] Dann hatten wir jemanden, der hat mal nicht das Standard Lasten- und Pflichtenheft benutzt,

[1:01:10] obwohl er Scrum einsetzt, ja, das kommt dann ja auch noch meist dazu, ne, dann haben wir

[1:01:14] halt Experten, die Scrum machen, aber irgendwo lesen, dass Lasten- und Pflichtenheft ja auch

[1:01:18] wichtig ist, also mache ich einfach beides, so, das passt natürlich auch hinten und vorne

[1:01:21] nicht zusammen, ja.

[1:01:22] Aber jetzt hatten wir einfach mal einen, der hat es dann auch mal richtig gemacht, der

[1:01:25] hat dann gesagt, ich habe jetzt kein Lastenheft geschrieben, ähm, er hat es nicht geschrieben,

[1:01:28] sondern das wäre ja blöd, dann hätte er es ja wieder aus irgendeiner Vorlage, sondern

[1:01:31] er hat gesagt, Mensch, bei uns werden die Anforderungen in Tickets erfasst, der Fachbereich

[1:01:34] macht Tickets auf, da steht drin, was sie fachlich haben wollen, so, zack, und hat da

[1:01:37] einfach statt eines Lastenheftes Screenshots von diesen Tickets gemacht, so, und die waren

[1:01:41] auch gut ausformuliert, da hat jemand drüber geguckt, die waren priorisiert und so weiter

[1:01:44] und so fort, das war eine tolle Geschichte, das war eine realistische und nachvollziehbare

[1:01:48] Dokumentation der Anforderungen, das fand ich richtig gut, ja, anstatt sich also ein

[1:01:52] Lastenheft auszudenken, weil das in den meisten Unternehmen doch sowieso gar nicht geschrieben

[1:01:56] wird, sind wir doch mal ganz ehrlich, ja, warum denn nicht einfach mal das darstellen,

[1:01:59] wie es wirklich läuft?

[1:02:00] Warum denn nicht einfach mal die Tickets zeigen?

[1:02:01] Völlig okay, die Anforderung, die Anforderungen vernünftig aufzunehmen, ist doch damit super

[1:02:07] umgesetzt.

[1:02:08] Also, warum nicht machen?

[1:02:09] Hat mir richtig gut gefallen.

[1:02:10] Dann hatten wir noch in der Präsentation jemanden, der hat eine Web-Anwendung gebaut

[1:02:14] und hat seine Präsentation dann so aufgebaut, dass sie aussah wie Browser-Tabs, das heißt,

[1:02:18] wenn du ganz viele Browser-Tabs auffasst, dann weißt du das vielleicht, irgendwann

[1:02:20] zeigt der Browser die nicht mehr an, dann steht dann rechts oben sowas wie plus zwölf,

[1:02:24] weil noch irgendwie zwölf andere Tabs auf sind oder so, ja, die man nicht mehr sehen

[1:02:26] kann.

[1:02:27] So, und so hat er seine Präsi auch aufgebaut, da hieß dann der erste Tab sowas wie Einleitung,

[1:02:30] der zweite Tab hieß dann irgendwie Analysephase und sonst irgendwas und daneben stand dann

[1:02:34] irgendwie plus sechs, sondern beim nächsten Klick war dann irgendwie die nächste Phase

[1:02:37] und da stand dann nur noch plus fünf, dann wusste man, aha, okay, es wird jetzt weniger,

[1:02:41] es geht jetzt weiter und diese Analogie aus dem Web hat er übertragen auf seine Präsentation,

[1:02:45] fand ich richtig cool.

[1:02:46] Ja, das war sehr schlicht gestaltet, das hätte man noch ein bisschen netter machen

[1:02:48] können, aber von der Idee her, coole Sache, ja, er hat eine Web-Anwendung gebaut und seine

[1:02:53] Präsi ist so aufgebaut wie ein Browser, also ich fand das richtig cool, hat mir Spaß

[1:02:57] gemacht.

[1:02:58] So, dann haben wir noch einen in der Präsi auch gehabt, der einfach mal sein Mockup und

[1:03:03] die fertige Web-Anwendung gegenübergestellt hat und gezeigt hat, wie sich das entwickelt

[1:03:06] hat.

[1:03:07] Da konnte man dann sehen, Mensch, hier ist noch was verändert worden, aber bei einigen

[1:03:10] auch, Mensch, das ist exakt so umgesetzt worden, also richtig, so war es geplant, so sieht

[1:03:14] es jetzt aus.

[1:03:15] Also wirklich ein schöner Soll-Ist-Vergleich an einer echten Oberfläche, das fand ich

[1:03:20] auch richtig, richtig gut, habe ich so auch noch nicht gesehen, hat mir auch sehr gut

[1:03:23] gefallen.

[1:03:24] Dann hatten wir dieses Jahr auch häufig Leute, die zum Beispiel die Entscheidung für ein

[1:03:28] Vorgehensmodell vernünftig begründet haben, sowas wie Wasserfallmodelle.

[1:03:32] Früher war es ja immer, ja, ich mache Wasserfall, was anderes kenne ich nicht und heutzutage

[1:03:35] wird das auch mal vernünftig begründet, was ja auch in Ordnung ist, in Zeiten von

[1:03:38] Scrum und Agile und ich weiß nicht was, muss man ja auch vielleicht mal begründen, eben

[1:03:41] diesen Kram nicht zu machen, sondern vielleicht ein ganz klassisches Wasserfallmodell einzusetzen.

[1:03:45] Und wenn das vernünftig begründet ist, keine Ahnung, es gibt gesetzliche Anforderungen,

[1:03:49] die sind genau definiert, davon wird nicht abgewichen, die habe ich in einem Anforderungskatalog

[1:03:53] hier schon vorliegen, zum Beispiel, ja, dann brauche ich nicht ein künstliches Agile oben

[1:03:57] draufsetzen, was überhaupt nicht passt, sondern dann mache ich einfach ein Wasserfallmodell.

[1:04:00] Und wenn ich das dann auch noch vernünftig begründe, dann habe ich alles richtig gemacht.

[1:04:04] Also das fand ich richtig gut.

[1:04:05] Jo, dann hatten wir noch einen, der hat auch so ein bisschen an den Prüfungsausschuss gedacht

[1:04:10] und hat dann versucht, so ein bisschen auch zu individualisieren und uns so ein bisschen

[1:04:14] mit einzubeziehen.

[1:04:15] Das war jetzt nur eine Kleinigkeit, aber er hat zum Beispiel dann in so einer Adresse,

[1:04:18] die da zu sehen war, ich glaube, der musste so Adressaufkleber oder sowas war das, glaube

[1:04:22] ich, musste er drucken und da hat er einfach die Adresse der Berufsschule genommen, in

[1:04:25] der wir geprüft haben.

[1:04:26] Das war nur eine Kleinigkeit, aber das zeigt, Mensch, der Präsentator hat sich ein bisschen

[1:04:30] Gedanken gemacht.

[1:04:31] Er hat nicht einfach seine eigene Adresse genommen oder die seiner Firma, sondern hat

[1:04:35] einfach die der Berufsschule genommen, in der wir da gerade sitzen.

[1:04:39] Das heißt, er hat versucht, irgendwie eine Brücke zum Prüfungsausschuss zu schlagen

[1:04:42] und das hat mir persönlich sehr schön gefallen.

[1:04:44] Also ein bisschen Gedanken gemacht einfach, wie kriege ich die Prüfer irgendwie mit angesprochen?

[1:04:49] Das hat mir einfach sehr gut gefallen.

[1:04:52] Und dann hatten wir auch zum ersten Mal jemanden, der seine Amortisationsrechnung im Nachhinein

[1:04:57] nochmal validiert hat.

[1:04:59] Der hat zum Beispiel in seiner Amortisationsrechnung gesagt, Mensch, ich gehe davon aus, wir haben

[1:05:02] eine Zeitersparnung von x Minuten im Monat, mit meiner neuen Software wird alles besser,

[1:05:06] wie es ja immer so ist.

[1:05:07] Aber anstatt das dann einfach dahin zu stellen, zu sagen, ja, amortisiert sich in fünf Jahren,

[1:05:11] hat er dann ganz am Ende, nachdem das Projekt umgesetzt wurde und die Anwender wirklich

[1:05:14] mit der Anwendung auch gearbeitet haben, das nochmal validiert.

[1:05:17] Das heißt, er hat sich dann wirklich mal hingestellt und geguckt, wie lange brauchen

[1:05:19] die denn jetzt?

[1:05:21] Und dann konnte er wirklich im Nachhinein nochmal seine angenommenen Zahlen mit den

[1:05:24] tatsächlichen Zahlen, die am Ende rauskamen, abgleichen und dann zeigen, Mensch, das hat

[1:05:28] ja wirklich funktioniert.

[1:05:29] Das wird ja wirklich schneller und die Amortisation ist sogar ein bisschen schneller oder wird

[1:05:33] schneller eintreten als geplant, weil die sogar noch einen Ticken schneller jetzt arbeiten

[1:05:37] können.

[1:05:38] Das fand ich richtig, richtig gut.

[1:05:39] Das war nicht einfach nur Amortisation, ich denke mir irgendwelche Zahlen aus und lalalala,

[1:05:43] weil die meisten können es dann ja auch nicht erklären.

[1:05:44] Wie kommen Sie darauf, dass Sie drei Minuten einsparen?

[1:05:46] Ja, Schätzwerte vom Fachbereich.

[1:05:48] So, völlig Banane.

[1:05:50] Und der hat jetzt einfach mal sich die Mühe gemacht und das am Ende nochmal verifiziert.

[1:05:54] Also einen schönen Soll-Ist-Vergleich gemacht.

[1:05:56] Ich habe gesagt, ich spare drei Minuten ein und jetzt kontrolliere ich das auch, ob das

[1:06:00] wirklich eingetreten ist.

[1:06:02] Das fand ich richtig gut, hat bei uns allen einen super Eindruck gemacht.

[1:06:06] So, das waren jetzt meine Highlights der Sommerprüfung.

[1:06:09] Ich habe viele andere Sachen gar nicht erzählt.

[1:06:13] Wir hatten auch viele gute Prüflinge, die auch top Gespräche gemacht haben, super Präsis.

[1:06:16] Wir hatten auch schlechte Präsis.

[1:06:18] Wir haben auch jemanden durchfeiern lassen.

[1:06:19] Also es war völlig gemischt, wie jedes Jahr.

[1:06:22] Es gibt nicht nur schlecht und nur gut.

[1:06:24] Es ist immer eine, wie ein Kollege sagt immer, die schöne gaussische Glockenkurve.

[1:06:29] Es gibt viele in der Mitte und einige schlechte links und einige gute rechts daneben.

[1:06:33] Das ist einfach so.

[1:06:34] Und wie gesagt, ich will nicht alle Prüflinge runter machen oder irgendwen hier persönlich

[1:06:38] angreifen oder sonst irgendwas.

[1:06:39] Mein Ziel ist, dass du für deine Prüfung Sachen besser machst.

[1:06:43] Und deswegen habe ich heute einen ganzen Haufen gezeigt, der einfach gar nicht geht und am

[1:06:47] Ende noch ein paar Sachen, die mir richtig positiv aufgefallen sind.

[1:06:49] Und ich fände es natürlich super, wenn du in deiner Prüfung irgendwas machst, was auch

[1:06:52] positiv auffällt.

[1:06:54] Und vielleicht machst du dir einfach mal ein paar Gedanken, wie das klappen könnte.

[1:06:58] Einfach mal deine kleine Welt verlassen und überlegen, wie kann ich denn dem Prüfungsausschuss

[1:07:03] irgendwie was Gutes tun?

[1:07:04] Weil wenn es auch nur so was ist, wie diese Adresse da einblenden, die ich jetzt gerade

[1:07:08] gesagt habe, um einfach zu zeigen, Mensch, die Person hat sich ein bisschen Gedanken

[1:07:12] gemacht, denn die Prüfer sind auch nur Menschen.

[1:07:15] Wir sitzen da, hören uns den ganzen Tag.

[1:07:17] Also ich hätte jetzt dieses Jahr vier Tage haben wir getagt.

[1:07:20] Ich war nur bei zweieinhalb dabei, aber acht Stunden sitzen wir da und hören uns immer

[1:07:24] den gleichen Senf an.

[1:07:26] Ich übertreibe das mal, aber so ist es meistens.

[1:07:28] Und da musst du dir einfach mit ein paar Kleinigkeiten vielleicht die Prüfer mal auf deine Seite

[1:07:32] holen und dann klappt das auch super.

[1:07:34] Ja, okay.

[1:07:36] Ja, so, ich habe die Stunde heute gerissen.

[1:07:38] Das wollte ich eigentlich gar nicht, aber ich muss das jetzt mal loswerden.

[1:07:41] Ich hoffe, es hat dir ein bisschen weitergeholfen.

[1:07:43] Ich hoffe, du hast einiges mitgenommen, was du nicht mehr machst und einige Anregungen,

[1:07:48] wie du es vielleicht ein bisschen besser machen kannst.

[1:07:49] Wenn du gerade Prüfungen hattest oder sie noch vor der Tür steht und du hast noch Fragen

[1:07:53] oder Anregungen oder lustige Anekdoten oder was auch immer, vielleicht bist du ja selber

[1:07:57] Prüfer und willst noch was beisteuern.

[1:07:58] Ich freue mich, wenn du das machst.

[1:08:00] In den Shownotes zur Episode kannst du natürlich deine Kommentare hinterlassen.

[1:08:04] Die findest du wie immer unter anwendungsentwicklerpodcast.de slash 139, denn das hier heute war die 139.

[1:08:13] Ich würde mich über deinen Feedback auf jeden Fall sehr freuen und höre jetzt mal

[1:08:16] auf zu sabbeln und sage vielen Dank fürs Zuhören und bis zum nächsten Mal.

[1:08:20] Tschüss!