Zwei Gründe, der erste ist menschlich:
1.) Ihr braucht nicht nur einen (viele) guten Softwareingenieur(e), ihr braucht einen Softwareingenieur der Leute führen kann und predigen kann. Einer der Angst und Buße in die Herzen der Entwickler schürt und einen der sich unbeliebt macht und unbeliebt machen will. Egal wie man Software strukturiert, es muss eine Struktur geben und damit eine klare Meinung.
Da ihr noch keinen in der Firma habt denken wir uns jetzt das so ein Typ in die Firma kommt. Was hat der zu tun? Er muss sich die Software anschauen, rausfinden was ihr könnt, rausfinden wie es zu sein hat, einen Entwicklungsplan aufstellen, euch sagen wie ihr das machen sollt und alle die vielen Fehler finden und auslöschen. Erstmal macht er sich zwingend unbeliebt. Er wird euch Arbeit machen, er wird alle (naja, alle findet man eh net sagen wir 50 % (was schon viel wäre)) eure Fehler suchen und euch vor Augen halten, er wird ein schlechtes Licht auf viele Mitarbeiter werfen und kann damit die Moral des Teams zerstören.
Anforderungen an den Entwicklungsleiter
Gleichzeitig muss dieser Typ aber das Vorbild und der Leithahn in der Entwicklung sein. Der wird keine Zeit haben selber zu coden, daher muss er zwingend auf das Team angewiesen sein. Wie bekommt man das unter einen Hut? Indem man dem Chef und Personalmanager verbietet sich mit dem Typen zu unterhalten. Alle die Fehler die er findet müssen geheim bleiben, sonst verreckt euch die Moral. Gleichzeitig muss das Team super offen zu dem Entwickler sein. Der muss sozusagen die Stellung eines katholischen Priesters (ich rede vom Beichtstuhl, nicht von den schmudellstories) einnehmen. Das ist nebenbei die wichtigste Regel von komplexer Softwareentwicklung, "die Schranken der Entwicklung sind stets durch die Firmenkultur geben".
Gleichzeitig muss der Typ Respekt und Leitstellung halten. Und sind wir ehrlich, wie viele Informatiker sind Respektspersonen. Der zweite Grund ist theoretischer Natur. Es gibt in der Softwareentwicklung sehr langweilige, oft widersprüchliche Regeln die besagen wie Software sich zu verhalten hat. Das ganze liegt immer dadurch begründet welches Paradigma und welche Sprache man nutzt. Aber im wesentlichen sind das solche Regeln wie das "Liskovsche Substitutionsprinzip" oder das "Prinzip der Offen- und Verschlossenheit". All diese Regeln sollten von dem Informatiker der den Stoff mit der Muttermilch aufgenommen hat bereits instinktiv eingehalten worden sein. Es gibt meisten einen im Team der sich darum kümmert das die eingehalten werden aber die meisten Regeln werden instinktiv eingehalten. Wenn diese nicht ist, so gibt es in einer größeren Software oft keine direkte Transformation um Software A direkt in gute Software B zu verwursten.
Krisenmanagement in der Software-Entwicklung
Daher braucht es Erfahrung und Intuition um das Problem schrittweise in die richtige Richtung zu bringen. Zu diesem Zeitpunkten wird das System nicht laufen oder schlechter laufen. Also habt ihr dadurch noch ein Problem an der Backe. Ihr müsst dem Kunden erklären warum die nächsten Monate kein Fortschritt kommt und ihr müsst euch beim zweiten Mal nicht wieder verrennen. Folgende Lösungen biete ich an:
1.) Ihr stellt jemanden an der das kann und sich unbeliebt machen will, das ist teuer und nicht immer gut aber kann helfen. Hier wäre ein Freischaffender vielleicht ganz nützlich. Denk dran, ihr macht den Depp den Ihr einstellt zu eurem Steuermann, das ist viel Verantwortung und gefährlich.
2.) Ihr bringt euch den Scheiß selber bei, das kann dauern (viel Zeit) und ist sehr schwer. Ich kann euch kein Buch dafür empfehlen, das kann keiner denn es es kein Buch gibt das alles enthält. Vielmehr müsst ihr schauen das ihr euch klar werdet welche Schranken euch aufgezwungen sind d.h. welche Programmiersprache ist fest, wie sieht das System aus, was kann der Kunde etc. Versucht unbedingt rauszuknobeln welches Paradigma für euch richtig ist, das bestimmt eure Sprache und Umgebung.
Hierzu keine Buchempfehlung da ich nicht weiß was du kannst und wo ihr arbeitet. Google ist dein Freund und damit meine ich Google mal 3-4 h alle möglichen Sprachen ab die in deiner Nische verwendet werden. Dann (und erst dann) sucht ihr euch Bücher oder Tutorials die zu euch passen und folgende Themen beinhalten. (Wenn du im Team bist sollte jeweils eine Person einen der Punkte können):
- Software Construction, Patterns und Gesetze eures Paradigmas. Kann sein das der Typ mehr als ein Buch lesen muss. -Software Testen (wenn nötig auch Hardware)
- Datenbanken (wenn notwendig) -Distribution/Versionirung (wenn notwendig) -Tiefgreifendes Buch über eure Sprache
- Tiefgreifendes Buch über eure Hardware (wenn notwendig), das kann entweder Admin zeug für Server oder Hardware Kram für Hardware sein Wichtig ist das ihr den Scheiß nicht nur lest sonder dabei codet. So kleine Beispiele damit man es lernt.
Software-Entwicklung - Von der Konkurrenz lernen
In der Zwischenzeit nehmt Ihr euch einen aus dem Team der schaut wie die Konkurrenz das macht. Schaut sich Open Source Projekte an. Alles große was nach Qualität stinkt. Das ist die wichtigste und schlimmste Aufgabe. Gut, ihr solltet jetzt 5-7 Experten haben. Jetzt geht's ans wesentliche. Ihr:
- Startet von vorne. Klingt scheiße, könnte die ökonomisch richtige Entscheidung sein.
- Baut den alten Scheiß um. Ich weiß das ihr das eh machen werdet, aber tut mir den gefallen und versucht so viel wie möglich zu testen wenn ihr das macht. In beiden Fällen denkt ihr euch ne gute neue Struktur aus. Hier ist wichtig das diese:
- Die der Konkurrenz ähnlich ist wenn und nur wenn die Konkurrenz guten Code hat und die gleichen Paradigmen nutzt -Die Regeln eures Paradigmas hält
- Skaliert d.h. auch im großen funktioniert
- Testbar ist / ständig getestet wird -Mit der Hardware realisierbar ist -Keine komischen Kompromisse oder Sonderlösungen hält, alles sollte klar und einfach erscheinen.
Gemacht? Ja?
Gut dann kritisiert das Ding. So richtig. Nutzt richtig Zeit um euer Luftschloss zu zerlegen. Baut an dem Ding herum bis es nach allen Regeln der Kunst passt. Erst dann geht dazu über die Räume des Luftschloss mit den alten Codeteilen zu füllen. Wichtig ist das ihr jeden Raum den Ihr füllt testet.
Keine Kommentare:
Kommentar veröffentlichen