Am Freitag und Samstag war in Stuttgart das DroidCamp Stuttgart 2010.
Da ich in letzter Zeit verstärkt mit Android-Entwicklung zu tun hatte, durfte ich dort nicht fehlen. Es war ein Barcamp wie es sein sollte: offen, sympathisch, persönlich und mit viel Freude an der Sache umgesetzt. Vielen Dank an das Orgateam dafür, ihr seid echte Helden!
Neben den Sessions gab es auch wieder viele interessante Disukussionen rund um die LessCode-Initiative. Auf Barcamps ist es üblich, dass die Zeiten zwischen den Vorträgen mindestens so interessant sind wie die Sessions selbst, und so fand ich das auch hier.
Ich habe die Idee hinter LessCode natürlich oft erklärt, und sie erhielt viel Zustimmung. Java als Sprache ist zu „boilerplate“ und „overengineered“, auch die Idee, dass das Fehlen von statischer Typisierung zwar einen Nachteil darstellt (der durch sowieso praktiziertes Testen stark minimiert wird), der aber durch viele andere Vorteile deutlich überwogen wird.
In letzter Zeit halte ich viele Gespräche mit Entwicklern und Entscheidern gleichermaßen und auch auf dem DroidCamp ging es um die Soft-Faktoren rund um die Entscheider, mit der sich die Idee hinter LessCode in der Praxis schwieriger umsetzen lassen: Wie erreichen wir die Entscheider und wie finden sie den Mut, eine neue Technologie in einem Projekt einzusetzen?
Folgende Ansätze zur Verbreitung haben sich bisher herauskristalliert: » Weiterlesen: DroidCamp Stuttgart 2010
Archiv für Juni 2010
DroidCamp Stuttgart 2010
24 Juni 2010Agile Softwareentwicklung mit Hibernate, Spring, Eclipse
24 Juni 2010Heute war ich in Karlsruhe in einem Workshop im Rahmen der Entwicklertage. Thema: „Durchstarten – Agile Softwareentwicklung mit Hibernate, Spring, Eclipse„. Ich habe diesen Workshop bewusst gewählt, da sie laut Beschreibung den Anspruch hat, agile Praktiken anhand dieser Technologien zu zeigen. Das hat sie auch voll erfüllt, keine Frage.
Allerdings sah ich mich auch in meiner Meinung bezgl. der „Geschwätzigkeit“ dieses Technologiestacks voll bestätigt. DRY ist anders. Es handelte sich um eine für einen Workshop vorbildhaft große Beispielapplikation, an der wir diverse agile Methoden praktizierten, also Einarbeitung in ein fremdes Projekt, Feautererweiterung im Sprint, Bugfixing von Legacy-Code usw.
» Weiterlesen: Agile Softwareentwicklung mit Hibernate, Spring, Eclipse
Von agilen Methoden und Technik-Monstern
23 Juni 2010Agile Software-Entwicklungsmethoden, insesondere Scrum, haben sich inzwischen als ernsthafte Alternative etabliert, es gibt eine große Gruppe zufriedener Menschen, die sie täglich praktizieren.
Es gibt viele Mitteln und Wege, die für die tägliche Umsetzung dieser Methoden genutzt werden. Das Team praktiziert diese Rituale (Sprint, Daily Scrum, Retrospektiven usw.) gerne, denn sie passen sehr gut zur agilen Denkweise. Meist setzen sich die Team-Mitglieder nach dem Daily Scrum an die Tastatur und den Compiler, und schon ist die Agilität wieder verflogen…
Agile Methoden und der Placebo-Effekt
15 Juni 2010Gestern Abend war ich auf einem Vortrag der Scrum User Group Karlsruhe. Er fand bei der NetViewer AG statt und als Speaker war Linda Rising zu Gast!
Ravioli Code
10 Juni 2010Ich habe schon oft über das Phänomen nachgedacht, aber noch nie einen passenden Begriff dazu gefunden. Und gestern auf dem JUG-KA-Vortrag fiel er endlich: „Ravioli Code“
Der Begriff „Spaghetti Code“ sollte bekannt sein. Er beschreibt die Unübersichtlichkeit von Code aufgrund wilden Hin- und Herspringens.
„Ravioli Code“ beschreibt, dass der relevante Businesscode über zu viele kleine (in diesem Fall Java-)Klassen verteilt ist und man sich deshalb den Programmablauf mühsam aus all diesen „herausfischen“ muss. Also bspw. um am Ende 25 Zeilen Businesslogik zu verstehen ist es notwendig, das Zusammenspiel von 10 verschiedenen Klassen zu analysieren.
Ich bezeichne dieses Symptom, das m.E. in der Javawelt oft anzutreffen ist, gerne als „Over-Engineering“, und ist mit ein Grund für die Idee von LessCode.
Ich bin mir sicher, dass das alles etwas weniger dramatisch wäre, wenn die Sprachsyntax von Java endlich mal Closures bekäme, aber nichtmal für Java 7 wird es wohl so sein.
Statische vs. Dynamische Typisierung: Overengineering im Kleinen?
10 Juni 2010Ein anderes Flurthema auf der JUG-KA war mal wieder statisch vs. dynamisch typisierte Programmiersprachen (konkret: Ruby und Python vs. Java)
Die Java-Fraktion fühlt sich sicher dank Typüberprüfung schon zur Compilezeit oder während der Code-Erstellung und fühlt sich wohl durch die IDE, die Code Completion und die Refactoring Tools.
» Weiterlesen: Statische vs. Dynamische Typisierung: Overengineering im Kleinen?
Vortrag JUG Karlsruhe: Extremes Testen
10 Juni 2010Gestern abend war ich auf einer Veranstaltung der Java-User-Group Karlsruhe.
Das Thema war „Testgetriebene Entwicklung – vom Dogma zum Pragmatismus“ vorgetragen von Martin Schneider und allein schon durch die ähnlichen Taglines (LessCode proklamiert „Pragma statt Dogma“), musste ich mir das anhören.
Beeindruckend fand ich die systematische Erfassung der „test smells“ (analog der „code smells“ von Kent Beck): Es geht um die Kategorisierung von nicht optimalen Tests. Z.B. gibt es Tests, die deshalb nicht gut sind, weil sie zuviel auf einmal testen, weil sie ein zu komplexes Testsetup erfordern, Tests die kopiert und nur wenige Zeichen abgeändert werden oder Tests, die nur manchmal fehlschlagen (Eine Auflistung findet sich z.B. hier)
Vorstellung
10 Juni 2010Herzlich willkommen zum ersten Blog-Eintrag von LessCode!
Mit LessCode.de strebe ich eine Plattform an, über die sich Menschen austauschen, die im Software-Entwicklungs-Umfeld arbeiten und täglich weinen könnten über die Verschwendung von Entwickler-Resourcen aufgrund – um es mal abstrakt auszudrücken – für sie nicht nachvollziehbarem Verhalten Ihrer Umgebung.
LessCode soll Mut machen zur Veränderung, den Horizont erweitern, Alternativen zu festgefahrenen Strukturen aufzeigen und nicht zuletzt wie in jeder „Selbsthilfegruppe“: Aufzeigen, dass es anderen auch nicht besser geht.
Mit LessCode will ich meinen Beitrag dazu leisten, dass der Spaß des Entwicklers an seiner Arbeit wieder zunimmt und – durch die Auswahl der richtigen Werkzeuge – Projekte eher so ablaufen wie sie sollen.