ACHTUNG - NEUES BLOG

Ab sofort steht unter http://devtyr.norberteder.com mein neues Blog zur Verfügung. Dieses Blog wird nicht weiter betreut, bleibt aber erhalten. Neue Eintr%auml;ge erfolgen nur mehr im neuen Blog. Kommentare werden ebenfalls nicht mehr behandelt. Wer weiterhin meinen EintrÃ¤gen und Aktivitäten folgen möchte, möge bitte RSS-Feeds, Verlinkungen etc. an die neue Location anpassen.

Der leidenschaftliche Programmierer

28.10.09 - Entwicklung, Diskussionen, Offline
Beitrag von Norbert Eder

Nicht zufällig deckt sich die Überschrift dieses Beitrags mit dem Buch von Chad Fowler (nicht zu verwechseln mit Martin Fowler). The Passionate Programmer, also der leidenschaftliche Programmierer. Es gibt einige Bücher, die sich mit allgemeineren Entwicklerproblemen oder mit speziellen Methoden beschäftigen. Aber nicht alle sind zu empfehlen. In der letzten Zeit habe ich viele dieser Bücher gelesen, einige haben jedoch einen bleibenden Eindruck hinterlassen. So auch das Buch von Chad Fowler.

Worum geht es? Kurz und bündig geht es darum, wie sich ein Programmierer den Weg in seine Zukunft selbst ebnen kann. In den Tag hineinleben, täglich dieselbe Arbeit leisten und dabei auch noch glücklich sein, fällt wohl den meisten Programmierern schwer. Chad erzählt aus seinem und dem Leben anderer, bekannter IT/Software-Experten. Worauf kommt es an, welche Schritte kann man selbst setzen, um Leidenschaft zu entwickeln, diese zu stärken und somit ein erfüllteres Leben zu schaffen?

In kurzen Kapiteln (dafür sehr viele) werden die einzelnen Aspekte hinterfragt und Tipps gegeben. In vielen Fällen kamen mir die Situationen wohl bekannt vor, stehen doch die meisten Entwickler vor den gleichen Fragen und Problemen. Natürlich kann man keine 100%ige Lösung für sein eigenes Problem erwarten, doch tut eine andere Meinung durchaus gut, um den eigenen Weg zu reflektieren bzw. zu begradigen.

Den Abschluss eines jeden Kapitels bilden kleine Aufgabenstellungen, die es erleichtern sollen, das Gelesene zu verstehen und gleich in die Praxis umzusetzen. Ob diese wirklich ausgeführt werden bleibt natürlich jedem selbst überlassen, doch laden sie jedenfalls ein, sich weitere Gedanken zum Thema zu machen, die vielleicht noch weiter als das Buch gehen und somit neue Ideen, Möglichkeiten und Wege bilden.

Insgesamt ein sehr gelungenes Buch, das zwar – wie bereits erwähnt – nicht alle Fragen eines Entwicklers klären wird, aber mit Sicherheit hilft, den Blick auf das Wesentliche zu schärfen, nämlich Leidenschaft für seine Arbeit zu entwicklen und die eigenen Fähigkeiten zu stärken bzw. überhaupt herauszufinden, wo denn die eigenen Stärken tatsächlich liegen. Darauf kann jeder aufbauen und so seinen eigenen - für sich selbst idealen - Weg finden und sich optimal einbringen (sei es unselbständig oder selbständig).

Chad Fowler
Chad Fowler has been a software developer and manager for some of the world's largest corporations. He recently lived and worked in India, setting up and leading an offshore software development center. He is co-founder of Ruby Central, Inc., a non-profit corporation responsible for the annual International Ruby Conference, and is a leading contributor in the Ruby community. Chad is a contributor and editor for numerous books.

Hinweis
Bei einigen meiner Unterhaltungen kam die Frage auf, ob es denn jemand ohne einschlägige Ausbildung in der Softwareentwicklung weit bringen kann (wie auch immer der Terminus "weit bringen" zu definieren ist). Chat Fowler ist hier ein wirklich gutes Beispiel, ist er doch eigentlich Musiker ...

Wer sich für dieses Buch interessiert, findet einige Leseproben unter http://www.it-fachportal.de/5885 und kann sich selbst einen eigenen Eindruck verschaffen.

3 Kommentare - 136 mal angesehen | 2 Trackbacks | Permalink | Trackback-URL

Was der Bogensport mit Softwareentwicklung zu tun hat ...

25.10.09 - Entwicklung, Diskussionen, Qualitätsmgmt.
Beitrag von Norbert Eder

Seit nun mehr als einem Jahr gehe ich in meiner Freizeit dem Bogensport nach. Weit entfernt ein Experte in diesem Sport zu sein, hat mich dennoch die Faszination dieses Sports erreicht. Anfangs als Ruhepol, quasi als Ausgleich, zu stressreichen Zeiten angesehen, tun sich mit Fortdauer des Trainings einige Parallelen zur Programmierung auf.

Während Experten danach trachten, mit jedem Schuss das „Gold“ zu erreichen steht für mich im Vordergrund, eine gute Grundleistung abzurufen und alle Pfeile eng beieinander ins Ziel zu bringen. Können alle Pfeile eine Schussserie im „Gold“ platziert werden, wäre dies natürlich das Optimum – die beste aller möglichen Lösungen. Tatsächlich kann es aber auch schon als gute Leistung angesehen zu werden, alle Pfeile eng beieinander in die 8er zu senden. Alle im 8er zu versenken, jedoch verteilt über den gesamten Ring wäre hingegen keine besonders gute Leistung, sondern eher dem Glück zuzuschreiben. Warum?

Sind alle Pfeile eng beieinander muss nur eine kleine Korrektur vorgenommen werden und sie alle können im höchsten Ziel platziert werden. Können die Pfeile jedoch nicht angrenzend gereiht werden, wird es zunehmend schwieriger, dies zu tun.

Die Quintessenz daraus ist, dass zu Beginn des Trainings nicht das Erreichen vieler Punkte ausschlaggebend ist, sondern vielmehr die enge Platzierung der Pfeile, egal wohin. Ist dieser Schritt getan, können weitere Verbesserungen vorgenommen werden. Zu dieser Fähigkeit müssen weitere entwickelt werden:

Automatisierung der Abläufe: Wer sämtliche Abläufe verinnerlicht und automatisiert, muss sich darüber keine Gedanken machen. Es geschieht einfach automatisch. Übrig bleibt, sich voll auf das eigentliche Ziel konzentrieren zu können. So verhält es sich auch in der Softwareentwicklung. Nur wer seine Werkzeuge kennt und sie verinnerlicht, hat den Kopf für die eigentliche Lösung eines Problems frei. Nur wer nicht die Feinheiten hinterfragen muss, kann einen Überblick über das Gesamte erlangen und so seine Fähigkeiten voll ausspielen.

Konzentration: Dies ist wohl eine der wichtigsten Fähigkeiten des Bogensports. Wer sich nicht konzentrieren kann (aus welchen Gründen auch immer), wird weder den richtigen Zeitpunkt finden, den Pfeil loszulassen ( zu releasen), noch einen geschmeidigen Bewegungsablauf erreichen. Das Erfassen des Zieles wird extrem schwierig, wenn nicht gar unmöglich. Die täglichen Anforderungen an einen Entwickler erfordern ebenfalls ein gehöriges Maß an Konzentrationsfähigkeit. Wir sind ständig von äußeren Einflüssen (Lärm, Anfragen, Emails, Messenger, etc.) umgeben. Diese müssen über einen notwendigen Zeitraum ausgeblendet werden können. Nur so ist es möglich, sich auf das Wesentliche zu beschränken bzw. dieses überhaupt erst ins Licht zu rücken. Wer schon einmal mit dem Bogensport (oder einer ähnlichen Sportart) in Berührung gekommen ist weiß, dass das Training eigentlich sofort abgebrochen werden kann, wenn die Konzentration nicht stimmt bzw. diese nicht geschaffen werden kann.

Genauigkeit: Schon mal versucht, ohne genau zu sein, das Gold zu treffen? Vielleicht auch getroffen? Zufall. Wer keine Genauigkeit an den Tag legt (angefangen bei der Körperhaltung, dem Bewegungsablauf, der Konzentration, etc.) wird keine beständige Leistung bringen. Allenfalls basieren Erfolge auf Glück. Darauf kann man sich nicht verlassen, möchte man eine solide Leistung über einen langen Zeitraum erbringen. In der Softwareentwicklung spielt Genauigkeit ebenfalls eine große Rolle. Im Gegensatz zum Bogensport können die meisten Softwareentwickler davon ausgehen, dass keine Menschenleben in Gefahr sind. Nichts desto trotz müssen Anforderungen korrekt umgesetzt, Qualität hochgehalten und Termine eingehalten werden. Dies kann nur durch ein ausreichendes Maß an Genauigkeit erreicht werden.

Der Verzicht auf die notwendige Konzentration und Genauigkeit kann beim Bogensport – wie bereits erwähnt - schnell ein Menschenleben kosten. Im geringsten Fall entstehen Materialkosten. Diese sind nicht zu unterschätzen. Ein verirrter Pfeil der Mangels an Konzentration abgeschossen wurde, fällt sehr schnell Hartholz, Beton, Steinen oder anderen Hindernissen zum Opfer. Bedenkt man die verhältnismäßig hohen Kosten eines Pfeiles rentiert es sich nicht, unkonzentriert diesem Sport nachzugehen. Pro Trainingssession zwei zerstörte Pfeile á 10 Euro ergeben 20 Euro Minus pro Trainingseinheit. Unter der Annahme, dass pro Woche zweimal trainiert wird, entstehen im Jahr dadurch Kosten von über 2000 Euro. Sehr viel für ein Hobby. In der Softwareindustrie können Fehler, nicht eingehaltene Termine etc. ebenfalls ungeahnte Kosten verursachen. Angefangen von kostenlosen Fehlerbehebungen (Personalkosten, es könnte an anderen, lukrativen Projekten gearbeitet werden), Pönalezahlungen für nicht eingehaltene Termine bis hin zum Konkurs des Unternehmens – und somit der Verlust des eigenen Jobs - ist alles möglich. Ein sehr hoher Preis.

Natürlich kann man daraus nur sehr schwer Regeln für die Allgemeinheit abbilden. Für mich konnte ich mit auf den Weg nehmen, dass das Einhalten kleiner Regeln, angelehnt an mein Hobby, die Arbeitsleistung erheblich steigern kann. Jeder muss seinen eigenen Weg finden, mit bestimmten Situationen umzugehen, ein Ausgleich tut jedoch immer gut, gibt Kraft für schwere Zeiten und hilft, Probleme aus einem anderen Licht zu betrachten.

Kommentar hinzufügen | 1 Trackbacks | Permalink | Trackback-URL

Effizienz durch Kreativität und Intuition steigern

22.05.09 - Entwicklung, Diskussionen, Qualitätsmgmt.
Beitrag von Norbert Eder

Das Gehirn besteht bekanntlich aus zwei Hälften. Der logisch und der kreativ geprägten. Der logische Part ist zuständig für Logik, Analyse, Sprache, Regeln usw. Die rechte Gehirnhälfte ist verantwortlich für unsere Phantasie, Kreativität, Gefühl, Formen und unsere Intuition. Als Softwareentwickler ist man geneigt, hauptsächlich den logischen Part des Gehirns zu nutzen. Klar, beschäftigen wir uns hauptsächlich mit der Analyse von Problemen, wollen wir doch Lösungswege finden und diese klar strukturiert umzusetzen.

Wie oft passiert es aber, dass wir vor einem Problem sitzen, dieses immer und immer wieder durchgehen und analysieren, ohne jedoch eine wirkliche Lösung zu finden. Diese trudelt dann bei einer niedrigen Tätigkeit ein, beispielsweise beim Ausräumen des Geschirrspülers, beim Staubsaugen, beim Laufen, Spazieren oder Wandern. Wie kommt es dazu?

Fangen wir bei der inneren Stimme an. Diese Stimme (und hoffentlich ist es nur eine) brabbelt ständig vor sich hin und spiegelt unsere logische Welt (also die linke Gehirnhälfte) wider. Sie erzählt uns, was wir bewusst wissen. Alles was in unserem Gehirn indiziert wurde und in Worten auszudrücken ist. Während dieser Zeit ist unsere rechte Gehirnhälfte blockiert. Kreativität kann sich nicht entfalten, unterbewusste Ereignisse, Ideen etc. können nicht aufgearbeitet werden. Sobald wir uns aber um niedrige Tätigkeiten kümmern, die schnell zu Langeweile führen, schaltet unser logischer Part ab. Die innere Stimme reißt ab und aktiviert dadurch unser kreativ geprägtes Wesen. Dieses kann nun Dinge, die uns beschäftigen, im Hintergrund aufarbeiten, was schlussendlich irgendwann zu einem Ergebnis führt. Und schwupp, wir haben eine Idee, einen Lösungsansatz. Eventuell können wir nicht nachvollziehen, woher diese kommt, oder wie wir darauf gekommen sind, aber wir können damit arbeiten.

Was möchte ich damit sagen? In vereinfachten Worten: Wir Softwareentwickler sind sehr logisch ausgeprägt. Alles muss seine Ordnung, seinen Ablauf und seine Regeln haben. Viele Entscheidungen werden jedoch intuitiv getroffen (wie war das mit Entscheidungen aus dem Bauch fällen?). Dazu wird die kreative Gehirnhälfte gebraucht, die von uns jedoch nicht ausreichend trainiert wird. Durch eine verbesserte Verkopplung beider Gehirnhälften können beide „Seiten“ benutzt werden. Das führt zu mehr Kreativität, zu höherer Leistung, zum schnelleren Erfassen des Kontextes, in dem wir uns bewegen, oder aber unser Problem.

Dies kann man trainieren. Durch einfachste Mittel. Schreiben ist eines davon. Viele schreiben Blogs. Das ist durchaus ein erster Schritt, kreativ zu werden und seine rechte Gehirnhälfte mit einzubeziehen. Um dies bewusst zu fördern bieten sich jedoch so genannte Morgenseiten an. Diese werden vorwiegend den Autoren unter uns bekannt sein. Zu den Morgenseiten muss ich etwas ausholen:

Während wir schlafen, existiert unsere innere Stimme nicht. Diese Welt gehört der kreativen Seite. Das spiegelt sich in unserem Träumen wider. In unseren Träumen sehen wir Bilder, eventuell ganze „Filme“. Diese entspringen nicht nur unserer Phantasie, sondern es werden auch Erlebnisse, Ereignisse, Fragestellungen und Probleme unterbewusst aufgearbeitet. An manches können wir uns nach dem Aufstehen erinnern, an manches nicht. Aber immer kann es uns weiterhelfen, wenn auch manches nicht wörtlich beschrieben werden kann. Wer kennt das Gefühl, in der Früh aufzustehen und eine Lösung zu haben?

Werden wir munter, schalten wir nicht sofort vollständig in den Logikmodus. Es bedarf einer bestimmten Zeit, die rechte Gehirnhälfte zu verlassen. Dies ist genau der richtige Zeitpunkt, um sich mit seinen Morgenseiten zu beschäftigen. Einfach ein paar Zettel und einen Stift zur Hand nehmen und einfach drauflos schreiben. Dabei ist es nicht wichtig, WAS man schreibt, sondern, dass man es tut. Anfangs weiß man nicht, was man schreiben soll, dann schreibt man eben das nieder. Aber es wird immer besser und schlussendlich werden äußerst hilfreiche Notizen zu Papier gebracht, die in vielen Situationen entscheidend sein können. Wichtig ist, nicht nur zwei Zeilen zu schreiben. Idealerweise schreibt man bis zu drei Seiten. Das hört sich nach viel an, ist es aber nicht. Außerdem sollten diese Seiten VOR ALLEM anderen geschrieben werden, sollte also die erste Aufgabe des Tages sein. Noch vor dem Kaffee, der Dusche oder dem Frühstück.

Wer dieses Vorgehen über einen Zeitraum von einigen Wochen probiert, wird außerordentliche Fortschritte erleben. Versprochen.

By the way: Immer den Kontext beachten!

3 Kommentare - 1309 mal angesehen | 0 Trackbacks | Permalink | Trackback-URL

Getting Ideas Done

16.05.09 - Entwicklung, Diskussionen, Projektmgmt., Qualitätsmgmt.
Beitrag von Norbert Eder

Der Weg von einfachen Ideen zu tatsächlich Umsetzbarem ist nicht einfach. So müssen Ideen erst geboren werden. Anschließend müssen sie verfeinert und schlussendlich zur Umsetzung gebracht werden. Ein langer Weg, nutzt man nicht diverse Hilfsmittel.

In Erinnerung kommt hier Getting Things Done (GTD). Hierzu die Grundregel:

GTD basiert auf dem Prinzip, dass eine Person ihre anstehenden Tätigkeiten notiert und somit den Kopf frei hat für Wichtigeres.

Eigentlich einfach: Eine Aufgabe tut sich auf und wird sofort notiert. Daraus ergibt sich eine Liste von Aufgaben (Prioritäten etc. spielen natürlich auch eine Rolle), die man dadurch immer im Überblick hat und abarbeiten kann. Alle notierten Aufgaben muss man fortan nicht mehr in Gedanken halten, sie wurden niedergeschrieben, man kann nachsehen und muss nicht erst lange darüber nachdenken, was denn noch alles zu erledigen ist. Vorausgesetzt, man hat immer ein entsprechendes Werkzeug zur Hand, um Aufgaben niederschreiben und wieder nachlesen zu können.

Ähnlich verhält es sich mit Ideen. Jeder Mensch hat gute Ideen. Viele dieser Ideen werden jedoch nicht weiterverfolgt. Weiterverfolgt können sie jedoch nur werden, wenn man sich der Ideen bewusst ist, die man hat und sich darum kümmert. Das Ziel ist nicht, sich an eine Idee zu erinnern, wenn man Fremdprodukte sieht und denkt: „An so etwas Ähnliches habe ich auch schon einmal gedacht.“. Ziel sollte es sein, aktiv mit den eigenen Ideen zu arbeiten, um sie auch verwirklichen zu können.

„Ich habe keine guten Ideen“ mag nun der eine oder andere denken. Das mag vielleicht sogar korrekt sein und resultiert sehr wahrscheinlich daraus, dass nie auf geborene Ideen reagiert wurde. Das Gehirn hört auf, weitere Ideen zu produzieren, da diese ohnehin nicht weiterverfolgt werden. Wie also kann man aus diesem Dilemma ausbrechen?

Die GTD-Ansätze können auch für unsere Ideen genutzt werden. Einfälle und Ideen sollten niedergeschrieben werden. Hierbei ist es nicht wichtig, in welches Medium sie eingetragen werden, vielmehr sollte dieses immer verfügbar sein. Durch regelmäßige Durchsicht der gemachten Aufzeichnungen, gehen diese ins Unterbewusstsein ein und das Gehirn kann an den Einfällen weiterfeilen, bis schlussendlich ein Ansatz geliefert wird, der tatsächlich Erfolg versprechen kann. Zu beachten ist, dass DER Einfall zu jeder Zeit kommen kann, auch wenn man aktuell mit gänzlich anderweitigen Dingen beschäftigt ist. Das Gehirn arbeitet in zwei unterschiedlichen Modi, einem linearen Modus (Sprechen etc.) und einem asynchronen Modus. Letzterer verwaltet Langzeitinformationen und ist für Intuition und Problemlösung verantwortlich, quasi eine Such- und Abfragemaschine mit bewusstseinserweiternden Fähigkeiten. Der Vorgang der Ideenfindung wird also asynchron ausgeführt. Wann dieser beendet ist, ist nicht vorhersagbar. Es kann sich um Minuten, Stunden, Tage, aber auch Wochen handeln.

Quintessenz ist daher: Nicht nur Aufgaben notieren, um den Kopf für „Wichtigeres“ frei zu bekommen. Auch Ideen, Ansätze und Einfälle sollten gleich behandelt werden. Eine regelmäßige Durchsicht zeigt dem Gehirn, dass Interesse daran besteht und weitergearbeitet werden soll. Ist dies erst einmal automatisiert, werden sich die ersten Erkenntnisse einstellen.

Ganz interessant dazu ist natürlich die Frage, wo sollen diese Aufzeichnungen vorgenommen werden. Hier bieten sich unterschiedlichste Hilfsmittel an. Vom Notizbuch bis hin zum Handy ist alles möglich. Wichtig ist nur, dass das Hilfsmittel immer zur Hand ist und sofort, ohne Aufwand verwendet werden kann.

Zu guter Letzt noch ein kleiner Hinweis: Interessant zu diesem Thema ist pocketmod.com. Angeboten wird eine Flash-Applikation, mit deren Hilfe man sich ein „Pocket-Notizbuch“ zusammenstellen kann. Zur Auswahl stehen die unterschiedlichsten Seiten-Vorlagen, angefangen vom Kalender, bis hin zu Kontakt- und Aufgabenlisten. Diese können ausgedruckt und anschließend zusammen gefaltet werden (eine Anleitung ist ebenfalls auf der Homepage zu finden). Eingesteckt und immer dabei, ohne großen Aufwand betreiben zu müssen.

Kommentar hinzufügen | 0 Trackbacks | Permalink | Trackback-URL

Qualität als Weg aus der Wirtschaftskrise

29.04.09 - Entwicklung, Diskussionen, Qualitätsmgmt.
Beitrag von Norbert Eder

Stefan Lieser hat einen Blog-Post verfasst, der sich mit Qualität und Wirtschaftskrise befasst. Darin schreibt er, dass sich Unternehmen mit hoher Qualität gerade in schlechten wirtschaftlichen Zeiten von der Konkurrenz absetzen und verbesserte Chancen haben. Unternehmen, die niedrigere Qualität bieten, bleiben auf der Strecke bzw. haben verschlechterte Chancen.

Grundsätzlich verstehe ich seine Argumentation. Aber trifft dies auf alle Branchen bzw. überhaupt zu - so, wie es Stefan beschreibt?

Ich würde es gerne so wie Stefan sehen, tue es aber nicht. Aus meiner Sicht verhält es sich so, dass Unternehmen gerade zu wirtschaftlich schwachen Zeiten ihre Budgets straffen und der Spar-Modus aktiviert wird. Qualität kostet Geld und verteuert entsprechend das resultierende Produkt. Unternehmen werden also dazu neigen, zu günstigeren Produkten zu greifen. Günstige Produkte bedeutet nicht zwangsweise hohe Qualität, eher im Gegenteil.

Daher sehe ich in wirtschaftlich schlechten Zeiten eher Unternehmen mit geringem Qualitätsbewußtsein, jedoch kurzen Umsetzungszeitpunkten im Vorteil. Besteht Wirtschaftswachstum, ist genügend Geld im Umlauf, darf das Produkt auch etwas kosten. Geld ist vorhanden, qualitative Werte werden daher eher berücksichtigt.

Ich will damit nicht sagen, dass es für Unternehmen von Vorteil ist, gerade jetzt qualitativ minderwerte Produkte auf den Markt zu werfen. Qualität zahlt sich immer aus - ganz klar. Nur sollte dieser Grundgedanke nicht erst jetzt greifen, sondern immer. Dazu gehört nicht nur das Unternehmen, sondern auch seine Mitarbeiter.

1 Kommentar - 2498 mal angesehen | 0 Trackbacks | Permalink | Trackback-URL

Entwickler sind nicht gleich Entwickler

18.03.09 - Entwicklung, Diskussionen, Qualitätsmgmt.
Beitrag von Norbert Eder

Jeder sucht sie. Die Entwickler im Alter von 25 mit 15 Jahren Berufserfahrung und einem abgeschlossenen Studium. Auch in vielleicht nicht allzu rosigen Zeiten. Die Anforderungen der Firmen sind mehr oder weniger hoch. Je nach Bedarf ergeben sich jedoch gut dotierte Stellen. Doch können auch alle Bewerber die gewünschten Anforderungen erfüllen?

Bis dato hatte ich immer wieder gewettert, dass die Anforderungen an einen potentiellen Mitarbeiter recht hoch sind, während die gebotenen Leistungen oft zu wünschen über lassen, oder gar keine Erwähnung finden. Mittlerweile sehe ich dies gar nicht mehr als die tatsächliche Hürde, da die Leistungen reine Verhandlungssache sind und Unternehmen durchaus bereit sind, gute Leistungen entsprechend zu honorieren.

Vielmehr möchte ich dieses Mal in eine andere Kerbe schlagen: Bekommt das Unternehmen das, was der Bewerber versprochen hat? Lebensläufe sind ja ganz nett um den Werdegang eines potentiellen Mitarbeiters zu begutachten. Darauf lässt sich nur leider - in vielen Fällen - kaum etwas über die Person selbst ableiten. Leistungen an teilgenommenen Projekten werden in die höchsten Sphären gelobt, es wird erzählt, was denn nicht alles gemacht wurde und wofür man sich denn nicht alles interessiert.

Die Wirklichkeit sieht jedoch oft anders aus. Damit möchte ich keinem Entwickler etwas unterstellen. Im Gegenteil - schließlich bin ich doch selbst einer und würde mir dadurch nur ins eigene Fleisch schneiden. Tatsache ist jedoch, dass nicht jeder Entwickler mit jahrerlanger Erfahrung auch wirklich das Geld wert ist, das er für seine Leistungen erhält. Auf Basis der jahrelangen Erfahrung (wie immer diese auch aussieht) tritt oft ein Schlendrian ein, der vor persönlicher Weiterentwicklung schützt. Konzepte, die eigentlich klar sein sollten, sind es nicht. Selbstschützende Maßnahmen (Testing) werden nicht durchgeführt, da sich dieses Bewusstsein trotz jahrelanger Entwicklung (und Erfahrung) nicht gefestigt oder gar gebildet hat.

Toll finde ich Initiativen, welche den Entwickler unterstützen, seine tägliche Arbeit zu verbessern, das Bewusstsein für qualitativ hochwertige Software zu schärfen. Im Endeffekt liegt es am Entwickler selbst - und seinen Kenntnissen. Die besten bewusstseinsbildenden Maßnahmen greifen nicht, wenn er selbst nicht bereit ist, an seinen eigenen Prozessen zu arbeiten. Motivation, Eigeninitiative, Wissbegiehrigkeit und Genauigkeit sind gefragt. Das sind die Basis-Skills, die jeder Softwareentwickler mit sich bringen sollte.

Sehr viele Entwickler leben jedoch in den Tag hinein, erledigen ihre Aufgaben und lassen alles andere bei Seite. Ein denkbar schlechter Weg, qualitativ hochwertige Software zu produzieren. Dabei ist das Wissenslevel nicht entscheidend. Jeder, wirklich jeder kann gute Software schreiben. Vielleicht unterscheidet sich die Software im gewählten Design, vielleicht finden sich wenige oder unbewusst genutzte Patterns darin. Aber das Produkt ist robust und erfüllt die Anforderungen. Softwareentwickler, die nur ihren Task berücksichtigen, nicht rechts und nicht links blicken, sind out.

Auch wenn es hart klingt: Unternehmen müssen darauf reagieren. Nicht jeder ist ein Technologiefreak oder gar ein Multiplikator, es darf jedoch damit gerechnet werden, dass sich jeder Entwickler mit seinem Werkzeug vertraut macht und versucht, seine Leistung zu optimieren. Jeder Entwickler, der nicht mindestens das versucht, hat sich - meiner bescheidenen Meinung nach - in seiner Berufswahl vertan.

7 Kommentare - 1976 mal angesehen | 0 Trackbacks | Permalink | Trackback-URL

Clean Code Developer - Gedanken zum Online-Meeting

10.02.09 - Entwicklung, Diskussionen, Patterns, Software Testing, Qualitätsmgmt.
Beitrag von Norbert Eder

Gestern hatte es das 3. Online Meeting von ALT.NET DE zum Thema Clean Code Developer (CCD) gegeben. Mit dabei war jede Menge Prominenz der deutschsprachigen .NET Community.

Ich möchte an dieser Stelle jetzt nicht das Thema Clean Code Developer (= die Initiative) breittreten - da kann sich jeder auf oben verlinkter Site informieren. Vielmehr möchte ich auf einen gestrigen Aspekt eingehen, dem ich nicht so wirklich zustimmen möchte und den ich gerne diskutieren würde.

Grundsätzlich, damit ich nicht falsch verstanden werde: Ich finde diese Initiative sehr gut, sie erhält meine vollste Unterstützung und auch ich versuche tagtäglich, mich und meinen Output zu verbessern.

Einer der Punkte, der gestern aufkam, betraf die Verteilung der Prinzipien, Paradigmen und Werte. Hier kam mehrfach zur Sprache, dass denn die Hersteller von Entwicklungstools, als auch die Lehre (konkret wurden Fachhochschulen angesprochen) hauptsächlich zur Verbreitung dieser Bewegung beitragen sollten, dies aber lange Zeit vernachlässigt wurde bzw. immer noch wird. Durch das Eine oder Andere Zitat eines FH-Professors sollte dies weiter unterstrichen werden.

Da ich selbst an einer Fachhochschule unterrichte und daher die "andere Seite" auch ganz gut kenne, möchte ich dazu meine Gedanken einbringen (dies gilt auch für Trainingscenter etc.):

Ich kann nicht beurteilen, wie Fachhochschulen in Deutschland aufgestellt sind. Ich kenne einige in Österreich und weiß daher, dass an zahlreichen Fachhochschulen wichtige Prinzipien zur Erhöhung der Software-Qualität gelehrt werden. Woraus besteht dies in vielen Fällen?

Vermittlung des notwendigen Stoffes
Hervorhebung der sich daraus ergebenden Vorteile
Laufende Verwendung, sofern möglich
Bei Bedarf Diskussion und Gegenüberstellung

Dies bedeutet: Die Lehre vermittelt das notwendige Wissen (Qualitätssicherungsmaßnahmen, Code Metriken, Code Coverage, Versionierung, Test, etc.). Auf dieser Basis werden die Vorteile klar hervorgehoben und versucht, diese in sämtlichen Projekten einzusetzen (Teile werden zwingend vorgegeben).

Was aber jetzt nicht durch die Lehre passieren kann (konträr zu einigen gestrigen Meinungen) ist, dass dieses Muster in jeden hinein geprügelt werden kann. So funktioniert es nicht. Der angehende Entwickler (egal ob durch eine Ausbildung, ein Training, FH, Uni, etc.) muss von sich aus die Vorteile aufnehmen und sich selbst dahin bringen, diese laufend einzusetzen. Der Vortragende kann den Grundstock legen. Genauso wie es der Hersteller von Entwicklungswerkzeugen kann. Aber weder der Vortragende, noch der Hersteller können den Entwickler zwingen.

Aus dieser Sichtweise heraus ist es ebenfalls unwesentlich, ob diverse Praktiken vom Vorgesetzten unterstützt werden oder nicht. Wer um Qualität bemüht ist, wird dies umsetzen. So oder so. Wer um Qualität bemüht ist, wird sich fortbilden bzw. nach entsprechenden Möglichkeiten suchen. Wer gezwungen wird, der lehnt sich dagegen auf. Das ist der natürliche Lauf der Dinge.

Fazit: Es braucht Multiplikatoren (Hersteller, Vortragende, aber VOR ALLEM Entwickler), welche die Vorteile aufzeigen, die unterstützend tätig sind, damit möglichst viele auf diesen Zug aufspringen. Aber niemand kann von einem Absolventen erwarten, dass er es genau so macht und dann der Ausbildungsstätte die Schuld zuweisen, es würde nicht gelehrt werden. Daher mache ich den Softwareentwickler (fast) alleine für (fehlende) Qualität verantwortlich. Schließlich heißt es ja auch Clean Code Developer.

2 Kommentare - 6682 mal angesehen | 0 Trackbacks | Permalink | Trackback-URL

Coding Standards als wichtiges Instrument

07.01.09 - Entwicklung, Diskussionen, Qualitätsmgmt., .NET, Grundlagen
Beitrag von Norbert Eder

Wichtigstes Ziel in der Softwareentwicklung ist es, Projekte zeitgerecht und qualitativ hochwertig abzuschließen. Damit dies auch funktionieren kann, bedarf es Coding Standards, die von allen Team-Mitgliedern eingehalten werden müssen.

Da es wieder Zeit wurde, die eigenen Coding Standards anzupassen, machte ich mich auf die Suche, um meinen Horizont diesbezüglich wieder etwas zu erweitern. Dabei stieß ich auf die Coding Standards Reference Documents von Clint Edmonson. Clint hat dabei grundlegende Coding Standards für VB.NET und C# aufbereitet und als Download zur Verfügung gestellt.

Folgende Themen werden behandelt:

Golden Rules
Formatting
Commenting
Capitatlization & Naming
Programming

Diese Dokumente stellen eine gute Grundlage für jeden Softwareentwickler, als auch für gesamte Teams dar. Im Idealfall werden Ergänzungen gemacht und als Standardlektüre für jeden Entwickler im Team verpflichtend vorgesehen.

Weiters empfiehlt es sich, die Coding Standards auch entsprechend zu kontrollieren, damit sie tatsächlich Anwendung finden. Dies kann in Reviews passieren.

Der eine oder andere mag an dieser Stelle vielleicht die Meinung vertreten, dass zuviel Einschränkung schlecht ist. Dem kann ich allerdings nicht zustimmen. Ein Team an Entwicklern bedarf eine Führung und auch Rahmenbedingungen innerhalb derer sie sich zu bewegen haben. Nur dann kann ein (hoffentlich) optimales Ergebnis verfolgt und erzielt werden.

3 Kommentare - 1479 mal angesehen | 0 Trackbacks | Permalink | Trackback-URL

Perfektion als Maßstab?

05.12.08 - Entwicklung, Diskussionen, Software Testing, Projektmgmt., Qualitätsmgmt.
Beitrag von Norbert Eder

Schön langsam wird es schwierig, alle Themen unter einen Hut zu bekommen. Ich versuche daher hiermit auf einige Punkte aus den unterschiedlichen Themenbereichen einzugehen, um hoffentlich alles ein wenig zu kanalisieren.

Alex hat ja bereits meine Aussagen zum Thema Der perfekte Softwareentwickler kommentiert. Nun hat sich auch noch Sven zu Wort gemeldet und das Thema Perfekte Software ins Spiel gebracht. Plausible und legitime Fragestellungen bzw. Aussagen können daraus erlesen werden.

Wenn ich mir darüber nun so meine Gedanken mache, dann stellt sich für mich die Frage, ob Perfektion überhaupt der Maßstab sein kann?

Qualität als Hürde

Software wird bekanntlich von sehr vielen nicht als qualitativ hochwertig angesehen, unabhängig der Bereiche, in denen seit jeher getestet wird, was das Zeug hält. In Business-Anwendungen und im Individual-Bereich zählen oft andere Anforderungen: schnelle Umsetzungszeit, möglichst hohe Funktionsdichte, möglichst hoher Gewinn. Legitime und nachvollziehbare Punkte, die sich offensichtlich mit erhöhtem Zeitaufwand durch Qualitätssicherung, Einführung neuer Methoden und Praktiken oft nicht vereinbaren lassen. Oder doch?

Aus Sicht der Nicht-Entwickler, fallen zum Zeitpunkt der Einführung derartiger Prozesse höhere Aufwände (zeitlich, monitär, etc.) an. Diese wollen oder können nicht getragen werden.

Der springende Punkte daran (und hier können sich weder Kunde, noch der Vorgesetzte, noch die Entwickler ausnehmen) ist, dass jeder seinen Teil dazu beitragen muss. Eine Gruppe alleine kann den großen Umschwung nicht bringen. Prozesse müssen optimiert, Methoden eingesetzt und beides gelebt werden. Nur dann kann es funktionieren.

Im Zuge dessen fällt immer wieder der Return on Investment (ROI). Ich gehe nicht so weit zu sagen, dass ihn niemand erkennt. Vielmehr wird oft nur der vermeintlich steinige Weg gesehen, den es zu gehen gilt. Dass dieser Weg gar nicht so steinig ist und mit kleinen, eingestreuten, Änderungen sehr schnell gegangen werden kann, wird oft nicht korrekt vermittelt (vom Entwickler, von Magazinen, von Online-Artikeln, etc.) oder vom Vorgesetzten dem Kunden gegenüber. Letztlich ist es dem Kunden egal, er will ein funktionierendes Produkt haben. Wie dies erreicht wird, Sache des Herstellers.

(Bewusst aussen vor lasse ich hierbei die Themen wie mit Features etc. umgegangen wird.)

Verantwortung übernehmen

Wohl einer der wichtigsten Punkte: Wer Verantwortung übernimmt, kann Veränderung bringen. Ein qualitätsbewußter Entwickler wird Verantwortung übernehmen, indem er einfach mal eben eine Build-Umgebung einrichtet, oder unabhängig der Unterstützung von oben seine Tests schreibt. Er wird eine geeignete Möglichkeit finden, seine Aufgaben zu analysieren, zu planen, umzusetzen und zu testen. Mit ein wenig Glück kann er diesen Gedanken auf Kollegen und Vorgesetzte transportieren.

Der Vorgesetzte muss Verantwortung üernehmen, indem dieser Entwickler gefördert wird. Natürlich muss nicht nur der qualitative Output passend sein, auch der quantitive. Ganz klar. Er muss einsehen, dass eine qualitative Verbesserung natürlich eine Auswirkung auf den gesamten Output des Unternehmens und somit auch auf das Branding des Unternehmens hat. Der Kunde wird es danken und eventuell weitere Kunden heranschaffen.

Ziel soll es sein, dass sich alle Bereiche (Entwickler, Vorgesetzer, Kunde) gegenseitig unterstützen und sich gegenseitig motivieren sich zu verbessern. Das muss nicht in Einklang mit Verzögerung, weniger Gewinn etc. gehen. Wohl aber geht es in die positive Richtung - mit dieser Einstellung.

Suchen, Sehen, Lernen, Verstehen, Vermitteln

Was Sven festgestellt hat, kann ich nur unterstreichen. Niemand weiß alles. Perfektion kann es also in diesem Sinne nicht geben. Was es aber geben kann und sollte, ist eine permanente Annäherung. Die Entwicklung von Software geht heute kaum schneller voran, als dies vor einigen Jahrzehnten der Fall war. Lediglich die Mittel, Werkzeuge haben sich geändert. Aus einem einfachen Programmierer ist ein Entwickler geworfen. Mit höheren Anforderungen, höhrerer Eigenständigkeit und mehr Verantwortung.

In diesem Zusammenhang fällt mir spontan der Begriff des Paradigmenwechsels ein. Ein Paradigmenwechsel wird notwendig, wenn Anomalien zunehmen und erkannt wird, dass ein anderer Weg doch der bessere wäre. Bis das Spiel wieder von vorne beginnt. In unserer schnelllebigen Branche verändert sich zwar vieles, Paradigmenwechsel halten sich - aus meiner Sicht - jedoch in Grenzen. Es gibt zwar hier Neues, dort Neues, aber wirklich wichtige Praktiken werden nur sehr sehr langsam angenommen.

Woran scheitert das?

Nicht weil wir so schlecht sind, es ist die Fülle an Information, an Werkzeugen, an Methoden. Haben sich darüber früher eine Handvoll Personen Gedanken gemacht, ist in der heutigen Zeit an allen Ecken und Enden ein neuer Aspekt zu lesen. Schwierig, alles unter einen Hut zu bekommen.

Wie war das? Sprich mit fünf Leuten und du erhältst 6 Meinungen. Der einzig wahre Weg ist nicht zu finden. Aber führen nicht alle Wege nach Rom? Die impliziert, das Rom das Ziel aller Ziele wäre. Dies bedeutet, dass auch alle Wege an Ziel führen. Ist das so?

Wie viele (Software)Projekte werden nicht abgeschlossen? Wieviele werden nicht mit vollständiger Funktionalität rechtzeitig ausgeliefert? Die Antwort kann sich jeder selbst geben.

Der Punkt ist, dass eben nicht alle Wege ans Ziel führen. Unterschiedliche Zeiten erfordern unterschiedliche Aktionen.

Gibt es eine Lösung?

Wohl nicht. Man kann wohl niemanden bekehren den richtigen Weg zu gehen, weil es ihn einfach nicht gibt. Aber man kann durchaus einen richtigeren Weg vorschlagen und versuchen zu unterstützen. Eigeninitiative und Verantwortung sind sie Schlagwörter von Wichtigkeit.

Es ist schön perfekt zu sein. Niemand wird jemals perfekt sein. Weder der Mensch, noch seine erschaffenen Produkte. In ist, wer nicht perfekt sein will, sich und seine Umgebung jedoch beständig zu verbessern versucht.

In diesem Sinne:
Keine Perfektion, aber kontinuierliche Verbesserung!

Kommentar hinzufügen | 1 Trackbacks | Permalink | Trackback-URL

Gedanken zum perfekten Softwareentwickler

04.12.08 - Entwicklung, Diskussionen, Software Testing, Qualitätsmgmt.
Beitrag von Norbert Eder

Nach meiner Antwort zu Peter, hat sich nun auch Alex zu Wort gemeldet. Dem kann ich mich inhaltlich auch voll und ganz anschließen (ein Hoch auf mein Notizbuch).

Was ich jedoch aussagen wollte, war etwas anderes. Wir sprechen hier von Themenbereichen, die für manche täglich Brot sind und worüber oft nicht mehr nachgedacht werden muss. Bei vielen Entwicklern verhält sich das anders.

So erlebe ich fast täglich, das Begriffe wie Test-Driven-Development (TDD) oder Domain-Driven-Design (DDD) nicht allgemein hin bekannt sind. Teilweise noch nicht einmal im Ansatz.

Verweigerung: Nein! Doch!

In der Praxis wird Software oft nicht entsprechend dieser Methoden entwickelt. Dies hat unterschiedlichste Gründe:

Unzureichende Motivation, sich weiter zu bilden
Probleme mit dem Programmier-Werkzeug
Ausrede: Zeitdruck
Verweigerung dem Testing gegenüber
Lieber diskutieren anstatt es zu tun
Faulheit
Nicht wissen, wo beginnen

Diese Liste könnte wohl noch um zahlreiche Punkte verlängert werden.

Es gibt Entwickler, die als Leitkuh fungieren und versuchen, andere mit auf diesen Zug zu bringen. Das ist teilweise nicht so einfach. Wie bewegt man jemanden dazu, sich diesen Methoden anzuschließen, wenn jegliche Motivation, dies zu tun, fehlt?

Vorschriften. Schön und gut. Aber kann ein Softwareentwickler zu Qualität gezwungen werden? Wohl nicht. Daher ist es angesagt, Best Practices aufzuzeigen und der Einfachheit halber den Weg langsam zu beschreiten. Nicht jeder kann und will seinen über Jahre antrainierten Wasserfall-Stil von Heute auf Morgen aufgeben und sich um 180° wenden.

Streben nach Perfektion

Der Entwickler ist faul - wird immer behauptet. Daraus ließe sich ableiten, dass er von Haus aus versucht den idealen Weg zu finden, seine Arbeit zu lösen. Lieber einmal kurz und knackig implementieren, als ständig Fehler beheben zu müssen. Lieber mit Testing arbeiten und sich so absichern. Lieber Tools verwenden, die sich aktuelle Paradigmen zu Nutze machen und die Arbeit erleichtern. Alles logische und nachvollziehbare Punkte. Was aber, wenn die Faulheit in die andere Richtung ausschlägt?

Verbesserungsmöglichkeiten?

Eine fehlende Grund-Motivation kann man keinem Entwickler einpflanzen. Aber dem Gewillten kann man den Weg ebnen. Vielleicht wäre es also ganz gut, sich darüber Gedanken zu machen, wie man denn unbedarfte Software-Entwickler erfolgreich, ohne allzu große Hürden auf diesen Weg bringt. Der von Alex aufgezeigte Weg ist sicherlich einer, den doch einige von uns gegangen sind. Aber ist er nicht zu steinig?

Daher meine abschließende Frage: Gibt es überhaupt einen einfachen Weg, das Verständnis und die Bereitschaft zu agilem Denken zu schaffen, oder kann dieser Weg nur vom Entwickler selbst eingeschlagen werden?

2 Kommentare - 885 mal angesehen | 2 Trackbacks | Permalink | Trackback-URL

Weiter