Posts mit dem Label Project Management werden angezeigt. Alle Posts anzeigen
Posts mit dem Label Project Management werden angezeigt. Alle Posts anzeigen

Montag, 26. März 2012

Polyglote Programmierung

Als ich die Überschrift das erste Mal las, dachte ich zuerst es geht um Internationalisierung und UTF-8, aber nein das Thema polyglotte Programmierung ist spannender. Vereinfacht beschreibt polyglotte Programmierung einen Mix aus unterschiedlichen Programmiersprachen zur Lösung von Softwareentwicklungsaufgaben und bildet damit einen einen Gegenpol zu der vor allem Im Java-Bereich dominieren Auffassung, das eine Programmiersprache für alle Probleme (Server, Smartcard, Client, Real Time) reicht. Oder um es sehr plakativ austzzudrücken: Java und C gegen XML und DSL (domain-specific language). Auf der Heise-Seite gibt es eine kritischen kurzen Artikel zur polyglotten Programmierung (http://www.heise.de/developer/artikel/Warum-Polyglot-Programming-nicht-praxistauglich-ist-1479542.html) bzw. ist das Original auf Englisch als Blog Post erschienen (http://lofidewanto.blogspot.de/2011/10/why-is-polyglot-programming-or-do-it.html). Auch wenn ich offen gegenüber neuen Entwicklungen bin, so kenne ich die Konfigurationshöllen ala Spring und Maven. Auch wenn sich heute der Zustand in der Spring Welt verbessert hat, so bestärkt mich der Artikel in meiner Skepsis gegenüber polyglotten Projekten. Ein Problem der polyglotten Entwicklung muss aus meiner Sicht stärker betont werden, das Problem der Wartbarkeit polyglotter Projekte. Ich bin der Meinung, dass polyglotte Projekt entgegen der eigentlichen Ziele der polyglotten Programmierung zu einer höheren Komplexität neigen. Und die Nachteile, mehr Fehler und hohe Änderungsträgheit überwiegen. Aus meiner Sicht sind gut designte Objekte und Pakete nichts weiter als eine Vorform einer DSL. Wichtig ist, die Benennung und die Sichtbarkeit von Objekten und Methoden so einzusetzen, dass man mit ihnen so effektiv umgehen kann, wie man man es von einer DSL erwarten würde.

Dienstag, 24. Januar 2012

Buchreview: Arbeiten statt Deligieren

Junge, neue Unternehmen haben es in Deutschland schwer auf die Beine zu kommen und erfolgreich zu werden. Die bürokratischen Bestimmungen und die Organisations-Mentalität der Deutschen hämt viele gute Ideen und lässt diese schon im Keim ersticken. Das Besteller Buch "Rework" der erfolgreichen Software Schmiede "37signals" aus Amerika beschreibt wie es mit einfachen, greifbaren Mitteln möglich ist gute Ideen auf den Markt zu bringen. Es geht nicht darum teure Werbung zu schalten, Manager einzustellen welche die Arbeit deligieren, lange Meetings zu halten, bis spät in die Nacht zu arbeiten oder Geld von Investoren zu akquirieren. Im Gegenteil, es geht darum Produkte zu entwickeln die einen begeistern, seinen Kunden zuzuhören, ehrlich zu sein und am Erfolg zu arbeiten und das mit Mitteln die wir alle zur Verfügung haben. Die Autoren zeigen wie jeder mit dem Fokus auf das Wesentliche zum Ziel kommt. Diese Maxime wird wunderbar im Buch umgesetzt. Die Kapitel sind nicht länger als zwei Seiten, sind leicht zu lesen und für jeden verständlich. Ein großartiges Buch für Alle die arbeiten und Arbeit produzieren.
REWORK - Jason Fried & David Heinemeier Hansson - Founders of 37signals
Autor des Gastbeitrags: Stefan Laabs

Sonntag, 22. Januar 2012

Zeitbetrug aufdecken

Neben den Werksverträgen werden oft Serviceverträge zwischen Unternehmen abgeschlossen. Serviveverträge sind im IT Bereich sehr beliebt. Dazu werde in der Regel die Arbeitszeiten des Dienstleiters nachgewiesen. Praktisch sind im IT Bereich Issue Tracking Systeme wie JIRA dafür. Sie ermöglichen das Festhalten und Dokumentieren der Aufgabe, der Problemlösung und der dafür benötigten Zeiten, sehr praktisch. Sehr praktisch, vor allem weil der Kunde keine Kontrollmöglichkeit Besitz und er dem Dienstleister ausgeliefert ist.
Aber nein, es gibt einfache Möglichkeiten mit Hilfe von ein wenig einfacher Mathematik den Betrugs mit Servicezeiten aufzudecken. Dazu zuerst der Normalfall an einem Beispiel kurz dargestellt, ein Aufgabe kommt herein, und wird auf X h geschätzt und bearbeitet, innerhalb des Bearbeitungszeitraums wird die Zeit für das Bearbeiten verbraucht. Die Aufgabe wird gelöst. In der Regel werden diese Arbeiten beim Kunden zum Monatsende abgerechnet. 
Die allermeisten Abweichungen sind Betrug, die wohl beliebteste Methode ist, wenn der Dienstleister merkt, dass er zu wenig Aufwände (Zeiten) im Monat hatte. Er trägt zum Monatsende, kurz vor Rechnungsstellung gehäuft Zeiten nach. D.h. es werden Zeiten auf längst bearbeitete Vorgänge geschrieben. Um diese Betrugsvariante aufzudecken, muss man nur die Daten, wann Zeiten eintragen wurde in Bezug zum Abrechnungszeitraum setzen. Es kommt zu einer klaren, nicht normalen Häufung. Die zweite Auffälligkeit dieser Betrugsmethode ist die große Differenz (Tage) zwischen dem Datum wann die Zeiten eingetragen wurden und wann sie angeblich angefallen sind. Mit beiden Methoden lässt sich diese Betrugsart erkennen.

Donnerstag, 22. Dezember 2011

Schöne neue Maven Welt

Was mich an Maven oder viel mehr an Maven Entwicklern stört, ist dass sie Abhängigkeiten aufbauen statt sie abzubauen. Wenn ich an einem Open Source Plugin eines größeren Systems nur eine Zeile Code ändern möchte, dann  muss ich gleich das ganze System und nicht nur das Plugin auschecken. Das ist absurd. Guter Code hat eine eine geringe Kopplung zwischen Modulen und wenige Abhängigkeiten. Parent Module sind schön aber nicht immer notwendig. Hört auf alle möglichen Features zu nutzen. Jedes neue Feature sollte das Gesamtsystem einfacher und nicht komplizierter machen.

Montag, 7. Februar 2011

Broken-Window-Theorie und Null-Tolleranz-Strategie bei der Softwareentwicklung

Für Alle die nicht mit den Themen vertraut sind, hier eine Minimaleinführung. Die Broken-Window-Theorie kann erklären wie Kleinigkeiten z.B. ein zerbrochenes Fenster zu Verwahrlosung eines Hauses, des Stadtviertels führen. Darauf aufbauend wurde von der New Yorker Polizei die Zero-Toleranz-Strategie angewandt, die kleinste Vergehen konsequent angeht und damit der Verwahrlosung schon in deren Entstehung begegnet. Dies ist ein effektive Strategie zur Verhinderung solcher Missstände.

Was hat die mit Softwareentwicklung zu tun? Dazu folgendes. Wenn ein neuen Entwickler zu einem bestehenden Projekt kommt und anfägt Code zu schreiben, dann setzt er den Code nicht nur so um, wie er es für richtig hält, sondern der bestehende Code wirkt sich auf ihn aus. Wenn also der bestehende Projektcode in einem suboptimalen Zustand ist, dann wirkt sich dieses Manko auf alle Programmierer aus. Sie werden zusehens schlechteren Code abliefern, im schlimmsten Fall kann dies zu einer negativen Abwärtsspirale führen. Als Gegenmassnahmen gibt es zwei Dinge. Erstens, der Code muss aufgeräumt werden und zwar sofort. Selbst Kleinigkeiten im Code korrigiert müssen korrigiert werden. Und Zweitens, dass man Code-Review auf Basis der Null-Toleranz-Strategie fahren muss. Mit Hilfe dieser beiden Verfahren ist es möglich eine gewachsene Code-Basis für zukünftige Erweiterungen fit zu machen. Aus einer anderen Perspektive, ohne Aktives Gegensteuern im Bereich der Softwarequalität werden schlechte Softwareprojekte schlechter. Diese Erkenntnis ist nicht neu, aber man kann sie mit Hilfe der Broken-Window-Theorie erklären und damit kennt man auch die Gegenmaßnahmen. Und so können Programmierer der New Yorker Polizei dankbar sein.

Donnerstag, 25. November 2010

Au weia, ich habe die falsche Datei überschrieben ...

was nun, ich habe eine wichtige Datei im Projekt überschrieben und im Subversion liegt auch nur eine alte Version. Eclipse liegt lokale Kopien von den Daten an die man bearbeitet. Wenn man eine solche lokale Kopie wiederherstellen will, muss man im Package Explorer einen Rechtsklick auf die Datei machen und dann in das Menü Restore from Local History ... (siehe Bild).
Damit hat man das erste Problem gelöst, aber da hinter jedem kleinen Problem ein grosses Problem steckt, muss auch dieses Problem gelöst werden. Es zeigt sich also, dass die Richtlinien fürs Codemanagement unvollständig sind oder unzureichend umgesetzt werden. In der Regel gilt, nach jeden Bug Fixing, nach jeden Feature oder nach jedem Refactoring sollte das SVN Repository aktualisiert werden. Übrigens kann man auch sehr einfach ein lokales SVN aufsetzen (Setup a Subversion Server in 4 Minutes). Wenn sich dies nur schwierig im eigenen Entwicklungsprozess umsetzen lässt, dann sollte man einen Blick auf Git werfen.

Donnerstag, 14. Oktober 2010

Verbreitung der Programmiersprache Java

Wenn ein Softwareprojekt ansteht, steht auch immer die Frage mit welcher Programmiersprache soll es umgesetzt werden. Oft wird die Programmiersprache dafür gewählt, für die es im Haus verfügbare Programmierer gibt. Und trotz dieser pragmatischen Antwort bleibt diese Frage. Wenn dies aber eine offene Frage ist, kann man anfangen das Problem mit allen Programmiersprachen zu vergleichen, um die beste Programmiersprache zu finden. Auch wenn man sich einschränkt ist dies eine sehr Zeitaufwendige Untersuchung. Unklar ist auch ob man alle Aspekte des Problems kennt um objektiv die richtige Programmiersprache zu wählen. Ich behaupte, das es nicht möglich ist alle Aspekte und Informationen vor der Beendigung des Projektes zu kennen. Daher bin ich ein Verfechter der Agilen Softwareentwicklung, die flexibel mit wechselnden Anforderungen umgehen kann. Mit dieser Erkenntnis kann man andere Kriterien für die Auswahl einer Programmiersprache heranziehen. Wenn man davon ausgeht das alle Programmiersprachen ähnlich leistungsfähig sind, kann man sich an dem Verbreitungsgrad einer Programmiersprache orientieren. Zu behaupten alle Programmiersprachen sind gleich leistungsfähig ist eine sehr grobe Vereinfachung, die aber aber für die wichtigsten Programmiersprachen ein zulässige Annahme ist. So lassen sich Java, C++ oder C# im Allgemeinen als äquivalent betrachten. Dazu kommt, dass der Verbreitungsgrad von Programmiersprachen sich gut ermitteln lässt. Bei Heise Jobs 2010 (http://www.heise.de/jobs/artikel/Wer-verdient-wie-viel-981845.html?artikelseite=8) liegt Java bei 17,3% auf Platz 1 und C++ bei 7,4%. Bei Tiobe ist die Nummer 1 Java mit 18% vor C mit 17% gefolgt von C++ mit 9,8% (http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html). Bei Gulp liegt Java derzeit (09/2010) bei ca. 16%, C bei 9% und C++ bei nur 4%. Der Trend bei Gulp und Tiobe ist ähnlich, die Differenz lässt sich zu Teil dadurch erklären, dass bei Gulp nacht Skills gefiltert wird, d.h. SQL hat dort eine Wert von 13%, wohingegen SQL bei Tiobe nicht separat aufgeführt wird. Trends bei den Programmiersprachen werden bei Tiobe direkt angegeben, auch bei Gulp kann man Trendanalysen durchführen. Bei Gulp fällt auf, dass die Angaben zu einer Programmiersprache stark zeitlich schwanke, für genaue Aussagen, müsste man die Gulp-Daten statistisch bearbeiten. In diesem Zusammenhang interessant sind die Nutzungswerte der Usenet Gruppe Java (siehe Bild).

Danach erreichte Java seinen Höhepunkt im Jahr 2002 und ist bis 2010 deutlich geschrumpft. Bei Gulp erreichte Java seine grösste Popularität im Jahr 2000. Dies betrifft nicht nur Java sondern auch andere etablierte Programmiersprachen wie C. C erreicht bei Gulp im Jahr 1999 seine maximale Beliebtheit. 1999 ist dabei das erste verfügbare Jahr in Gulp. Ob diese Rückgänge real oder nur Prozentual auf Grund sich neu etablierender Programmiersprachen ist, ist nicht zu ermitteln. Aber die zunehmende Diversität der Programmiersprachen ist sicher ein Grund für die prozentualen Rückgänge bei Gulp und die realen Rückgänge im Usenet. Bei den dramatisch erscheinenden Java Usenet Zahlen kommt hinzu, dass es auch bei den Hilfepunkten zu einer staken der Diversität z.B. durch Webforen kam. Bei Tiobe sind auch allgemein abnehmende Verbreitungsgrade festzustellen, aber entgegen dem Trend bei Gulp kann sich dort C im Langzeittrend (10 Jahre) besser behaupten und sogar Boden gut machen.
Abschliessend kann man sagen, dass es in den letzten 10 Jahren zu einer stark zunehmenden Diversität der Programmiersprachen kam. Trotzdem behaupten sich die wichtigen Sprachen wie Java oder C weiterhin. Diese neue Vielfalt der Programmiersprachen lädt dazu ein beim nächsten Projekt mal über alternative Programmiersprachen nachzudenken. Ein einfaches Auswahlkriterium könnte die Verbreitung der Sprache sein.

Dienstag, 9. März 2010

Free Projekthosting Origo

Es gibt eine Reihe von Anbietern zum hosten von eigenen Projekten. Der bekannteste ist Sourceforge. Bei Sourceforge wie bei ähnlichen Hostern z.B. Berlios kann man nur Open Source Projekte hosten, die auch entsprechende Lizenznen z.B. die infektiöse GPL haben. Natürlich sind auch andere Lizenzen OSS-Lizenzen wie die APL möglich. Eine Übersicht der relevanten OSS-Lizenzen ist auf Wikipedia zu finden (Link).
Es ist schwierig für Closed Source einen Hoster zu finden. Ein weniger bekannter Hoster der auch Closed Source Projekte akzeptiert ist Origo. Natürlich hat man auch die Möglichkeit eigene Softwareinstallationen einzusetzen z.B. bietet sich da TRAC an.

Update:
Leider scheitere ich an der Issue-Tracker-Integration von Origo in Eclipse. Der entsprechende Connector liefert leider einen Fehler.