Nachdem ich mich immer wieder mal grün und blau (und nicht blau weil ich beim THW tätig bin) über diversen Software-Design-Schwachsinn ärgere, habe ich mich entschlossen in loser Folge immer einmal wieder eine schlechte Art der Programmierung / Modellierung und natürlich auch Wege wie man es besser machen kann vorzustellen.

Für heute will ich erst einmal mit einigen Grundlagen beginnen, die sicherlich nicht nur für die Programmierung und Software-Entwicklung hilfreich sind, sondern für jeden der ein Projekt in irgendeiner Form betreut.

Ad 1) Klar festlegen was ich eigentlich will – jeder hat es sicherlich schon mal erlebt: „So hab ich mir das aber nicht gedacht gehabt …“ Die Ursache ist meist leicht gefunden: Es mangelt an klarer und eindeutiger Vorgabe – da gehört hinein was man will, aber auch was man gerade nicht will. Es ist sicherlich nicht immer leicht alles möglichst eindeutig und klar zu beschreiben, aber alleine wenn man sich darum bemüht ist schon eine große Menge Missverständnissse aus dem Weg geschafft

Ad 2) Klare Definitionen und einheitliches Vokabular: Jeder Mensch ist einzigartig, mit all seinen Vorlieben, Stärken, Schwächen und Erfahrungen. All diese Einflüsse prägen uns und haben eine Auswirkung auf die Rezeption und Reaktion gegenüber unserer Umwelt. Daher ist es keineswegs selbstverständlich das jeder unter einen Begriff anfänglich genau das gleiche versteht und ihn genauso abgrenzt wie ein anderer Mitarbeiter. Daher klar festlegen was unter einem bestimmten Begriff zu verstehen ist, und was nicht – es mag lästig erscheinen jede Entität und deren Bedeutung im Prozess-Zusammenhang einmal ausführlich zu beleuchten und zu beschreiben, aber es macht im weiteren Verlauf das Leben deutlich leichter. Wichtig ist hierbei: Jeder muss das Vokabular auch entsprechend anwenden, was abgestimmt wurde ist fest, ein „aber ich hab doch eigentlich 0815 anstelle 4711 gemeint“ ist ein absolutes no-go

Ad 3) Kenne deine Werkzeuge: Nicht jeder in einem Projekt muss mit jedem Werkzeug umgehen können – eine Führungskraft muss nicht zwingend mit einem Code-Editor und Compiler hantieren (es schadet nichts wenn sie sich dennoch einmal damit auseinander setzt), aber das tagtägliche Handwerkszeug mit den Routine-Funktionen muss nahezu blind bedienbar sein. Dazu muss auch klar sein: Für welchen Zweck welches Werkzeug? (Das kann von Projekt zu Projekt ein wenig schwanken, auch hier hilft es ggf. niederzulegen welche Mittel zur Verfügung stehen und für welchen Zweck benutzt werden sollen). Wichtig ist gerade in der Software-Entwicklung der sichere Umgang mit der persönlichen Entwicklungsumgebung (da kann jeder Entwickler verwenden was er für richtig hält, es sei denn es gibt zwingende Vorgaben. Gerade im Code ist es aber egal ob jemand eine vollwertige IDE wie Netbeans, KDevelop, Eclipse verwendet oder doch lieber einen schlichten Text-Editor mit ein wenig Syntax-Highlighting. Ebenso gehört der Umgang mit Team-Werkzeugen wie e-mail, Versionskontrolle, Bugtracker, Requirement-Management etc. zum Routine-Werkzeug. Hier muss ggf. geübt werden, aber nach einer gewissen Zeit darf es kein Bremsklotz mehr sein. Für die Arbeit am Rechner empfiehlt sich auch ein flüssiges Tippen und Arbeiten mit reduziertem Mauseinsatz (Shortcuts).

Ganz wichtig: Die ganzen Punkte da oben gelten für alle im Projekt, Neueinsteiger oder auch weitere Führungsebenen muss man da etwas heranführen und klar kommunizieren wie der Hase läuft. Absolut hinderlich ist es, wenn Leute die sehr viel an einem Projekt mitwirken diese einfachen Regeln nicht gebacken bekommen. Das geht auf die Nerven und somit auf die Performance des restlichen Teams.

So weit mal für den Anfang, wie geschrieben: in loser Folge kommen weitere Grausamkeiten der Software-Entwicklung (alles leider Dinge die man immer wieder erlebt, auch das oben ist keineswegs aus den Fingern gesaugt).