Code Design ist ein schwieriges Unterfangen. Entscheidungen müssen früh gefällt werden um dem Entwickler Team einen Standard an die Hand zu geben, der es ermöglicht eine Software zu generieren, die auch nach langer Entwicklungszeit wartbar und testbar bleibt. Soll die Software monolithisch aufgebaut werden oder soll man die Komponenten doch lieber dezentral über eine Pipeline ihre Jobs abarbeiten lassen. Es gibt viele Möglichkeiten und grundsätzlich kann man sich sicher sein, dass man zu irgendeinem Zeitpunkt merkt, dass man Fehler gemacht hat und umdenken muss.
Was aber klappt nie? Demokratie…
Hinter einem guten und flexiblen Softwaredesign steht ein Diktator. Jemand der Ahnung vom Werk hat und beim Design ganz klar ansagt, wie die Software zu gestalten ist. Open Source ist eine super Sache und ich plädiere dafür, so viel wie möglich der Community zur Verfügung zu stellen. Ich würde aber niemals behaupten, dass man in der Open Source Gemeinde eine Software findet, die ein sauberes und elegantes Design besitzt. Beispiel? WordPress! Eine Blogsoftware, die so weit verbreitet ist und auf die ich hier selber setze. Aber möchte ich ein Plugin für WordPress schreiben? Um Himmels Willen, Nein! Das Konzept von Hooks und Plugins ist so verwoben, dass man teilweise einen Knoten im Kopf bekommt, wenn man mal einen Blick unter die Haube wagt.
Also, wenn ihr die Verantwortung für ein Softwareprojekt übernehmt und eine klare Vorstellung von der Software habt, dann lasst euch nicht rein reden. Lasst euch vorher beraten, holt euch Ideen von anderen, aber während der Entwicklung gebt klare Richtlinien und lasst niemanden ausbrechen. Denkt daran, Entwickler sind Schweine, die machen das Code stinkt! Euer Software Design ist dabei wie ein großer Besen, der von selber sauber macht…
Zieht die Linie früh und lasst sie niemanden überschreiten!
Es ist zeitweise schwer gute Entwickler zu finden. Meiner Erfahrung nach lassen sich Juniors in Kombination mit ein oder zwei Seniors in ein Team am besten integrieren. Juniors sind zu Anfang erst einmal sehr pflegeintensiv, aber sie zeigen doch die stärkste Lernkurve. Auch die Kreativität kann hier durchaus mannigfaltiger sein als bei einem Senior, der meistens seine festgelegten Trampelpfade nimmt. Was der Bauer nicht kennt, das coded er nicht…
Schwierig wird es jedoch, wenn ab einem bestimmten Level der Wissensstand nicht mehr zunehmen möchte. Häufig stand ich vor dieser Situation und musste zusehen, wie ich dem Team neue Kenntnisse beibringe. Häufig stand ich als Lehrer vor ihnen und zeigte ihnen neue Sachen in der Hoffnung, dass auch sie zu einem späteren Zeitpunkt auf Dinge stoßen, die sie gerne präsentieren würden. Fehlanzeige, null Feedback, keine Reaktion, Nullkurve. Die Begeisterung wollte einfach nicht überspringen. Und so blieben die Juniors bei ihren vertrauten Themen und begaben sich selten auf neue Wege in unbekannte Regionen. Doch gerade das ist es, wo die größten Lerneffekte aufkommen, wo neue Ideen entstehen und neue Inspiration gefunden wird. Woran kann das liegen? Meiner Meinung nach liegt dies an einer häufigen Auslastung von 100% und keinen Pufferzeiten. Wann soll man mal die Möglichkeit haben abzuschweifen, einfach mal rumprobieren? Meistens ist der Zeitplan so knapp, das der Junior an den Lippen des Seniors hängt und um Anweisungen bittet, die er dann auch befolgt. Aber was ist den mit der Möglichkeit mal Fehler zu machen? Wozu sind QA, UnitTestcases und Staging Systeme da?
Also geht raus und macht Fehler und denkt ruhig auch erstmal 60 Sekunden über ein Problem selber nach, bevor ihr zu StackOverflow geht
Ich habe vor ein paar Tagen bereits davon geschrieben, dass wir bei uns in der Firma einen Funktion “den Springer” eingeführt haben. Dieser sollte sich darum kümmern, dass andere Teammitglieder vollständig Störungsfrei arbeiten konnten. Schnell zeigten sich die Stärken und Schwächen des Prinzips
Die Schwächen:
Allen vorran gibt es hier Probleme mit Leuten, die ihre Aufgaben grundsätzlich als unberechenbar hoch priorisiert sehen. Diese sehen die Funktion des Springers als lästige Instanz, die doch nur eingeführt wurde um die für technische versierte Leute “dummen” Fragen zu filtern. Also gehen sie direkt zu den Personen, die sie als richtige Ansprechperson sehen und sprechen ihre Aufgabe/Problem durch. Da es sich hierbei meist um einen Vorgesetzten handelt, zögern viele mit der eigentlich korrekten Antwort: “Bitte wende dich an den Springer”. Hier ist der Teamleiter gefragt, der seinen Leuten regelmässig klar machen muss, dass ein “Nein” durchaus auch gefordert ist.
Die Stärken:
Ein unübertreffbarer Vorteil ist die Wissensverteilung der Software über das gesamte Team. Nie zuvor haben sie so viele Bereiche des Systems kennen lernen und sich aus ihrer Wohlfühlecke entfernen müssen als in der Funktion des Springers. Innerhalb von wenigen Wochen wussten viele deutlich mehr von der Software. Dieser Umstand wirkte sich auch Abseits der Springertätigkeiten ebenfalls positiv aus. Es wurden weniger Fragen in die Runde gestellt, man fühlte sich einfach sicherer im Umgang mit der bestehenden Code.
Alle anderen Dinge sind teilweise vom Team abhängig, dass mit der IT zusammen arbeiten darf. Macht hier eure eigenen Erfahrungen
Ich habe bei uns in der Firma ein Institut eingeführt, dass dafür sorgen soll, dass die anderen Entwickler Unterbrechungsfrei arbeiten können. Ich präsentiere euch: Den Springer
Ein Springer (auch “der Springer”) ist eine Person, die sich um Aufgaben kümmert, dessen Arbeitsaufwand unter 1 Stunde liegt und akut dringend ist. Der Springer wird dabei meist aus dem Team durch ein visuelles Merkmal erkennbar und wechselt in einem festgelegtem Turnus innerhalb des IT Teams
Wir haben im Team gemerkt, dass unsere Arbeit immer wieder unterbrochen wurde. Anfragen für Statistiken, Auswertungen von Logdateien, Fehlersuche, kleine Hilfestellungen. In der Regel stand dann jemand bei der IT im Türrahmen, guckte erstmal mit großen Kuhaugen umher, bis jemand aus der IT Mitleid bekommen hat und fragt, was den sei. Diese Person war dann auch zumeist das arme Schwein, dass die Aufgabe erledigen musste. Manchmal wurde je nach Aufgabenbereich aber auch weiterdeligiert und es wurden gleich zwei Personen unterbrochen.
Was ist jetzt anders? Der Springer ist deutlich erkennbar, z.B. durch eine Leuchtweste, die jeder im Auto haben sollte. Somit weiß jeder ausserhalb der IT, wenn er ansprechen muss, wenn er im Tührramen steht. Die Situation wurde also bereits für beide Parteien entspannt. Der Springer nimmt die Aufgabe an, unterbricht seine aktuelle Arbeit und kümmert sich um das Problem. Wichtig ist dabei, dass der Springer nicht delegieren sondern Teamkollegen nur um Hilfe fragen darf. So wird sichergestellt, dass nach einer gewissen Zeit jeder im Team die kleinen Aufgaben alleine meistern und ohne Hilfe aus dem Team arbeiten kann. Ein schöne Methode zur Verbreitung der Wissensbasis über die Software.
Das Resultat werde ich in Kürze ebenfalls vorstellen!
Schon einmal den Tunnelblick beim Coden bekommen? Nicht mehr ansprechbar gewesen und gereizt auf Unterbrechungen reagiert? Es gibt Momente im Leben von Programmierern, wo einfach alles von selber läuft und ausnahmsweise mal Google und StackOverflow nicht zur Unterstützung gebraucht werden. Dein Wesen und Geist verändert sich in einziges StackOverflow gefüllt mit eleganten und korrekten Antworten. [...]
Wenn man eine Webapplikation bauen möchte, ist, wenn man den Statistken glaubt, PHP die erste Wahl. PHP ist einfach und sein Stack in Apache macht auch den ersten Rollout sehr einfach. Mit PHP kann man komplizierte Sachverhalte sehr einfach ausdrücken und die Fülle an Beispielen und Erweiterungen im Netz sind einfach atemberaubend. Große Webprojekte habe [...]
Wer es noch nicht kennt sollte es umbedingt einmal ausprobieren. Piwik ist eine Open Source Alternative zu Google Analytics, ist mittlerweile in der Version 1.4 erschienen und in PHP geschrieben. Dabei liegen die Vorteile in der offenen Datenbankstruktur und der Möglichkeit Plugins selber zu schreiben. Auch die Integration in das eigene System gestaltet sich durch [...]
Server Side Includes sind alt. Uralt! Aber trotzdem findet man sie auch noch heute in modernen Webserverimplementierungen wie Lighttpd oder Nginx. Brauchen tut man sie eigentlich nicht mehr, sind sie doch nicht ansatzweise so performant wie die heute eingesetzten Websprachen. Seit CGI sind SSI eigentlich überflüssig. Aber für manch ein Szenario findet sich auch heute [...]
Reguläre Ausdrücke sind ja schon ganz nett und mächtig, aber das hier ist mal jetzt echt übertrieben. Wer kann so was den noch lesen geschweige den debuggen http://www.ex-parrot.com/pdw/Mail-RFC822-Address.html
Nachdem ich in zwei Artikeln kurz und knapp die Thematik angesprochen habe, das der Google Algorithmus zu wenig auf die ganzen Content Farmen eingeht, die professionell und massenweise SEO Optimierungen vornehmen, gab es im Google Blog eine Reaktion (nicht als Reaktion auf meine beiden Artikel (Google schafft sich ab: Grund1, Grund2), das wäre vielleicht etwas [...]
