Letzten Abend ging mir mal wieder eine Idee durch den Kopf, die ich einfach nicht wieder los bekommen habe und die ich natürlich wieder haarklein ausarbeiten musste. Grundsätzlich gehe ich dabei von 2 Annahmen aus:

• Technologie aus dem IT-Sektor steigt permanent in Abstraktionsebenen
• Programmierer/Netzwerktechniker/Whatever lernen permanent dazu, bzw. werden in dem was sie tun besser, solange sie sich ernsthaft darum kümmern was sie in ihrem Beruf so tun und selbst besser werden wollen

Im Folgenden werde ich für Personen die sich nicht mehr weiterentwickeln den Begriff “Code-Monkey” verwenden, es handelt sich dabei um Personen mit stagnierenden Fähigkeiten, die kein wirkliches Interesse mehr für ihren Beruf aufbringen. Dabei werde ich mal einfach ignorieren dass diese Erscheinung durchaus nicht an Code gebunden ist (sprich: ich rede nicht nur von Programmierern) sondern wohl in der ganzen Branche (oder wahrscheinlich auch weit darüber hinaus) vorkommen wird.

Diese Grundlagen werde ich nun erstmal genauer ausführen und dann meine Schlüsse erläutern.

zu den Grundannahmen

Steigende Abstraktionsebene

Jegliche Software scheint sich immer weiter von den relativ statischen Grundlagen der Computertechnik zu entfernen, um flexiblere Funktionen anzubieten. Dies bedeutet einerseits dass die Verwirklichung von immer größeren Projekten immer einfacher wird, da flexiblere Werkzeuge zur Verfügung stehen, andernseits bedeutet es aber auch dass sich Technik in Zwiebelschichten übereinander legt und immer stärker verhüllt was auf den untersten Schichten wirklich passiert.

Ein leider viel zu selten beachteter Nebeneffekt ist leider dass diese Struktur auch immer dazu neigt langsamer zu sein als andere Lösungen, die der physikalischen Grundlage auf der die Technologie basieren, näher sind. (Ein Thema das ich an dieser Stelle wohl erstmal außen vor lassen, ein Rant darüber dass man auch vor 20 Jahren schon Texte schreiben konnte ohne 20sec. auf den Startvorgang des Editors zu warten kommt dann wohl mal wieder gesondert)

permanentes Lernen

Diese Grundlage stellt gleich den wackeligsten Punkt meiner Theorie dar. Natürlich habe ich nicht wirklich die Möglichkeit diese Behauptung mit wahnsinnig vielen Beobachtungen belegen zu können. Wirklich dauerhaft beobachten kann ich dies wohl nur bei mir selbst, dort besitze ich auch die beste Möglichkeit um möglichst genau vergleichen zu können welches Wissen ich mir wann, wo und auf welche Art angeeignet habe.
Bei anderen Personen kann ich allerhöchstens als Außenstehender versuchen den geschriebenen Code in seiner Qualität zu vergleichen, manchmal mag dies schon aufgrund des eigenen Unwissens um bestimmte Hintergründe unmöglich sein, an anderen Stellen wird es ganz einfach durch die eigenen Vorlieben beeinflusst sein. Je länger man mit jemandem zusammen arbeitet, desto stärker muss sich natürlich die Art der Lösungen, die man erzeugt, aneinander angleichen/anpassen.
Dies sorgt sicher für den Effekt dass man z.B. Quellcode den ein Kollege nach 3-4 Jahren zusammenarbeit produziert als “besser” oder zumindest “angenehmer” empfindet als Code den er geschrieben hat ohne zu wissen wer das jemals lesen wird, welchen Stil dieser verwendet oder gar über welche Wissensbasis er verfügt.

Weiterhin mag es durchaus eine Grenze geben, ab der man sich persönlich nicht weiterentwickeln kann, sei es aufgrund des eigenen, begrenzten Intellektes oder anderer Umstände. Bisher konnte ich noch keinen derartigen Effekt beobachten, bin mir aber auch ziemlich sicher dass jemand der von einem derartigem Effekt betroffen wäre, ihn auch nicht wahrnehmen würde oder sich dann zumindest in einer ernsthaften Motivationskriese befinden müsste.

Schlussfolgerungen

Da sich jeder IT-ler permanent in seinem Wissen und seinen Fähigkeiten verbessert, wird er mit dem Verlauf der Komplexitätsebenen auf seinem Tätigkeitsfeld immer besser werden. Verstärkt wird dies durch eben jene Komplexitätsebenen, da man meist eine neue Ebene besser verwenden kann, wenn man die ihr zugrunde liegende Technologie besser verstanden hat.
Ein typisches Beispiel wäre dass es von Vorteil ist wenn man weiß wie eine Datenbank funktioniert, während man ein ORM verwendet. (Sonst kommt z.B. sowas raus)
Gebremst wird dieser Verlauf wohl hauptsächlich durch ein “Aussteigen” der Personen, indem sie entweder die Lust an persönlicher Weiterentwicklungen, bzw. den Wissensdrang nach Hintergründen verlieren, den Tätigkeitsbereich wechseln oder indem sie an persönliche Grenzen stoßen, also z.B. mit einer neuen Komplexitätsebene nicht zurecht kommen.

Je länger und interessierter sich also jemand auf dem Sektor beschäfftigt, umso qualifizierter wird er wohl sein, desto stärker steigt aber auch die Wahrscheinlichkeit dass er “aussteigt”. (Übertrieben formuliert: Nur die allerwenigsten Programmierer werden mehr als 100 Jahre Berufserfahrung sammeln.)
Von den ausgestiegenen Arbeitern werden nur die Stagnierenden (oder, sollte das möglich sein, diejenigen die sich verschlechtern) in der Branche bleiben.

eigentliche Theorie

Je mehr Abstraktionsebenen ein IT-Arbeiter in seiner Karriere miterlebt hat und je mehr er sich für sein Fachgebiet interessiert, desto fähiger ist er auf diesem Gebiet. Je fähiger/erfahrener man jedoch wird, desto höher die Wahrscheinlichkeit dass er zu einem reinen “Code-Monkey” wird und nur noch desinteressiert seinen Job macht und in seiner Entwicklung stagniert.
Oder noch kürzer:

Je länger die Berufserfahrung, desto höher die Fähigkeitsstufe, desto höher aber auch die Wahrscheinlichkeit auf einen “Code-Monkey”.

Abschließende Bemerkungen

Natürlich habe ich hier noch keinerlei Randerscheinungen beachtet, so kann es z.B. durchaus sein dass jemand nach einiger Zeit als Code-Monkey doch wieder interesse aufbringt oder (und diese Wahrscheinlichkeit ist sogar ziemlich hoch) bereits aus anderen Gründen, als ernstem Interesse am Gebiet, in die Branche wechselt/ausgebildet wird und so seine Laufbahn bereits als Code-Monkey beginnt.

Code-Monkey ist absichtlich ein abwertend gemeinter Begriff, da ich diese Variante weit weniger erstrebenswert ansehe als sich ernsthaft dafür zu interessieren was man tut.
Code Monkeys hingegen als Gesamterscheinung sind durchaus nicht nur negativ zu betrachten, es gibt im täglichen Leben nunmal weit mehr langweilige Tipparbeit und Routinejobs, in denen sich ernsthaft interessierte Zeitgenossen wohl weit weniger wohl fühlen als ein Code Monkey, der sich vlt. sogar mit Routine abgefunden hat. Sie mögen nicht mal annähernd guten Code schreiben, doch sie schreiben verdammt viel davon. Auch wenn jemand besser qualifiziertes also vlt. doppelt so viel Arbeit erledigt, die dann wiederrum nur die Hälfte an Wartungsarbeit verursacht, könnten Code-Monkeys diese Arbeit genauso erledigen, einfach weil es erheblich mehr von denen gibt.

Also ich hab ja in letzter Zeit viel ebensolche mit dem Beheben von Bugs^Wzufällig entstandenen Zusatzfunktionen verbracht. Bei dieser Tätigkeit kommt man immer wieder an Stellen bei denen man denkt “WTF? Wie hab ich das übersehen können?” oder sonst irgendwie spontan den Wunsch entwickelt mit dem Kopf eine Wand aus dem Weg zu räumen.
Da draußen, im großen, bunten Intarweb gibts aber Schilderungen von Problemen die alles in den Schatten stellen was mir so tagtäglich vor das Keyboard läuft. Ein paar besonders schöne Exemplare will ich euch heute mal zeigen…

Die ersten beiden stammen aus dem Android-Umfeld:

• datumsabhängige Qualität der Autofocus-Funktion
• Nach einem Neustart wird jedes eingegebene Wort, im Hintergrund, unbemerkt, mit root-Rechten als Befehl interpretiert

Einen weiteren, besonders schönen hat Chronodd entdeckt:
IE-Lookahead-Bug
um die Funktionalität mal zusammenzufassen:

The incorrect behavior occurs if your page contains a JavaScript URL which spans exactly the 4096th byte of the HTTP response. If such a URL is present, under certain timing conditions the lookahead downloader will attempt to download a malformed URL consisting of the part of the URL preceding the 4096th byte combined with whatever text follows the 8192nd byte, up to the next quotation mark. Web developers encountering this problem will find that their logs contain requests for bogus URLs with long strings of URLEncoded HTML at the end.

Zum Abschluss noch eine alternative Variante wie man seine Funktionen benennen kann.. erinnert mich ziemlich stark an unsere Idee während des Studiums doch alle Funktionen nur noch TLA/XTLA/SXTLA oder ähnliches zu nennen. Die Idee dann aber in Produktivcode durchzuziehen hat schon eigentlich wieder einen balls-of-steel-award verdient.

Bei solchen Aktionen finde ich den Begriff “Quählkot” doch ziemlich treffend…

Sichere Software gewinnt zunehmend an Bedeutung. Sicher im Sinne von „extrem schwer angreifbar“ (Security) ebenso wie im Sinne von „extrem zuverlässig“ (Safety). Das macht es erforderlich, Sicherheitsaspekte bereits in den Entwicklungsprozess der Software zu integrieren, anstatt die Sicherheit erst nachträglich „reinzupatchen“.

Um Abhilfe zu schaffen, haben sich zahlreiche Unternehmen in einem Verein – dem International Secure Software Engineering Council (ISSECO) – zusammengeschlossen. Und dort einen zertifizierbaren Standard für sichere Softwareentwicklung entwickelt.

Will man das Problem der Sicherheitslücken und Qualitätsmängel in Softwareprodukten an der Wurzel packen, muss das Thema Sicherheit in den Entwicklungsprozess integriert werden, um so frühzeitig der Entstehung von Sicherheitslücken entgegenzuwirken.

Das hierfür notwendige Wissen zur Vermeidung von Sicherheitslücken ist jedoch bis heute nur ein Randthema in der Ausbildung von Softwareentwicklern. Auch wenn Fachverbände wie der Arbeitskreis Software-Qualität und -Fortbildung oder die Gesellschaft für Informatik hier bereits seit längerem Verbesserungen anmahnen. Zudem lässt die zunehmende Komplexität von Softwareprodukten erwarten, dass das Ausmaß der Bedrohungen durch Sicherheitslücken und Qualitätsmängeln in den kommenden Jahren weiter zunehmen wird.

Der ISSECO hat daher einen Standard sowie ein Fortbildungscurriculum (ISSECO Certified Professional for Secure Software Engineering – CPSSE) entwickelt, um diese Lücke zu schließen. Das Thema Sicherheit soll dadurch zum selbstverständlichen Bestandteil jedes Softwareentwicklungsprozesses werden. Dieser internationale Zertifizierungsstandard für sichere Softwareentwicklung soll in der Softwareindustrie etabliert werden, um den Anwendern Sicherheit bei der Verwendung von Softwareprodukten zu garantieren und so auch verlorenes Vertrauen in die Softwarequalität zurück zu gewinnen.

Inhalte des Curriculums zur sicheren Softwareentwicklung sind Themen wie die Angreiferperspektive sowie die Kundenperspektive auf Software, Thread Modeling, Methoden sicherer Softwareentwicklung und Lebenszyklusmodelle für Software, Anforderungsanalyse, sicheres Design von Software, sicheres Testen, sicherer Rollout, Reaktion auf Angriffe und Qualitätsmängel sowie Sicherheit mit Metriken transparent machen. Dies wird entlang der Etappen des Softwareentwicklungsprozesses verdeutlicht:
•    Requirements Engineering
•    Design und Spezifikation
•    Programmierung und Test
•    Evaluierung, Distribution & Maintenance

Erste Schulungsangebote zum CPSSE werden derzeit am deutschen Markt etabliert. Zielgruppen sind Anforderungsanalysten, Softwarearchitekten, Designer, Entwickler, Softwarequalitätsmanager, Softwaretester, Projektmanager – kurz alle, die entscheidend an der Entwicklung von guter Software beteiligt sind.

Wenn sich Ideen wie der CPSSE im Markt durchsetzen, kann dies ein wichtiger Schritt zu sicherer und qualitativ hochwertigerer Software sein.

Sichere Software gewinnt zunehmend an Bedeutung. Sicher im Sinne von „extrem schwer angreifbar“ (Security) ebenso wie im Sinne von „extrem zuverlässig“ (Safety). Das macht es erforderlich, Sicherheitsaspekte bereits in den Entwicklungsprozess der Software zu integrieren, anstatt die Sicherheit erst nachträglich „reinzupatchen“.

Um Abhilfe zu schaffen, haben sich zahlreiche Unternehmen in einem Verein – dem International Secure Software Engineering Council (ISSECO) – zusammengeschlossen. Und dort einen zertifizierbaren Standard für sichere Softwareentwicklung entwickelt.

Will man das Problem der Sicherheitslücken und Qualitätsmängel in Softwareprodukten an der Wurzel packen, muss das Thema Sicherheit in den Entwicklungsprozess integriert werden, um so frühzeitig der Entstehung von Sicherheitslücken entgegenzuwirken.

Das hierfür notwendige Wissen zur Vermeidung von Sicherheitslücken ist jedoch bis heute nur ein Randthema in der Ausbildung von Softwareentwicklern. Auch wenn Fachverbände wie der Arbeitskreis Software-Qualität und -Fortbildung oder die Gesellschaft für Informatik hier bereits seit längerem Verbesserungen anmahnen. Zudem lässt die zunehmende Komplexität von Softwareprodukten erwarten, dass das Ausmaß der Bedrohungen durch Sicherheitslücken und Qualitätsmängeln in den kommenden Jahren weiter zunehmen wird.

Der ISSECO hat daher einen Standard sowie ein Fortbildungscurriculum (ISSECO Certified Professional for Secure Software Engineering – CPSSE) entwickelt, um diese Lücke zu schließen. Das Thema Sicherheit soll dadurch zum selbstverständlichen Bestandteil jedes Softwareentwicklungsprozesses werden. Dieser internationale Zertifizierungsstandard für sichere Softwareentwicklung soll in der Softwareindustrie etabliert werden, um den Anwendern Sicherheit bei der Verwendung von Softwareprodukten zu garantieren und so auch verlorenes Vertrauen in die Softwarequalität zurück zu gewinnen.

Inhalte des Curriculums zur sicheren Softwareentwicklung sind Themen wie die Angreiferperspektive sowie die Kundenperspektive auf Software, Thread Modeling, Methoden sicherer Softwareentwicklung und Lebenszyklusmodelle für Software, Anforderungsanalyse, sicheres Design von Software, sicheres Testen, sicherer Rollout, Reaktion auf Angriffe und Qualitätsmängel sowie Sicherheit mit Metriken transparent machen. Dies wird entlang der Etappen des Softwareentwicklungsprozesses verdeutlicht:
•    Requirements Engineering
•    Design und Spezifikation
•    Programmierung und Test
•    Evaluierung, Distribution & Maintenance

Erste Schulungsangebote zum CPSSE werden derzeit am deutschen Markt etabliert. Zielgruppen sind Anforderungsanalysten, Softwarearchitekten, Designer, Entwickler, Softwarequalitätsmanager, Softwaretester, Projektmanager – kurz alle, die entscheidend an der Entwicklung von guter Software beteiligt sind.

Wenn sich Ideen wie der CPSSE im Markt durchsetzen, kann dies ein wichtiger Schritt zu sicherer und qualitativ hochwertigerer Software sein.

Festplatten sind heute ja wirklich groß und bieten meist mehr als genug Platz. Ebenso sind aber auch die Dateigrößen für HD Filme, hochauflösende Fotos, Spiele, Programme usw. hoch gegangen. Eben weil man es sich jetzt erlauben kann auch. Allerdings ist das trotzdem kein Grund unnötige Dateien auf der Festplatte schlummern zu lassen. Wenn die Festplatte mehr suchen muss, dauert es länger und man selbst verliert bei zu vielen Dateien auch den Überblick.

Eine gute Möglichkeit mal zu schauen was denn nun so viel Platz auf der Festplatte belegt bieten zwei Freeware Tools, welche die Dateien nach Größe sortiert grafisch darstellen. Beide lassen einen zu Beginn auswählen welchen Bereich einer Festplatte man durchsuchen möchte, und zeigen dann in entsprechenden großen grafischen Blöcken die Dateien an, und lassen einen so nicht mehr verwendete Dateien aufspüren und löschen.

Beide Tools sind kostenlos, und es ist sicher Geschmacksache welches man lieber verwendet. Ich finde die direkte Listenansicht von Disk Inventory X auf jeden Fall ganz nett. Die Ansicht selbst ist bei beiden ähnlich. Beide Programme laufen einwandfrei unter Snow Leopard.

GrandPerspective

http://grandperspectiv.sourceforge.net/

Disk Inventory X

http://www.derlien.com/

Coverity, ein Anbieter von Werkzeugen zur Codeanalyse, gibt seit 2006 den „Coverity Scan Open Source Report“ (PDF, 2,8 MB) heraus, indem jährlich über die Entwicklung der Softwarequalität von quelloffener Software berichtet wird.

Die Ergebnisse basieren auf einer über drei Jahre gehenden Analyse von 60 Millionen Zeilen Code aus 280 Open-Source-Projekten, darunter Firefox, Linux, PHP, Ruby und Samba. Sie basieren auf Coveritys Scan-Service den die Firma OS-Entwicklern In Kooperation mit der Stanford University und in Zusammenarbeit mit dem US Department of Homeland Security kostenfrei anbietet. Ziel ist es, die Qualität von quelloffener Software grundsätzlich durch formalisierte Qualitätssicherung anzuheben. Nicht zuletzt deshalb, weil die US-Behörde in ihrer National Cyberspace Strategy (PDF, 0,5 MB) u.a. die Ziele der Aufdeckung vorhandener Qualitätsmängel und Sicherheitslücken in verbreiteten Softwaresystemen sowie die Entwicklung von Systemen mit einer geringerer Anzahl an Mängeln verfolgt.

So kam Coverity für 2008/09 zu dem Ergebnis, dass die Integrität, Qualität und Sicherheit von quelloffenem Code weiter zunimmt. Man fand seit 2006 mehr als 11.200 Fehler, die der Scan-Service in 180 zur Prüfung eingereichten Programmen entdeckt hat und die daraufhin beseitigt werden konnten. Insgesamt sieht die Firma einen Rückgang von 16 Prozent der in statischen Analysen festgestellten Fehler.

Coverity legt seiner Prüfung ein eigenes Reifegradmodell zugrunde, anhand dessen es geprüfte Software klassifiziert und zertifiziert. 144 Projekte laufen zurzeit in der ersten Stufe, 36 in der zweiten. Auf der höchsten Stufe finden sich derzeit vier OS-Projekte, darunter die Programmiersprache Ruby, der Samba-Server und das TOR-Netzwerk.

Insgesamt könne ein kontinuierlich steigendes Qualitäts- und Sicherheitsniveau im Bereich der Open-Source-Software festgestellt werden, so die Softwareprüfer. Die Entwickler in den OS-Ptrojeten treiben das Thema Softwarequalität aktiv voran. Die am häufigsten auftretenden Fehler der teilnehmenden Projekte waren über die Jahre hinweg NULL-Pointer-Variablen, Ressourcenlöcher und unabsichtlich nicht beachtete Expressions. Etliche OS-Projekte erreichten bereits den Status „defect-free“, d.h. man fand gar keine Fehler mehr.

Daneben bietet Coverity auch eine auf den Qualitätsprüfungen basierende Architekturbibliothek an, in der Architekturdaten von Anwendungen sowie Diagramme zu über 2500 Open-Source-Projekten frei zugänglich hinterlegt sind. Die Architektur-Bibliothek soll Entwicklern zugutekommen, die quelloffene Software in ihre eigenen Applikationen integrieren wollen und dazu die Architektur bekannter Projekte studieren möchten, um ein tieferes Verständnis der Struktur und zu den Fähigkeiten der Software zu erhalten. Sie kann ebenso bei Sicherheits- und Qualitätsaudits als Referenz herangezogen werden. Die Informationen werden unter einer Creative-Commons-Lizenz (CC-BY) bereitgestellt.

Coverity, ein Anbieter von Werkzeugen zur Codeanalyse, gibt seit 2006 den „Coverity Scan Open Source Report“ (PDF, 2,8 MB) heraus, indem jährlich über die Entwicklung der Softwarequalität von quelloffener Software berichtet wird.

Die Ergebnisse basieren auf einer über drei Jahre gehenden Analyse von 60 Millionen Zeilen Code aus 280 Open-Source-Projekten, darunter Firefox, Linux, PHP, Ruby und Samba. Sie basieren auf Coveritys Scan-Service den die Firma OS-Entwicklern In Kooperation mit der Stanford University und in Zusammenarbeit mit dem US Department of Homeland Security kostenfrei anbietet. Ziel ist es, die Qualität von quelloffener Software grundsätzlich durch formalisierte Qualitätssicherung anzuheben. Nicht zuletzt deshalb, weil die US-Behörde in ihrer National Cyberspace Strategy (PDF, 0,5 MB) u.a. die Ziele der Aufdeckung vorhandener Qualitätsmängel und Sicherheitslücken in verbreiteten Softwaresystemen sowie die Entwicklung von Systemen mit einer geringerer Anzahl an Mängeln verfolgt.

So kam Coverity für 2008/09 zu dem Ergebnis, dass die Integrität, Qualität und Sicherheit von quelloffenem Code weiter zunimmt. Man fand seit 2006 mehr als 11.200 Fehler, die der Scan-Service in 180 zur Prüfung eingereichten Programmen entdeckt hat und die daraufhin beseitigt werden konnten. Insgesamt sieht die Firma einen Rückgang von 16 Prozent der in statischen Analysen festgestellten Fehler.

Coverity legt seiner Prüfung ein eigenes Reifegradmodell zugrunde, anhand dessen es geprüfte Software klassifiziert und zertifiziert. 144 Projekte laufen zurzeit in der ersten Stufe, 36 in der zweiten. Auf der höchsten Stufe finden sich derzeit vier OS-Projekte, darunter die Programmiersprache Ruby, der Samba-Server und das TOR-Netzwerk.

Insgesamt könne ein kontinuierlich steigendes Qualitäts- und Sicherheitsniveau im Bereich der Open-Source-Software festgestellt werden, so die Softwareprüfer. Die Entwickler in den OS-Ptrojeten treiben das Thema Softwarequalität aktiv voran. Die am häufigsten auftretenden Fehler der teilnehmenden Projekte waren über die Jahre hinweg NULL-Pointer-Variablen, Ressourcenlöcher und unabsichtlich nicht beachtete Expressions. Etliche OS-Projekte erreichten bereits den Status „defect-free“, d.h. man fand gar keine Fehler mehr.

Daneben bietet Coverity auch eine auf den Qualitätsprüfungen basierende Architekturbibliothek an, in der Architekturdaten von Anwendungen sowie Diagramme zu über 2500 Open-Source-Projekten frei zugänglich hinterlegt sind. Die Architektur-Bibliothek soll Entwicklern zugutekommen, die quelloffene Software in ihre eigenen Applikationen integrieren wollen und dazu die Architektur bekannter Projekte studieren möchten, um ein tieferes Verständnis der Struktur und zu den Fähigkeiten der Software zu erhalten. Sie kann ebenso bei Sicherheits- und Qualitätsaudits als Referenz herangezogen werden. Die Informationen werden unter einer Creative-Commons-Lizenz (CC-BY) bereitgestellt.

Microsoft ist bereits seit längerem bestrebt, sich bzgl. Sicherheit und Softwarequalität seiner Produkte als führend zu positionieren. Daher hat die Firma u.a. das Vorgehensmodell des „Security Development Lifecycle (SDL)“ entwickelt, um Entwicklern bei der weiteren Verbesserung der Qualität sicherheitsbezogener Eigenschaften ihrer Software für die Windows-Plattform zu unterstützen.

Der Microsoft Bin Scope Binary Analyzer überprüft binären Code darauf, ob alle empfohlenen und notwendigen Security Flags, Schutzmechanismen und Kontrollen vorhanden sind. Das stellt sicher, dass in Anwendungen nicht durch gängige Sicherheitsfehler beim Coding Schwachstellen und Sicherheitslücken implementiert werden.

Der Microsoft MiniFuzz File Fuzzer ist eine Lösung für Tester, die unerwartete Verhaltensweisen ihrer Anwendungen eingrenzen wollen. Der Fuzzer automatisiert Sicherheitsüberprüfungen und testet den Code mit zufällig erzeugten Eingabedaten um das Verhalten der Applikation bei deren Verarbeitung zu prüfen. Auf diesem Wege wird bereits sehr früh im Entwicklungsprozess festgestellt, ob etwa Programmabstürze als Sicherheitsrisiken untersucht werden müssen.

„SDL hat sich seit seiner Einführung als effizienter Prozess zur Steigerung der Softwarequalität bewährt“, so Prof. Dr. Sachar Paulus, Vorstandsvorsitzender der ISSECO (International Secure Software Engineering Council e.V.). „Dank der guten Methodologie und einfachen Umsetzbarkeit hat sich SDL mittlerweile bei vielen Entwicklern etabliert. Die beiden neuen Tools sind weitere Bausteine hin zu einer besseren, sichereren Softwareentwicklung“.

Hinzu kommen weitere Hilfen für Entwickler wie z.B. das SDL Process Template für Visual Studio Team System, das SDL Threat Modeling Tool, FxCop (ein Tool zur Analyse von.NET-Assemblies) sowie einige weitere Werkzeuge für die statische Codeanalyse mit Microsoft-Entwicklungsumgebungen.

Alle Tools können bei Microsoft im SDL Tools Repository kostenlos heruntergeladen werden.

Der Security Development Lifecycle ist ein Kernelement der Trustworthy Computing Initiative von Microsoft zur Verbesserung der Sicherheitseigenschaften seiner Produkte. Der Prozess wurde zunächst geschaffen, um firmenintern sichere Anwendungen zu liefern und Attacken besser widerstehen zu können. Jedes Produkt von Microsoft, das mit dem Internet kommuniziert oder für den Unternehmenseinsatz konzipiert ist, muss Angaben von Microsoft gemäß den SDL-Prozess durchlaufen.

Tom Köhler, Direktor Strategie Informationssicherheit Kommunikation bei Microsoft Deutschland hierzu: „Wir schützen damit unsere Plattform. Dazu gehört nicht nur, dass wir unsere eigenen Betriebssysteme und Anwendungen immer sicherer machen, sondern auch Partner und andere Anbieter dabei unterstützen. Gerade Anwendungen von Drittanbietern stehen immer mehr im Zentrum der Attacken durch Schadsoftware. Jeder Entwickler, ob Freiberufler, Microsoft Partner oder Firmenentwickler muss bereits im Designprozess darauf achten, dass seine Anwendungen in der Praxis sicher funktionieren. SDL hilft dabei“.

Kein Zweifel – der Security Development Lifecycle Prozess dürfte für Entwickler auf der Windows-Plattform zunehmend an Bedeutung gewinnen.

Microsoft ist bereits seit längerem bestrebt, sich bzgl. Sicherheit und Softwarequalität seiner Produkte als führend zu positionieren. Daher hat die Firma u.a. das Vorgehensmodell des „Security Development Lifecycle (SDL)“ entwickelt, um Entwicklern bei der weiteren Verbesserung der Qualität sicherheitsbezogener Eigenschaften ihrer Software für die Windows-Plattform zu unterstützen.

Der Microsoft Bin Scope Binary Analyzer überprüft binären Code darauf, ob alle empfohlenen und notwendigen Security Flags, Schutzmechanismen und Kontrollen vorhanden sind. Das stellt sicher, dass in Anwendungen nicht durch gängige Sicherheitsfehler beim Coding Schwachstellen und Sicherheitslücken implementiert werden.

Der Microsoft MiniFuzz File Fuzzer ist eine Lösung für Tester, die unerwartete Verhaltensweisen ihrer Anwendungen eingrenzen wollen. Der Fuzzer automatisiert Sicherheitsüberprüfungen und testet den Code mit zufällig erzeugten Eingabedaten um das Verhalten der Applikation bei deren Verarbeitung zu prüfen. Auf diesem Wege wird bereits sehr früh im Entwicklungsprozess festgestellt, ob etwa Programmabstürze als Sicherheitsrisiken untersucht werden müssen.

„SDL hat sich seit seiner Einführung als effizienter Prozess zur Steigerung der Softwarequalität bewährt“, so Prof. Dr. Sachar Paulus, Vorstandsvorsitzender der ISSECO (International Secure Software Engineering Council e.V.). „Dank der guten Methodologie und einfachen Umsetzbarkeit hat sich SDL mittlerweile bei vielen Entwicklern etabliert. Die beiden neuen Tools sind weitere Bausteine hin zu einer besseren, sichereren Softwareentwicklung“.

Hinzu kommen weitere Hilfen für Entwickler wie z.B. das SDL Process Template für Visual Studio Team System, das SDL Threat Modeling Tool, FxCop (ein Tool zur Analyse von.NET-Assemblies) sowie einige weitere Werkzeuge für die statische Codeanalyse mit Microsoft-Entwicklungsumgebungen.

Alle Tools können bei Microsoft im SDL Tools Repository kostenlos heruntergeladen werden.

Der Security Development Lifecycle ist ein Kernelement der Trustworthy Computing Initiative von Microsoft zur Verbesserung der Sicherheitseigenschaften seiner Produkte. Der Prozess wurde zunächst geschaffen, um firmenintern sichere Anwendungen zu liefern und Attacken besser widerstehen zu können. Jedes Produkt von Microsoft, das mit dem Internet kommuniziert oder für den Unternehmenseinsatz konzipiert ist, muss Angaben von Microsoft gemäß den SDL-Prozess durchlaufen.

Tom Köhler, Direktor Strategie Informationssicherheit Kommunikation bei Microsoft Deutschland hierzu: „Wir schützen damit unsere Plattform. Dazu gehört nicht nur, dass wir unsere eigenen Betriebssysteme und Anwendungen immer sicherer machen, sondern auch Partner und andere Anbieter dabei unterstützen. Gerade Anwendungen von Drittanbietern stehen immer mehr im Zentrum der Attacken durch Schadsoftware. Jeder Entwickler, ob Freiberufler, Microsoft Partner oder Firmenentwickler muss bereits im Designprozess darauf achten, dass seine Anwendungen in der Praxis sicher funktionieren. SDL hilft dabei“.

Kein Zweifel – der Security Development Lifecycle Prozess dürfte für Entwickler auf der Windows-Plattform zunehmend an Bedeutung gewinnen.

Eine der grundlegenden Erkenntnisse das Qualitätsmanagements besteht darin, dass es besser ist Qualität gleich mit einzubauen als sie nachträglich „reinzuprüfen“. Also qualitätssichernde Vorgehensweisen und Praktiken zum verbindlichen  Bestandteil des Produktionsprozesses werden zu lassen.

Die zunehmende Bedeutung von Vorgehensmodellen, Reifegradmodellen und Standards in der Softwareentwicklung macht deutlich, dass die Industrialisierung der Softwareentwicklung auch zur Übernahme qualitätssichernder Konzepte und Methoden führt.

Das Thema „Security by Design“ wurde in den letzten Jahren maßgeblich von Microsoft durch die Entwicklung des Security Development Lifecycle (SDL) vorangetrieben und von zahlreichen anderen Softwareherstellern in der ein oder anderen Form übernommen.

Gängige Instrumente der Software-Qualitätssicherung wie das Testen entsprechender Features, Code-Review oder auch Penetration Tests fertiger Produkte mit sicherheitsrelevanten Eigenschaften erwiesen sich zunehmend als unzureichend, da sie nur punktuell prüfen, anstatt den ganzen Prozess der Entwicklung qualitätssichernd zu begleiten.

Abhilfe schaffen da lebenszyklusorientierte Ansätze wie der SDL bzw. das „Security by Design“-Prinzip, durch die Sicherheit bereits als explizite Anforderung definiert und im weiteren Entwicklungsprozess implementiert und verifiziert wird.

Security by Design bzw. SDL ist dabei keine Technik, sondern eine Sicherheitsmaßnahme, die den Entwicklungsprozess kontinuierlich begleitet. Die Maßnahmen sollen eine integrierte und nachhaltige Sicherheit der entwickelten Softwareprodukte zur Folge haben.

Generell umfasst SDL Sicherheitsmaßnahmen, die den Softwareentwicklungsprozess ergänzen und gewährleisten, dass Sicherheit im notwendigen Umfang berücksichtigt und integriert wird, unabhängig davon, mit welchen Vorgehensweisen und Werkzeugen gearbeitet wird. Die Sicherheitsmaßnahmen lassen sich immer parallel zu den Entwicklungsschritten ausführen.

Ein voll implementierter „Security by Design“-Entwicklungsprozess ist allerdings – ähnlich wie ein umfangreiches Testmanagement – recht aufwändig. Wie man den umfangreichen Microsoft-Ansatz auch auf kleinere Entwicklungsteams und Unternehmen herunterbrechen kann, schildert ein Fachartikel auf Heise Developer.

Im Wesentlichen wird dazu der SDL-Prozess auf seine fünf essenziellen Schritte Managementunterstützung sicherstellen, Awareness und Schulung, Risikoanalysen, sichere Programmierung anwenden, Test und Review reduziert.

Sichere Programmierung anwenden meint damit Schritte, die in eigentlich jeder Programmiersprache nachvollzogen werden können und durch die sich Software-Schwachstellen wie SQL-Injection, Cross-Site Scripting oder Fehler in der Zugriffskontrolle merklich reduzieren lassen:

1. Prüfung von Ein- und Ausgaben vor ihrer Weiterverarbeitung.
2. Authentisierung und Zugriffskontrollen.
3. Korrektes Handhaben und Schutz von sensitiven Informationen und Daten.
4. Befolgen des “Least Privilege”-Prinzips, das die geringstmöglichen Privilegien zur Umsetzung einer Handlung vergibt oder benötigt.
5. Verhindern von Informationspreisgaben.

Ähnliche, aber generellere Ansätze der Qualitätssteigerung während der Entwicklung verfolgt auch das Clean Code Development (CCD).

Hinzu kommt „nachfolgende Qualitätssicherung“ durch Sicherheitstests der fertigen Anwendung. Dadurch wird weiterhin geprüft, ob die Vorgaben zur sicheren Programmierung eingehalten wurden, um zu gewährleisten, dass keine Fehler, speziell keine sicherheitsrelevanten, implementiert wurden. Beispielsweise durch Prüfung des Quellcodes (Code-Review). Es lassen sich nicht nur Konventionen und Qualität prüfen, sondern Entwickler können konkret nach Sicherheitslücken suchen, sie dokumentieren und beheben.

Um einen SDL und damit „Security by Design“ einzuführen oder weiter auszubauen, lassen sich spezielle sicherheitsbezogene Vorgehensmodelle einsetzen. So weist Niklaus Schild in dem bereits erwähnten Heise-Artikel auf die Ansätze des Building Security In Maturity Model (BSIMM, Reifegradmodell für zwölf Praktiken, wie sie sich in der sicheren Softwareentwicklung anwenden lassen) sowie des Software Assurance Maturity Model (SAMM, Reifegrade und zusätzliche Beschreibungen und Empfehlungen für eine Umsetzung und Weiterentwicklung) hin.

Eine der grundlegenden Erkenntnisse das Qualitätsmanagements besteht darin, dass es besser ist Qualität gleich mit einzubauen als sie nachträglich „reinzuprüfen“. Also qualitätssichernde Vorgehensweisen und Praktiken zum verbindlichen  Bestandteil des Produktionsprozesses werden zu lassen.

Die zunehmende Bedeutung von Vorgehensmodellen, Reifegradmodellen und Standards in der Softwareentwicklung macht deutlich, dass die Industrialisierung der Softwareentwicklung auch zur Übernahme qualitätssichernder Konzepte und Methoden führt.

Das Thema „Security by Design“ wurde in den letzten Jahren maßgeblich von Microsoft durch die Entwicklung des Security Development Lifecycle (SDL) vorangetrieben und von zahlreichen anderen Softwareherstellern in der ein oder anderen Form übernommen.

Gängige Instrumente der Software-Qualitätssicherung wie das Testen entsprechender Features, Code-Review oder auch Penetration Tests fertiger Produkte mit sicherheitsrelevanten Eigenschaften erwiesen sich zunehmend als unzureichend, da sie nur punktuell prüfen, anstatt den ganzen Prozess der Entwicklung qualitätssichernd zu begleiten.

Abhilfe schaffen da lebenszyklusorientierte Ansätze wie der SDL bzw. das „Security by Design“-Prinzip, durch die Sicherheit bereits als explizite Anforderung definiert und im weiteren Entwicklungsprozess implementiert und verifiziert wird.

Security by Design bzw. SDL ist dabei keine Technik, sondern eine Sicherheitsmaßnahme, die den Entwicklungsprozess kontinuierlich begleitet. Die Maßnahmen sollen eine integrierte und nachhaltige Sicherheit der entwickelten Softwareprodukte zur Folge haben.

Generell umfasst SDL Sicherheitsmaßnahmen, die den Softwareentwicklungsprozess ergänzen und gewährleisten, dass Sicherheit im notwendigen Umfang berücksichtigt und integriert wird, unabhängig davon, mit welchen Vorgehensweisen und Werkzeugen gearbeitet wird. Die Sicherheitsmaßnahmen lassen sich immer parallel zu den Entwicklungsschritten ausführen.

Ein voll implementierter „Security by Design“-Entwicklungsprozess ist allerdings – ähnlich wie ein umfangreiches Testmanagement – recht aufwändig. Wie man den umfangreichen Microsoft-Ansatz auch auf kleinere Entwicklungsteams und Unternehmen herunterbrechen kann, schildert ein Fachartikel auf Heise Developer.

Im Wesentlichen wird dazu der SDL-Prozess auf seine fünf essenziellen Schritte Managementunterstützung sicherstellen, Awareness und Schulung, Risikoanalysen, sichere Programmierung anwenden, Test und Review reduziert.

Sichere Programmierung anwenden meint damit Schritte, die in eigentlich jeder Programmiersprache nachvollzogen werden können und durch die sich Software-Schwachstellen wie SQL-Injection, Cross-Site Scripting oder Fehler in der Zugriffskontrolle merklich reduzieren lassen:

1. Prüfung von Ein- und Ausgaben vor ihrer Weiterverarbeitung.
2. Authentisierung und Zugriffskontrollen.
3. Korrektes Handhaben und Schutz von sensitiven Informationen und Daten.
4. Befolgen des “Least Privilege”-Prinzips, das die geringstmöglichen Privilegien zur Umsetzung einer Handlung vergibt oder benötigt.
5. Verhindern von Informationspreisgaben.

Ähnliche, aber generellere Ansätze der Qualitätssteigerung während der Entwicklung verfolgt auch das Clean Code Development (CCD).

Hinzu kommt „nachfolgende Qualitätssicherung“ durch Sicherheitstests der fertigen Anwendung. Dadurch wird weiterhin geprüft, ob die Vorgaben zur sicheren Programmierung eingehalten wurden, um zu gewährleisten, dass keine Fehler, speziell keine sicherheitsrelevanten, implementiert wurden. Beispielsweise durch Prüfung des Quellcodes (Code-Review). Es lassen sich nicht nur Konventionen und Qualität prüfen, sondern Entwickler können konkret nach Sicherheitslücken suchen, sie dokumentieren und beheben.

Um einen SDL und damit „Security by Design“ einzuführen oder weiter auszubauen, lassen sich spezielle sicherheitsbezogene Vorgehensmodelle einsetzen. So weist Niklaus Schild in dem bereits erwähnten Heise-Artikel auf die Ansätze des Building Security In Maturity Model (BSIMM, Reifegradmodell für zwölf Praktiken, wie sie sich in der sicheren Softwareentwicklung anwenden lassen) sowie des Software Assurance Maturity Model (SAMM, Reifegrade und zusätzliche Beschreibungen und Empfehlungen für eine Umsetzung und Weiterentwicklung) hin.

Skype. Für all Diejenigen, die bisher von Instant-Messaging oder Voice-Over-IP gar nichts gehört haben oder aber ausschließlich ICQ nutzen ein paar einführende Worte: Skype ist ein relativ kleines Programm, mit dessen Hilfe andere Skype-User via Internetverbindung kostenlos angerufen werden können (auch Videotelefonie und Telefonkonferenzen). Telefonate ins Festnetz sind gebührenpflichtig aber ebenfalls möglich. Zudem können mit Skype Textnachrichten und Dateien verschickt werden. Zusätzliche Tools ermöglichen gemeinsames Spielen und Remote-Desktop-Verbindungen, die sich insbesondere bei Studenten großer Beliebtheit erfreuen (ein Beispiel: mit Hilfe von Skype können Dokumente von mehreren Nutzern zeitgleich bearbeitet werden; zeitaufwendige Treffen können so ersetzt werden). Skype ist dezentral und funktioniert über die Peer-to-Peer-Struktur.

Ich persönlich nutze Skype seit längerer Zeit und gehe davon aus, dass meine Skype-Nutzung weiter zunehmen wird, denn kostengünstiger kann man im Grunde nicht über große Entfernungen zwischen verschiedenen Ländern kommunizieren und telefonieren. Den Vergleich mit ICQ gewinnt Skype für mich aus zwei Gründen: Zum Einen ist (Video-)Telefonie mit Skype ein Kinderspiel, zum Anderen ist das Programm im Vergleich zu ICQ so gut wie werbefrei und im Design deutlich schlanker und eleganter (zumindest die Mac-Version).

Dennoch gibt es zahlreiche Gründe, Skype nicht zu nutzen. Der wohl entscheidende Punkt ist die Tatsache, dass das Programm proprietär ist und der Quellcode nicht offengelegt wird. Damit entsteht ein mächtiges Instrument, denn die steigende Anzahl an Nutzern und der zunehmende Einsatz in mittelständischen Unternehmen bei Unklarheit über Verschlüsselungsmechanismen birgt für den Eigentümer (aktuell ist dies übrigens eBay) enormes Potential und einen möglicherweise einfachen Zugriff auf sensible Informationen. Zudem ist die Abhörsicherheit nach Meinung zahlreicher Experten nicht gegeben.

Ein weiterer Kritikpunkt ist die Beobachtung, dass Skype im Laufe eines Monats bis zu 1 Gigabyte an Daten sendet (im Leerlauf, wenn man selber lediglich online ist ohne aber Nachrichten oder Anrufe zu tätigen). Welche Art von Daten gesendet wird bleibt dabei weitgehend unklar.

Skype kann also zusammenfassend als Blackbox mit vielen nützlichen Funktionen und Tools bezeichnet werden, die allerdings insbesondere bei sensiblen Daten mit Vorsicht anzuwenden ist. Für mich persönlich überwiegen derzeit klar die Vorteile, aber die Nutzung von Skype zur Abwicklung der gesamten internen Unternehmenskommunikation ist für mich fahrlässig und nicht nachvollziehbar

Ruben Unteregger hat rund sieben Jahre lang als Softwareentwickler beim Schweizer Unternehmen ERA IT Solutions gearbeitet. Seine Aufgabe dort war das Erstellen von Schadprogrammen, die ein Eindringen in die Computer von Privatanwendern ermöglichen soll. Die ERA IT Solutions soll insbesondere am Aufbau von Trojanern beteiligt sein, die dem Abhören von VoIP-Telefonaten dienen. Will er keine Vertragsstrafe zahlen, so muss er sich über die Kunden des Unternehmens ausschweigen. Zeitgleich zur Veröffentlichung dieses Interviews will Herr Unteregger der Öffentlichkeit den Quellcode seines Trojaners zur Verfügung stellen. Interview lesen auf gulli.com

Software besser zu machen, d.h. insbesondere ihre Qualität, Zuverlässigkeit, Fehlerfreiheit und Sicherheit zu steigern, ist mittlerweile ein Trendthema geworden. Bislang ging man dabei den Weg, über Vorgehens- und Reifegradmodelle zur Softwareentwicklung den Entwicklungsprozess zu verbessern. Softwareentwicklung also zunehmend durch Standardisierung zur Ingenieursdisziplin (Engineering) zu machen. In dieselbe Richtung gehen auch agile Methoden wie SCRUM oder XP, die auf die Verbesserung der Projekt- und Arbeitsorganisation der Softwareentwicklung abzielen.

Mit Clean Code Development (CCD) wurde zum Jahresanfang nun eine Initiative gestartet, die auf das eigentliche Herzstück der Softwareentwicklung abzielt: den Softwareentwickler.

Basierend auf den Arbeiten von Robert C. Martin, die dieser in seinem Buch „Clean Code“ veröffentlichte, befasst sich CCD mit Praktiken wie Codeoptimierung (Refactoring), Entwurfsmuster (Patterns) sowie Testen und Techniken zur Erstellung sauberen Quellcodes. Sozusagen die Rückführung der Softwareentwicklung auf gute handwerkliche Arbeit, durch die sich der Profi vom Amateur und Bastler unterscheidet.

Für Code als Quelltext und strukturiertem Ausdruck der Funktionalität sowie als kleinsten gemeinsamen Nenner zwischen Softwareentwicklern aller Art beschreibt Clean Code eine Menge von Prinzipien und Best Practices als kleinsten gemeinsamen Nenner.

Dazu gehört u.a. ein aus Prinzipien und Praktiken guter handwerklicher Arbeit bestehendes CDD-Wertesystem. Sowie eine Einteilung in aufeinander aufbauender Grade fortschreitender Professionalisierung, die sich mit Themen wie Automatisierung von Abläufen, Testen, Testautomation, projektbegleitende Qualitätssicherung sowie Steigerung der Produktivität als Entwickler auseinandersetzen.

Ralf Westphal, Mitbegründer der „Clean Code Development“-Initiative in einem Interview mit Heise Developer:

Mir ging es darum, Unternehmen bewusst zu machen, wie viel Geld sie mit schlechter Softwarequalität „verbrennen“ – selbst wenn die Umsätze sie irgendwie gerade noch tragen. Die Idee stieß bei Stefan auf offene Ohren, und so sahen wir das Buch “Clean Code” als pragmatischen Ausgangspunkt für mehr Bewusstsein hinsichtlich innerer Softwarequalität. Denn um die geht es uns. Wir machen keine Aussage zu äußerer Qualität, die zum Beispiel mit Funktionen, Usability oder Skalierbarkeit zu tun hat. Uns geht es um Wartbarkeit – auch wenn wir den Begriff unglücklich finden. Sehr viele Projekte stecken in einem Wartungsalbtraum. Aus dem wollen wir sie wecken. Andere Projekte bewegen sich darauf zu. Denen wollen wir zeigen, dass der Albtraum vermeidbar ist.

Dort weist er auch auf die Lücken bisheriger Ansätze zur Qualitätssicherung in der Softwareentwicklung hin:

Schließlich ist Softwarequalität das Thema von Verbänden und Normen. Da kann man sich ISO-zertifizieren lassen oder sich auf ein CMMI-Level heben. Das ist alles schön und gut. Nur sehen wir nicht, dass diese Initiativen auf breiter Front Erfolg haben. Der Entwickler einer Branchensoftware in einem 5-Mann-Team hat davon sogar wahrscheinlich nicht einmal gehört. Ganz zu schweigen davon, dass seine kleine Softwareschmiede eine Zertifizierung wegen der hohen Kosten nicht durchlaufen würde. Die „große“, „formale“, „offizielle“ Softwarequalität lässt also eine sehr große Zahl von Projekten außen vor, weil sie bürokratisch und teuer ist.

Mit Clean Code Developer wollten wir daher eine Lücke schließen, die wir in unserer Arbeit in vielen Projekten gesehen haben. Es geht uns „nur“ um eine ganz pragmatische und vor allem innere Softwarequalität, die sich mit etwas gutem Willen und ein paar Werkzeugen in jedem Projekt herstellen lässt. Von anderen Initiativen unterscheiden wir uns also schon einmal durch unseren Fokus.

Darüber hinaus legen wir Wert auf die Didaktik. Denn der schönste Fokus nützt nichts, wenn sich das Ziel nicht erreichen lässt. Clean Code Developer unterscheidet sich unserer Meinung nach daher von anderen Initiativen durch sein Stufenkonzept. Wir haben den „Lernstoff“ von vornherein eingeteilt, sodass ein klarer Weg hindurch sichtbar ist. Wir holen die Entwickler bei ihrer Überlastung ab und zeigen ihnen, wie sie in kleinen Schritten – definiert in den CCD-Graden – zu einer Veränderung ihrer Haltung und damit zu höherer Codequalität kommen.

Es bleibt abzuwarten, ob und wie sich CCD weiter entwickeln wird. Zumindest dort wo heute bereits mit agilen Methoden, d.h. sehr am einzelnen Entwickler orientiert gearbeitet wird, dürften CCD-Ansätze eine weitere methodische Ergänzung darstellen.

Insbesondere aber wer die Entwicklung von Software neu erlernt oder Entwicklungsprojekte häufiger auf Codeebene zu prüfen hat, täte gut daran sich mit den Überlegungen des Clean Code Development zu befassen.

Software besser zu machen, d.h. insbesondere ihre Qualität, Zuverlässigkeit, Fehlerfreiheit und Sicherheit zu steigern, ist mittlerweile ein Trendthema geworden. Bislang ging man dabei den Weg, über Vorgehens- und Reifegradmodelle zur Softwareentwicklung den Entwicklungsprozess zu verbessern. Softwareentwicklung also zunehmend durch Standardisierung zur Ingenieursdisziplin (Engineering) zu machen. In dieselbe Richtung gehen auch agile Methoden wie SCRUM oder XP, die auf die Verbesserung der Projekt- und Arbeitsorganisation der Softwareentwicklung abzielen.

Mit Clean Code Development (CCD) wurde zum Jahresanfang nun eine Initiative gestartet, die auf das eigentliche Herzstück der Softwareentwicklung abzielt: den Softwareentwickler.

Basierend auf den Arbeiten von Robert C. Martin, die dieser in seinem Buch „Clean Code“ veröffentlichte, befasst sich CCD mit Praktiken wie Codeoptimierung (Refactoring), Entwurfsmuster (Patterns) sowie Testen und Techniken zur Erstellung sauberen Quellcodes. Sozusagen die Rückführung der Softwareentwicklung auf gute handwerkliche Arbeit, durch die sich der Profi vom Amateur und Bastler unterscheidet.

Für Code als Quelltext und strukturiertem Ausdruck der Funktionalität sowie als kleinsten gemeinsamen Nenner zwischen Softwareentwicklern aller Art beschreibt Clean Code eine Menge von Prinzipien und Best Practices als kleinsten gemeinsamen Nenner.

Dazu gehört u.a. ein aus Prinzipien und Praktiken guter handwerklicher Arbeit bestehendes CDD-Wertesystem. Sowie eine Einteilung in aufeinander aufbauender Grade fortschreitender Professionalisierung, die sich mit Themen wie Automatisierung von Abläufen, Testen, Testautomation, projektbegleitende Qualitätssicherung sowie Steigerung der Produktivität als Entwickler auseinandersetzen.

Ralf Westphal, Mitbegründer der „Clean Code Development“-Initiative in einem Interview mit Heise Developer:

Mir ging es darum, Unternehmen bewusst zu machen, wie viel Geld sie mit schlechter Softwarequalität „verbrennen“ – selbst wenn die Umsätze sie irgendwie gerade noch tragen. Die Idee stieß bei Stefan auf offene Ohren, und so sahen wir das Buch “Clean Code” als pragmatischen Ausgangspunkt für mehr Bewusstsein hinsichtlich innerer Softwarequalität. Denn um die geht es uns. Wir machen keine Aussage zu äußerer Qualität, die zum Beispiel mit Funktionen, Usability oder Skalierbarkeit zu tun hat. Uns geht es um Wartbarkeit – auch wenn wir den Begriff unglücklich finden. Sehr viele Projekte stecken in einem Wartungsalbtraum. Aus dem wollen wir sie wecken. Andere Projekte bewegen sich darauf zu. Denen wollen wir zeigen, dass der Albtraum vermeidbar ist.

Dort weist er auch auf die Lücken bisheriger Ansätze zur Qualitätssicherung in der Softwareentwicklung hin:

Schließlich ist Softwarequalität das Thema von Verbänden und Normen. Da kann man sich ISO-zertifizieren lassen oder sich auf ein CMMI-Level heben. Das ist alles schön und gut. Nur sehen wir nicht, dass diese Initiativen auf breiter Front Erfolg haben. Der Entwickler einer Branchensoftware in einem 5-Mann-Team hat davon sogar wahrscheinlich nicht einmal gehört. Ganz zu schweigen davon, dass seine kleine Softwareschmiede eine Zertifizierung wegen der hohen Kosten nicht durchlaufen würde. Die „große“, „formale“, „offizielle“ Softwarequalität lässt also eine sehr große Zahl von Projekten außen vor, weil sie bürokratisch und teuer ist.

Mit Clean Code Developer wollten wir daher eine Lücke schließen, die wir in unserer Arbeit in vielen Projekten gesehen haben. Es geht uns „nur“ um eine ganz pragmatische und vor allem innere Softwarequalität, die sich mit etwas gutem Willen und ein paar Werkzeugen in jedem Projekt herstellen lässt. Von anderen Initiativen unterscheiden wir uns also schon einmal durch unseren Fokus.

Darüber hinaus legen wir Wert auf die Didaktik. Denn der schönste Fokus nützt nichts, wenn sich das Ziel nicht erreichen lässt. Clean Code Developer unterscheidet sich unserer Meinung nach daher von anderen Initiativen durch sein Stufenkonzept. Wir haben den „Lernstoff“ von vornherein eingeteilt, sodass ein klarer Weg hindurch sichtbar ist. Wir holen die Entwickler bei ihrer Überlastung ab und zeigen ihnen, wie sie in kleinen Schritten – definiert in den CCD-Graden – zu einer Veränderung ihrer Haltung und damit zu höherer Codequalität kommen.

Es bleibt abzuwarten, ob und wie sich CCD weiter entwickeln wird. Zumindest dort wo heute bereits mit agilen Methoden, d.h. sehr am einzelnen Entwickler orientiert gearbeitet wird, dürften CCD-Ansätze eine weitere methodische Ergänzung darstellen.

Insbesondere aber wer die Entwicklung von Software neu erlernt oder Entwicklungsprojekte häufiger auf Codeebene zu prüfen hat, täte gut daran sich mit den Überlegungen des Clean Code Development zu befassen.

Zum 40. Jahrestag der ersten bemannten Mondlandung wurde nun auf Google Code der Quellcode der damals benutzten Steuerungs-Software veröffentlicht – und zwar mitsamt der orignalen Kommentare…
Es gibt die Quellcodes für die Saturn V und für die Landefähre Eagle.

Und dass die Programmierer damals (wie heute) immer für ein wenig Spaß gut sind, zeigt der Name der Startroutine für die Eagle:

BURN_BABY_BURN–MASTER_IGNITION_ROUTINE.agc

Zum Heise-Artikel

Auch wenn die Konstruktionspläne weg sein sollten…  der Quellcode ist im MIT-Museum zu finden.

Nein, ich werte das nicht – Verschwörungstheorien und Beweise hin oder her

Der deutsche Ableger von facebook.com hat seinen Konkurrenten StudiVZ, und damit auch SchülerVZ, verklagt.

Grund für die Anklage ist die Tatsache, dass StudiVZ Logo, Features und den Service von facebook kopiert und übernommen haben soll. Vorallem aber geht es um die Features, die laut facebook geistiges Gut sein. Desweitern habe StudiVZ auf verbotene Weise Zugriff auf das facebook-Computersystem gehabt haben, unteranderem auch auf den Quellcode.

Die Gemeinsamkeiten sind kaum zu übersehen, von dem Design über die “Pinnwand” bis zur “Freundefunktion” haben die beiden Portale viel Gemeinsamkeiten. Bleibt natürlich die Frage, ob das Huhn oder das Ei zuerst da war.  In diesem Fall ist es wohl eindeutig: facebook ging bereits im Februar 2004 online, StudiVZ erst im November 2005…

Quelle: SPIEGEL ONLINE

Sorry das ich in den letzten Tagen nicht zum posten neuer Artikel gekommen bin. Fakt ist aber, dass ich gerade gewaltig viel Arbeit habe.

Nein: Ich spreche hier nicht von meinem Studium und

Ja: Ich meine Giga Mansion 2!

Endlich haben wir genug Material, um mit der Programmierung anzufangen. Ihr glaubt nicht, wie aufregend das sein kann! Zeitweise habe ich mich wie ein richtiger Spiel-Entwickler gefühlt, und ich muss sagen: es hat mir gefallen! Aber fangen wir erstmal ganz am Anfang an.

Wie läuft das mit der Programmierung überhaupt ab?

Als erstes muss ich hier Kollege Henning meinen Dank aussprechen (ja mal wieder!). Er steuert ja nicht nur seine Engine bei, sondern auch noch den Szeneneditor “Atlantis”. Mit dessen Hilfe kann ich die Grafiken von Guido nehmen und eine so genannte Szenerie erstellen. Dazu gehören der Hintergrund, verschiedene Grafiken und Images für (animierte) Entitäten im Vordergrund, sowie eine Polygon- und Pointerstruktur, um die Geometrie der Szene zu beschreiben. All diese Elemente kann ich in Atlantis, mit nur ein paar Mausklicks, zu einer Gesamtkomposition verbinden. Gerne würde ich euch an dieser Stelle einen Screenshot präsentieren, aber das muss ich auf Sonntag verschieben, da mir noch die Erlaubnis des Teams fehlt.

Dafür kann ich euch als Programmierer einen Auszug aus den ersten Zeilen Quellcode zeigen. Insgesamt sind es bereits weit über 700 Zeilen, die wir zusammen haben. Als guter Entwickler weiß man zwar, das diese Zahl überhaupt nichts bedeutet, aber es soll euch die minimalistische Größe dieses Ausschnittes verdeutlichen.

class Halo : SceneEntity {

    Halo_Panorama haloScene;

    this(char[] actiontext,Halo_Panorama scene){
        super(actiontext);
        defaultAction_ = g_actions.lookAction;
        this.haloScene = scene;
    }

    override ActionState executeAction(Action action, ActionTarget[] otherTargets){
        if(action is philboy.g_actions.lookAction) {
            haloScene.center(haloScene.atlantis.halo_center_point);
            SceneEntity.mainCharacter.sayPause(1000);
            SceneEntity.mainCharacter.say("WOOOOOOOW! Fettes Panorama");
            haloScene.center(SceneEntity.mainCharacter.position);
            return ActionState.HANDLED;
        }
        return ActionState.UNHANDLED;
    }
}

Was will uns der Autor mit diesem Text sagen? Nun in erster Linie will er nicht mit euch sprechen, sondern mit eurem Rechner! Abgesehen davon scheint es sich hier um eine Entität zu handeln. Wir sehen also nicht die Klasse einer kompletten Szenerie, aber wir sehen ein Element. Welches Element? Nun… sagen wir einfach: die Weitsicht ist fantastisch

Ich hoffe ich konnte euer Interesse wecken. Am Sonntag wird es spannend, also unbedingt am Ball bleiben.

Bis dahin noch viel Spaß

Euer GM2-Team

mit Benjamin

Eine der wichtigsten Programme, die ich auf mein PC habe ist sicher Delphi Programmiersprache. Ich habe arbeite mit Delphi schon lange, ungefähr fünf Jahren. Grund warum ich Delphi ausgewählt habe für meine Programmiersprache für Win32 Umgebung ist das ich schon in Gymnasium mit Pascal programmiert habe und ich habe mich auf diese Programmiersprache so angewöhnt, dass es kein Sinn machte das zu wechseln und damit auch viele Kenntnisse verlieren, die ich in Pascal gewonnen habe und dann in Delphi mitnehmen konnte. Deshalb programmiere ich jetzt schon lange Zeit in Delphi, obwohl die Sprache nicht sehr verbreitet, zumindest nicht so sehr wie die Konkurrenz.

Linux würde ich aus ideologischen Gründen selbst dann verwenden, wenn es das schlechteste der drei bekanntesten Betriebssysteme wäre, was aber wahrlich nicht der Fall ist. Würde man die OpenSource-Philosophie auf die gesamte globale Gesellschaft übertragen, wäre dieser unser Planet garantiert ein besserer Ort. Die Linux-Community hat großartiges geleistet. Sie hat bewiesen, dass man mit nichtkommerziellen Gemeinschaftssinn genauso viel und mehr leisten kann, als mit “geiz-ist-geil” und Shareholder Value. Frei bedeutet hier nicht Freibier, sondern Freiheit, die totale Kontrolle über Betriebssystem und Rechner, anstatt Hardwareeenteignung. Dank des offenen Quellcodes kann jeder sich sein eigenes individuelles Linux zusammenschrauben. Linux ist dezentral, kann niemals zum Monopol-Moloch anschwellen, weil die GPL-Lizenz dafür sorgt, dass der Quellcode offen bleibt. Dadurch kann jeder Programmierer auf erarbeitetes Wissen aufbauen und weiterentwickeln.

Dem Initiator dieser Blogparade muss ich trotz des guten Themas, die gelbe oder noch besser die gelbrote Karte zeigen und zwar wegen diesem Satz:

Sie sind Linux-User? Gut, aber warum haben Sie sich für das freie, kostenlose aber leider auch aufwändiger zu bedienendere Betriebssystem (im Gegensatz zu Windows oder Mac OS X) entschieden?

Einspruch! Ubuntu kann sogar ein besoffenes halbblindes Huhn installieren, wenn man ihm 5 Körner auf die linke Maustaste legt. Davon abgesehen, ist Linux für mich ebenso einfach oder schwer bedienbar, wie das System aus Redmond, man muss nur die Windows-Schiene verlassen und umdenken. Ich bin beileibe kein Nerd, sondern ein ganz gewöhnlicher User. Wenn ich mit dem Pinguin klarkomme schafft das jeder! Linux verfügt über komfortable Benutzeroberflächen, die Zeiten, wo man ständig krytische Befehle in die Shell eintippen musste, sind längst vorbei.

Das freie Betriebssystem ist sicherer. In 3 Monaten Windows war meine Festplatte voller elektronischer Ungeziefer und Quälgeister, in 6 Jahren Linux dagegen, sind mir solche Probleme gänzlich unbekannt geblieben. Ich brauche auch kein saudämliches Antivirenprogramm, welches mich ständig nervt und meinen Rechner unnötig ausbremst.

Linux ist weniger ressourcenhungrig, während beispielsweise ein Vista brutalste Hardwareanforderungen stellt. Die aktuellsten Linux-Distributionen dagegen machen selbst älteren Rechnern noch Beine, inklusive Desktopeffekte und 3D-Graphik!

Überragend ist auch die Hülle und Fülle an Software, welche die meisten Linux-Distributionen schon bei der Grundinstallation mitbringen. Um bei Windows die gleiche Vielfalt an Programmen auf die Platte zu bringen, musst Du Dir erst stundenlang den Arsch abinstallieren. Dass das OpenSource-Betriebssystem im Preis-Leistungsverhältnis unschlagbar ist, braucht eigentlich nicht erwähnt zu werden, da es kostenlos zu Verfügung steht. Diese Tatsache ist aber kein Hauptargument Pro-Linux für mich, ich würde auch dafür zahlen. Für die SUSE 10.0-Box inklusive Hanbuch und Installationssupport habe ich schonmal 49 Euro bezahlt…

Das waren die Argumente, die mir recht spontan zugunsten von Linux einfielen, kaum ein Grund spricht aus meiner Sicht für die Benutzung von Windows oder einem MAC.
Noch ein paar Zeilen zur “Konkurrenz”:
Microsoft hat seine quasi Monoplstellung oftmals zur politischen Einflussnahme missbraucht. Ich mag die Unternehmensphilosophie der Redmonder nicht, bin froh von denen nicht abhängig zu sein. Auch Apple fährt die Strategie, mit proprietärer Software, eine möglichst starke Kundenbindung zu erreichen. Gleichzeitig schafft man erfolgreiche “Kultmarken” wie z.B. das iPhone oder den iPod. Ich denke, wenn ich versuchen würde, das iPöttchen mit Linux zu betreiben, wäre ich ganz schön am iArsch. Warum kann man nicht jeden mobilen Musikplayer, wie eine externe Festplatte oder einen ordinären USB-Stick einbinden? Welch eine Technikverhinderung,…

Wer Freiheit und Entfaltung liebt, diese Ideologie lebt, müsste folglich Linux-User sein

Will man strukturierten Programmcode erstellen, kann man zum Beispiel Variablendefinitionen am Gleichheitszeichen ausrichten, oder Kommentare einheitlich in der gleichen Spalte beginnen.

Zum Beispiel statt:

i = 0; /*Zählervariable*/

blubb = 5; /* bla */

so:

i          = 0;      /* Zählervariable */

blubb = 556; /* bla                      */

Damit man das nicht per Hand machen muss, gibt es für vim-User (ja, crackpod, für dich nicht =P) ein Plugin namens “Align” mit dem man den Code nach belieben ausrichten kann, mit nur wenigen Tastendrücken. Dazu makiert man einfach im visuellen Modus den Block, auf den man die Änderung anwenden möchte und tippt dann z.B. ‘\t=’, um die Definitionen am Gleichheitszeichen auszurichten. Danach kann man noch mit ‘\acom’, die Kommentare ausrichten. Nahezu genial.

Das Plugin, zusammen mit einer Installationsanleitung und weiteren Beispielen für die Benutzung, findet man hier.

Darauf gestoßen, bin ich in diesem PDF-Dokument, einer Kurzanleitung zum Programmieren in vim, mit vielen nützlichen Tipps.