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.

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 - 2497 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 - 1975 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 - 6680 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 - 1475 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

Gedanken zum perfekten Software-Design

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

Peter Bucher hat in seiner Blogpost Es gibt kein perfektes Design, oder doch über die Qualität des Sourcecodes in Projekten geschrieben. Einige der Punkte möchte ich so aber nicht stehen lassen.

Entwickler und Wunschdenken

Im Gegensatz zum zugrunde liegenden Artikel bin ich nicht der Meinung, dass das Wunschdenken bei vielen Entwicklern in Richtung "Perfektes Design" geht. Vielmehr ist es den meisten Entwicklern wichtig, dass die umzusetzenden Punkte in der veranschlagten Zeit umgesetzt werden. Die Qualität wird daher oft außen vor gelassen. Dies resultiert darin, dass sich viele Entwickler kaum Zeit nehmen zu prüfen, wie ein Algorithmus etc. entwickelt werden kann, so dass er performant und zukunftssicher ist.

Das heißt, das Wunschdenken vieler Entwickler geht meist in Richtung "Hoffentlich bin ich bald fertig mit meinem Task". Natürlich gibt es auch Ausnahmen. Keine Frage. Aber sie sind nicht in der Mehrheit.

Debugging-based Development

Ein wichtiger Punkt hierbei ist - und diesen habe ich schon sehr sehr oft erlebt - das Entwickeln per Debugging. Was bedeutet das? Es werden ein paar Codezeilen geschrieben, dann wird gleich der Debugger angeworfen um zu sehen ob es funktioniert. Wenn nicht, dann gibt der Debugger ohnehin Bescheid an welcher Stelle es knackt. Dort wird eine Änderung durchgeführt und der nächste Debug-Durchlauf startet.

Vielmehr sollte sich der Entwickler zuvor Gedanken darüber machen, was denn da wirklich gefordert wird. Daraus ergeben sich Anforderungen an den zu schreibenden Code. Hier ist es oft sinnvoll, sich vielleicht doch ein paar Minuten mit dem MSDN auseinander zu setzen. Eventuell gibt es dann doch einen Hinweis, der mich das Problem wesentlich eleganter lösen lässt. Zusätzlich ist es immer von Vorteil, sich den Ablauf des Problems aufzumalen. Ob dies nun via UML-Tool passiert, per Visio (ja, kann auch UML) oder einfach am Blatt Papier hängt von der Komplexität und der Anzahl der notwendigen Klassen ab. Aber es fängt schon bei Methoden an, die drauflos entwickelt werden.

Das Hauptproblem bei Machen wir einfach mal schnell ist, dass irgendwann der Punkt kommt, der eine Änderung erfordert. Es funktioniert nicht so, wie man sich das gedacht hat. Und hier fängt es an: Der Code wird mit Gewalt so zurechtgerückt, dass er schlussendlich funktioniert. Im Schönwetter-Fall.

Streben nach Perfektion

Der eine hat's, der andere nicht. Es wäre eine Verallgemeinerung zu behaupten, dass jeder Entwickler nach Perfektion strebt. Viele wollen das Produkt fertig stellen, damit Geld herein kommt. Andere reden sich auf den Zeitdruck aus. Andere wollen wieder eine vergoldete Glaskuppel bauen und können ihr Projekt nie abschließen. Es muss also ein Mittelweg gefunden werden. Dieser sollte sowohl in sauberen Code (wie sieht sauberer Code aus?), Einfachheit und Zukunftssicherheit resultieren. Ebenso wenig sollte die Testbarkeit vergessen werden.

Fazit

Es gibt zwar kein perfektes Design, es gibt auch keinen perfekten Sourcecode. Aber jeder Entwickler sollte sich zumindest Mühe geben, Coding-Standards einzuhalten, sich mit seiner Programmiersprache als Werkzeug zu beschäftigen und diese auch entsprechend einzusetzen wissen. Ebenso gehört dazu, auch einmal die eine oder andere Minute mit dem Lesen der Dokumentation zu verbringen und grundsätzlich analytischer an die Problemstellung heran zu gehen.

Sehr gut funktioniert es, sich zuvor zu überlegen, wie denn der neue Code verwendet werden soll. Ein Zeilen wie die neuen Klassen und/oder Methoden verwendet werden sollen und schon erkennt man frühzeitig Probleme und kann diese noch vor dem Start der Implementierung bereinigen. So kleine Dinge können so viel verbessern.

4 Kommentare - 1199 mal angesehen | 1 Trackbacks | Permalink | Trackback-URL

"Alles Neu" ist besser!

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

Nicht nur kleine Unternehmen oder einzelne Softwareentwickler erwischt es. Nein, auch große Konzerne wie Microsoft. So geistert die Meldung durch das Internet, dass Microsoft die Workflow Foundation von Grund auf neu entwickeln wird. Oder zumindest einen Großteil, so genau kann das wohl niemand mit absoluter Sicherheit sagen. Aber ist das grundsätzlich schlecht?

Die wichtige Frage dabei ist wohl, aus welchem Grund eine Neuentwicklung passiert. Gründe hierfür lassen sich einige finden:

Technologie-Wechsel
Performance-Probleme
Mangelnde Erweiterbarkt
Design-Fehler
Sich veränderte Anforderungen

Dies ist nur als kleiner Auszug aus möglichen Gründen für eine komplette Neuentwicklung einer Software oder eines Frameworks zu sehen. Aber kommen wir zur Frage, wann denn eine neue Implementierung tatsächlich gerechtfertigt ist.

Der Ursprung dieses Gedankens liegt meist darin, dass gewünschte Anforderungen nicht mehr den Wünschen entsprechend umgesetzt werden können, oder aber laufend Probleme auftreten, die nicht in den Griff zu bekommen sind. An dieser Stelle muss nun gegenübergestellt werden, wie es um den Aufwand aussieht, der notwendig ist, diese Probleme in den Griff zu bekommen. In manchen Fällen rechnet es sich durchaus, einen Schritt zurück auf das "Startfeld" zu machen und die Implementierung der gesamten Software, oder der relevanten Teile neu zu beginnen.

Bei einem anstehenden Technologie-Wechsel werden sich einige Fragen nicht stellen. Hier steht der Wunsch (oder der Zwang) im Vordergrund, auf eine neue Technologie zu wechseln. Die Gründe können unterschiedlicher Art sein:

Fehlende Möglichkeiten
Effizienz-Einbußen
usw.

Treten tatsächlich Probleme auf (Performance, mangelnde Erweiterbarkeit), dann ist grundsätzlich Handlungsbedarf immer als dringend anzusehen. Können die Ursachen lokalisiert und dauerhaft gelöst werden (und das mit vertretbarem Aufwand) sollte darin investiert werden. Ist dies nicht der Fall, oder treten zusätzlich eigenartige Verhaltensweisen auf, dann kann durchaus an eine Neuentwicklung gedacht werden.

Auch eine Neuentwicklung bringt so ihre Probleme mit sich. Vor allem, wenn bereits Releases in Umlauf sind. Idealerweise sollten sich Schnittstellen nicht ändern. Bei einem Redesign bzw. einer Neuimplementierung ist dies allerdings nicht immer möglich. Um den neuen Anforderungen gerecht zu werden muss auch die API Neuerungen erfahren. Dies bringt sehr oft eine Inkompatibilität zu vorhergehenden Versionen mit sich. So in einigen Bereichen auch bei der geplanten Workflow Foundation. Damit gewisse Anforderungen erfüllt werden können, muss ein Bruch zur "alten" Version stattfinden. Er ist unvermeidbar. Schlecht für all diejenigen, welche die aktuelle Version einsetzen. Gut für diejenigen, die es schaffen, erfolgreich auf die künftige Version zu migrieren bzw. überhaupt erst mit der neuen Version einsteigen.

Was ich ingesamt damit sagen möchte: Ist von einer Neuentwicklung der eigenen Anwendung die Rede, verfallen die meisten sofort in Panik. Bisheriges kann doch nicht so schlecht sein. Bis jetzt wurden alle Anforderungen erfüllt. Reine Abwehrhaltung. Die Anforderungen ändern sich. Auch die zugrunde liegende Technologie. Irgendwann kommt jedes Produkt an seine Grenze. Idealerweise wird bereits frühzeitig erkannt, wann dies der Fall sein wird. Erhöht sich der Erweiterungsaufwand, wird die Anwendung oder das Framework instabil sollte man auch in diese Richtung denken. Nicht jede Neueentwicklung bedeutet, dass das bisher Geleistete schlecht ist. Man muss agieren um auch zukünftig konkurrenzfähig zu sein/bleiben. Eine Kosten/Nutzen-Rechnung sollte jedoch nicht ausser Augen gelassen werden.

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

Ungarische Notation als Problemlieferant

28.10.08 - Entwicklung, Diskussionen
Beitrag von Norbert Eder

Beim Durchsehen von Sourcecode fällt mir doch recht oft auf, dass die ungarische Notation noch häufig verwendet wird. Das, obwohl an vielen Stellen davon abgeraten wird. Was genau ist die ungarische Notation?

Bei der ungarischen Notation erhalten Variablen ein Präfix. Dieses Präfix beschreibt, von welchem Typ die Variable ist. Beispiele:

strName
dtBirthday
intCounter

Den Namen hat die ungarische Notation vom Erfinder: Charles Simonyi, einem Ungarn.

Doch warum wird von der ungarischen Notation abgeraten?

Hier gibt es eine ganz klare Antwort: Es gibt keinen Standard für die Wahl der Präfixe. Dies bedeutet, dass unterschiedlichste Präfixe für dieselben Typen verwendet werden und es daher nicht immer auf den ersten Blick ersichtlich ist, welcher Typ wirklich gemeint ist. Es entstehen dadurch also Verständnisprobleme, wo sie eigentlich nicht sein sollten.

Die Verwendung der ungarischen Notation sollte daher nie in Projekten verwendet werden, an denen unterschiedliche Unternehmen, Zweigstellen etc. involviert sind. Es mag zwar für ein Unternehmen, eine Zweigstelle eine Definition geben, diese muss jedoch nicht für andere gelten oder anderen bekannt sein.

Daher auch immer wieder der Rat, die ungarische Notation nicht zu verwenden.

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

Durchdachte Prozesse als Heilmittel in der Softwareentwicklung?

27.10.08 - Entwicklung, Diskussionen, Projektmgmt.
Beitrag von Norbert Eder

Die meisten Softwareschmieden haben das gleiche Problem: Die Softwareentwicklung durchläuft keinen klar definierten Prozess. Egal ob Feature, Bug oder Idee. Alles fließt in eine einige Datenhalde, die dann abgearbeitet wird. Prioritäten werden in den wenigsten Fällen vergeben. Ebenfalls finden sich oft kaum Beschreibungen, genaue Fehlerhinweise oder gar Konkretisierungen der gewünschten Anforderungen.
Immer wieder gerate ich in Unterhaltungen, in denen dieses Thema aufgegriffen wird. Meist ist man sich einig, dass am jeweiligen Software-Prozess Änderungen vorgenommen werden müssen. So einfach es theoretisch ist, treten doch in der Praxis zahlreiche Probleme auf. Wie kann man dem also entgegen wirken?

Eine der wichtigsten Aufgaben ist wohl, zu identifizieren was schief läuft und wo Handlungsbedarf besteht. Auch das klingt einfach und ist es schlussendlich nicht. Wo finden sich Ansatzpunkte?

Projektverantwortliche (unabhängig ob der Geschäftsführer, der Program Manager, der Project Manager usw.) finden sich immer wieder in der Situation, dass sie den aktuellen Entwicklungsstand nicht beurteilen können. So wird an der Businesslogik geschraubt, mit kaum sichtbaren Ergebnissen oder Erweiterungen finden ihren Weg in die Software, die auch erst im letzten Schritt eine Auswirkung auf das User Interface haben. Meist sehr unbefriedigend für denjenigen, der das Produkt seinen Kunden schmackhaft machen soll.

Die Entwickler auf der anderen Seite sehen sich damit konfrontiert, dass die Software im halbfertigen Zustand begutachtet wird, wobei doch gemachte Erweiterungen noch gar nicht sichtbar sein können. Aufgaben mit höchster Priorität werden verteilt, die aktuell nicht zum Entwicklungsstand passen und daher auch nicht wahrgenommen werden können. Zustätzlich werden in ein etwaiges vorhandenes System alle Punkte eingepflegt, sodass sie für jeden Entwickler sichtbar sind (eventuell sogar noch mit Benachrichtigung). Dies bringt definitiv Unruhe in das Entwickler-Team, da man sich automatisch Gedanken über Dinge macht, die zum aktuellen Zeitpunkt nicht relevant sind.

Resultat sind langwierige Diskussionen. Entwickler in ihrer technischen Welt auf der einen Seite und der wirtschaftliche Bereich auf der anderen. Wie gesagt: Stundenlanges Gerede. Jeder "spricht in seinen Worten". Die Annäherung geht gegen null. Schlussendlich glaubt jeder, die andere Seite verstanden zu haben, um bei nächster Gelegenheit zu merken, dass dem nicht der Fall ist.

Nun die entscheidende Frage: Wie kann Ordnung in dieses Chaos gebracht werden?

Es gilt den Wildwuchs von Informationen Herr (oder Frau) zu werden. Der Entwickler soll für ihn relevante Informationen zu Gesicht bekommen und nicht mehr. Dies bedeutet, dass - wie in agilen Prozessen üblich - Releasetermine definiert werden müssen. Jedes Release enthält eine klar abgegrenzte Feature-Liste. Diese wird mit Prioritäten versehen und entsprechend abgearbeitet. Zusätzliche (neue) Anforderungen werden für das aktuelle Release nicht mehr aufgenommen, sondern neuen Releases zugewiesen. Wichtig ist hier, dass die neuen Funktionalitäten klar definiert werden (genaue Spezifikationen müssen definitiv vorhanden sein, ebenfalls Use Cases usw.).

Wird ein Releaseplan zusammengestellt obligt es dem Entwickler eine Machbarkeitsanalyse durch zu führen und entsprechend Rückmeldung zu geben. Bei Machbarkeit erfolgt eine Aufwandsschätung. Darauf hin kann der "Auftraggeber" seine Prioritäten vergeben und festlegen, für welches Release dieser Punkt Relevanz hat.

Der Vorteil liegt klar auf der Hand:

Der Projektverantwortliche hält einen klaren Releaseplan in der Hand. Er weiß zu jeder Zeit, welche Features umgesetzt werden können und welche aus Zeitgründen in ein anderes Release verschoben werden müssen. Zusammen mit entsprechenden Auswertungen und Erfahrungswerten gelangt er zur Information, wieviel tatsächlich von seinem Team umgesetzt werden kann.
Der Entwickler erhält eine Liste von Punkten die umzusetzen sind. Änderungen (manche lassen sich leider nicht vermeiden, Blocker o.ä.) sind nicht vorgesehen. Er kann sich auf seine Aufgaben konzentrieren und muss sich mit neuen Aufgaben erst bei der Erstellung des nächsten Release-Planes beschäftigen. Er hat den Kopf für aktuelle Aufgaben frei.
Einer muss schließlich die Software verkaufen. Er hat aussagekräftige Informationen zur Hand, die er dem Kunden vorlegen kann. Zudem ist jedoch auch klar, dass mal eben ein Feature nicht untergeschoben werden kann. Dieses muss durch den Prozess durch und wird je nach Priorität und Aufwand einem bestimmten Release zugeordnet. Schwerwiegende Fehler sind davon natürlich ausgenommen. Natürlich kann sich durch die Wichtigkeit des Kunden bzw. des Punktes auch der nächste Release-Plan entsprechend verändern. Der aktuell vorliegende Plan sollte davon jedoch unberührt bleiben.

Dieser Prozess ist natürlich nur einer von vielen. An allen Ecken und Enden muss gefeilt werden. Idealerweise setzen sich jedoch Projektverantwortliche und Entwickler an einen Tisch und versuchen einen gangbaren Weg zu finden. Die Bedürfnisse sind auf beiden Seiten die gleichen:

Jeder möchte wissen, was im nächsten Release implementiert ist und was nicht.
Wie sieht es mit den nächsten Schritten aus? Was ist für zukünftige Releases geplant?
Wann sind wir fertig?
usw.

Fragen über Fragen. Ein sauberer Prozess kann nicht auf alles eine Antwort geben. Aber viele Antworten können erleichtert werden und durch zusätzliche Messungen kann festgestellt werden, wieviele Manntage tatsächlich innerhalb eines Monats umgesetzt werden können, was das für die Roadmap des Produktes bedeutet und viele weitere Angaben, welche die Planung erheblich erleichtern.

Vielleicht sind Projektverantwortliche und Entwickler in ihren Wünschen doch nicht so weit voneinander entfernt ...

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

Zurück Weiter