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.

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 - 1483 mal angesehen | 0 Trackbacks | Permalink | Trackback-URL

Projekte, Projekte, Projekte ...

27.12.08 - Blog-Intern, Entwicklung, .NET, WPF, ASP.NET, Silverlight
Beitrag von Norbert Eder

... was fehlt ist die Zeit dazu. Aber die muss man sich bekanntlich ja nehmen! Die Feiertage nach Weihnachten und rum um Silvester eignen sich wunderbar, neben Familie und Co. an Projekten zu arbeiten bzw. an bestehenden bzw. zukünftigen Projekten zu planen. Schließlich nähert sich 2009 auch mit großen Schritten und bekanntlich sollte man sich dann doch etwas vornehmen. Was also schwebt mir so im Kopf herum?

WPF-Blogger

WPF-Blogger hat einen recht guten Start hingelegt. Viele Anregungen fanden ihren Weg zu mir und dem möchte ich natürlich nachkommen, zumal sich derer viele mit meinen eigenen Vorstellungen decken. Anfang 2009 wird es ein größeres Update der Site geben. So kommen einige neue Funktionen hinzu, bishere werden verbessert. Auf vielfachen Wunsch wird auch eine weitere Sprache ihren Weg ins WPF-Blogger-System finden. Weiters freut es mich, dass die Software wohl auch für ein weiteres .NET Community Projekt verwendet werden wird - und dieses wird nicht von mir sein.

.NET BlogBook

Das .NET BlogBook erfreut sich nach wie vor großer Beliebtheit. Und das, obwohl die letzten Veröffentlichungstermine leider nicht eingehalten werden konnten. Der Hauptgrund hierfür war wohl die bis dato aufwändige Pflege des Buches. Hier wird es eine Konzeptänderung geben, die in den nächsten Wochen und Monaten in die Realität umgesetzt werden wird. Ziel ist es, den Aufwand auf meiner Seite zu verringern und dem Leser einen höheren Komfort, als auch höhrere Aktualisierungsraten zu bieten.

.NET Casts

Auf .NET Casts veröffentlichten Kai Gloth und ich vor allem 2007 viele Podcasts. 2008 ist dieses Projekt ziemlich eingeschlafen, da zum einen die gewünschten technischen Mittel nicht zur Verfügung standen und zusätzlich Kai unter massivem Zeitmangel litt. Auch hier habe ich mir Gedanken zu einem neuen Konzept gemacht. Zusammen mit weiteren Persönlichkeiten der deutschsprachigen .NET Szene könnte diese Site 2009 wieder ein Revival feiern.

.NET GUI

Meine Community zur .NET basierten Oberflächen-Programmierung hat es 2008 ganz gut geschafft, sich zu etablieren. 2009 möchte ich diesen Trend fortführen und den Besuchern und Mitgliedern noch mehr Inhalte bieten. Erklärtes Ziel ist es definitiv, die größte Community rund um WPF und Silverlight zu werden bzw. den aktuellen Spitzenplatz zu erhalten.

Trickkiste

Die beliebteste Seite meiner Blogs ist wohl die Trickkiste. Abgesehen von der Home wird diese Page am Häufigsten aufgerufen. Ist die gebotene Funktionalität zum aktuellen Zeitpunkt doch eher als gering einzuschätzen, möchte ich die Trickkiste um zusätzlichen Inhalt und einige neuen Funktionen erweitern.

Wechsel Blogsystem

Bis jetzt hat mein verwendetes Blogsystem ganz gute Dienste geleistet. Mit der Zeit steigen allerdings die Anforderungen. Bedingt durch sinkende Ladezeiten, vermissten Komfort und der fehlenden Möglichkeit, den Windows Live Writer zu verwenden, muss ich wohl oder übel auf eine neue Software umsteigen. Dies ist jedoch kein leichtes Unterfangen, als dass die alten Links weiter bestehen bleiben sollten. Zur Datenübernahme habe ich bereits eine kleine Anwendung geschrieben, die auch bereits gut funktioniert. Diese muss noch an einigen Stellen abgeschliffen werden, dann steht einem Umstieg nichts mehr im Wege. Als System werde ich wohl Wordpress einsetzen, da mir die vorhandenen auf .NET basierenden Systeme nicht ausreichend Komfort anbieten.

Windows Presentation Foundation / Silverlight

Die Windows Presentation Foundation (WPF) und Silverlight waren im letzten Jahr mein Steckenpferd und werden es auch 2009 bleiben. So sind für diese Gebiete nicht nur einige Zeitschriften-Artikel geplant, sondern auch ausführliche Artikel und How-To's auf meinem Blog. Auch möchte ich generell zu diesem Thema weitere Hilfen anbieten. Dazu wird es in den nächsten Wochen zusätzlich zum Blog auch wieder eine Main-Page geben, nachdem diese über einen längeren Zeitraum nicht verfügbar war.

Weitere Projekte

Als Trumpf halten ich natürlich noch ein paar Projekte zurück, die zu gegebener Zeit bekannt gegeben werden. Eines davon hat aktuell höchste Priorität und wird wohl im ersten Quartal 2009 zu bewundern sein.

Ja, 2009 wird ein interessantes Jahr. Viel ist geplant und viel will auch erreicht werden. Für mich essentiell wird 2009 die Zusammenarbeit mit weiteren Experten aus der deutschsprachigen .NET Szene. Eventuell läßt sich auch Microsoft selbst von der einen oder anderen Idee begeistern. Man darf auf jeden Fall gespannt sein.

PS: Wer Ideen zu meinen anvisierten Projekten hat, oder selbst Projekte am Start hat, welche sich mit meinen überschneiden: Auf jeden Fall melden. Gemeinsam läßt sich nun mal wesentlich mehr und sinnvolleres erreichen.

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

Hilfe! Ich werde verändert!

22.12.08 - Entwicklung, .NET, Grundlagen, Security
Beitrag von Norbert Eder

Im Artikel Ich werde beklaut! habe ich darüber geschrieben, wie einfach Ressourcen aus einer WPF-Anwendung entwendet werden können und warum es sich - aus meiner Sicht - nicht lohnt, diese Inhalte mit hohem Aufwand zu schützen.

Nun ist das Stehlen von Ressourcen (Layouts, Styles, Grafiken, etc.) wohl eine der häufigsten Arten, aber nicht die Schlimmste. Seltener, aber dennoch nicht zu unterschätzen ist es, wenn Software von Fremden bewußt verändert wird. Für viele Anwendungsbereiche mag das vielleicht kaum eine Relevanz haben, aber gerade im Security-Bereich kann dies äußerst unangenehme Folgen mit sich bringen. Aber wie kann man sich davor schützen?

Strong Named Assemblies

Der erste Ansatz ist, den eigenen Assemblies einen Strong Name zu verpassen. Die Identität der Assembly besteht hierbei aus ihrem Namen, der Versionsnummer und Informationen der Kultur (sofern diese gesetzt wurde) inklusive eines öffentlichen Schlüssels (Public Key), als auch einer digitalen Signatur. Dies ist ein einfacher Weg, der frei Haus durch .NET mitgeliefert wird, hat jedoch so seine Tücken als dass ein Strong Name sehr einfach entfernt werden kann. Danach kann die Software normal verwendet und auch verändert werden. Die veränderte Assembly kann zwar ohne Signatur nicht im den Global Assembly Cache (GAC) installiert werden, was aber in vielen Fällen auch nicht vorgesehen ist.

Nichts desto trotz sollte Strong Named Signing dennoch verwendet werden, da es doch eine zusätzliche Hürde darstellt und es daher für viele weniger attraktiv ist, die Software zu verändern. Alle Angreifer können damit allerdings nicht ausgeschlossen werden.

Wie vor Veränderung schützen?

Ein vollständiger Schutz ist nie möglich. Man kann es dem Angreifer aber erheblich schwerer machen. Es gibt zahlreiche Tools, die hier Abhilfe schaffen wollen. In diesem Zusammenhang werden oft Obfuscating-Tools genannt, die jedoch nicht vor Veränderung schützen. Andere Produkte fahren weit größere Geschütze auf. Eines davon ist CodeVeil. Dieses Tool bietet nicht nur Obfuscating-Mechanismen, sondern verschlüsselt zusätzlich auch MSIL. Weiters werden entschlüsselte Informationen nicht im selben Speicherbereich der Assembly geladen, wodurch eine Speicher-Dump erheblich erschwert wird.

Es gibt also durchaus Mechanismen, um sich bestmöglich zu schützen. Eine 100%ige Garantie wird es allerdings nie geben. Man kann also immer nur versuchen, einen Schritt vor den bösen Jungs zu sein bzw. es ihnen so schwer zu machen, dass die Attraktivität, die Software zu manipulieren, möglichst gering ist.

Wichtig ist zusätzlich, dass man sich als Entwickler über die Möglichkeiten der Angreifer informiert. Einen interessanten Einstieg bietet hier der Artikel Assembly Manipulation and C#/VB.NET Code Injection.

PS: Viele Tools unterstützen in den aktuellen Versionen weder WPF noch Silverlight. Hier bleibt zu hoffen, dass die Hersteller Mittel und Wege finden, uns Entwickler auch bei diesen Technologien mit Security zu unterstützen.

Kommentar hinzufügen | 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 - 889 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 - 1211 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 - 809 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 - 771 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 - 858 mal angesehen | 0 Trackbacks | Permalink | Trackback-URL

Entwickler zu Dumping-Preisen

15.09.08 - Entwicklung, Diskussionen
Beitrag von Norbert Eder

Da sehe ich doch heute glatt bei einer Google-Anzeige folgenden Text:

Finden Sie Top-Qualifizierte C#-Entwickler ab 6 Euro/Stunde

Das muss man sich auf der Zunge zergehen lassen. Sechs Euro pro Stunde. Für viele sicher genau DAS Argument, einen Klick für das gesamte AdWords-System zu produzieren. So billig kommt man doch sonst nie zu einem C#-Entwickler. Aber bekommt man hier auch die entsprechende Qualität? Wohl eher nicht.

Denn bei 25 Arbeitstagen zu je 8 Stunden bewegen wir uns hier bei genau 1.200 Euro. Da kommt noch die Steuer weg, Versicherung und natürlich auch sämtliche Aufwände (Equipment, Strom, Miete usw.). Wer also bitte arbeitet zu diesem Preis?

Davon abgesehen: Wieviel Qualität kann man für diesen Preis wirklich erwarten? Im Vergleich zu üblichen Preisen sind 6 Euro sogar unter Hungerlohn, d.h. ein wirklicher Experte auf seinem Gebiet wird sich zu diesem Preis nie und nimmer verkaufen.

Vermutlich lassen sich jedoch genügend darauf ein, da oft nur der Preis und nicht die tatsächliche Qualität zählt. Dass das Projekt damit drei Mal so lange dauert, von Fehlerfreiheit bei weitem keine Rede sein kann und auch sonst zur Genüge Probleme auftreten werden, ist eine andere Geschichte.

Ich kann mich über solche Angebote nur wundern ... und auch über diejenigen, die darauf einsteigen.

6 Kommentare - 1123 mal angesehen | 0 Trackbacks | Permalink | Trackback-URL

Zurück Weiter