Agile mit Super Powers

Superboys: Edict-Abhilekh on Pixabay

tl;dr Scrum Rollen superpowern: Es gibt viel zu tun. Deshalb muss man Fähigkeiten zusammenlegen: Scrum-Master coacht auch agile Technologien, Product Owner macht UX-Design, Visual-Designer kann Frontend-Programmierung, Entwicklungsleiter ist Technik-Coach für Product Owner.

In der realen Welt haben wir mehr Rollen, als die bekannten Scrum-Rollen: Scrum Master, Product Owner und Entwicklerin.

Außerdem gibt's da noch:

• Tester, die Test-Ingenieure sein sollten, nicht Durchklicker, sondern Integration-Test-Entwickler und Test-System Managerinnen,  
• Admins, früher Operator, jetzt Devops, also Devs mit Leidenschaft für Betrieb, 
• Systemarchitektinnen, die sich oft aus den Entwicklern rekrutieren und auf jeden Fall aktiv in den Entwicklungsteam sein sollten, vielleicht organisiert in Communities of Practice, aka Chapters, 
• UX-Designer, ständig ein bisschen gebraucht, denn bei jedem Feature mit Business-Value für Benutzerinnen ist UX wichtig, 
• Visual-Designer, soll ja auch gut aussehen, oft zwischen mehreren Teams geteilt oder sogar extern bei einer Agentur oder beim Auftraggeber. Burst-artige Arbeitslast und deshalb immer in der Gefahr, die Entwicklung aufzuhalten. 
• Produkt Managerin, die auch gewillt ist mit dem Agile-Team ins Eingemachte zu gehen und zusammen was umzusetzen. Phantastisch, wenn sie nicht aufhört bei Marktpotential/Marktbeobachtung und Anforderungen, sondern selbst die User Stories scheibt. 
• Marketing, Vertrieb, Controlling, Management… sind auch nötig, damit was geht, schon klar.

Von den Entwicklerinnen verlangt man heute viele Fähigkeiten:

• Frontend und Backend, jeweils mit ihren aktuellen (und schnell wechselnden) Frameworks, 
• Unit Tests ohne Zeit-Overhead während des Codings "einfließen" zu lassen, 
• Integration-Tests und GUI-Tests aufzusetzen und up-to date zu halten während sich UX Workflows ändern, 
• Beherrschung von Continuous Integration/Deployment Systemen, 
• Container und Orchestrierung, 
• Virtuose Bedienung von Code Repositories für Quellcode, Pakete, Container (Stichworte: GitFlow, nuget/PEAR, Dockerhub). Nicht nur benutzen, sondern auch bereitstellen, intern und extern. 
• Code Reviews und Refactoring
• Code-Metriken
• Kenntnis und Benutzung von Monitoring-Systemen für Alarm, Dashboard und KPIs, 
• Clean Code, Design Patterns, Entwicklungsumgebungen und deren Extensions, 
• Security (in Code, Libraries aus Repos?, Operating), 
• Reliability-Engineering, 
• Skalierung (Up and Out)
• Konfiguration der APIs und GUIs diverser Cloud-Anbieter und Meta-Cloud-Services, 

usw.

Unter den Entwicklern gibt es Spezialisten für das alles. Aber nehmen wir ein Team von 7, (UX-) Designer, Tester, Admin (ähm, Devops), Frontendler, Backenderin. Eigentlich sollen alle alles können, aber nicht jede, die Microservices containerisiert ist gleichzeitig ein CSS3-Wizard. Dann wird es langsam eng mit den oben genannten Spezialfertigkeiten. Coden sollen sie ja auch noch. 

Warum machen wir das alles?

Damit Features entstehen. Features, die User glücklich machen. Features entstehen durch Coding. Ohne Coding keine Features. Viel Coding - viele Features, wenn sonst alles stimmt.

Fragt man in der Retro "was hat dich in diesem Sprint vom Coden abgehalten?" - typische Antwort: "Meetings", aber auch immer öfter "Infrastruktur" und vor allem: Infrastruktur aneignen, neu lernen und verstehen. 

Ganz viel dieser Infrastruktur macht uns agil bzw. ist nötig für agile Arbeitsweise über Scrum/Kanban hinaus:  Continuous-*, Container, Cloud, Clean Code, Frameworks, Repositories…

Die Infrastruktur hat gemeinsam: Sie ist aufwändig für jede einzeln zu lernen, aber notwendig, und wenn erstmal gelernt, dann völlig OK. Aber bis dahin dauert es.

Man kann das nicht alles den Entwicklern aufbürden, deshalb verteilen wir das:

Superpower #1: Agile-Coach mit agiler Technologie

Es könnte/sollte/müsste die Aufgabe des Scrum-Masters sein, agile Technologien in das Team zu tragen, so wie auch agile Arbeitsweisen in das Team getragen werden. Natürlich soll die Scrum-Masterin nicht dauerhaft den Build-Server betreuen (obwohl sie das kann, wenn sie mehrere Hüte aufhaben will/kann/soll). Es geht darum, dass der Agile-Coach das Wissen in das Team trägt, damit nicht immer wieder wertvolle Entwicklerzeit darauf verwendet wird, zu lernen, wie man einen KPI-gesteuerten Continuous Deploment Prozess konfiguriert. Und wenn wir schon dabei sind: Es ist auch die Aufgabe des Agile-Coaches, die Beschäftigung mit Clean-Code und Design-Patterns zu stimulieren, vielleicht sogar selbst zu schulen, zumindest aber die Seniors dazu zu bringen, dass sie ihr Wissen teilen. Aber dazu muss man wissen, was es zu teilen gibt. Sorry, liebe SMs aus dem Persönlichkeitscoaching, eine agil-technische Scrum Masterin macht das Team nicht nur glücklicher, sondern auch schneller, viel schneller. Und mit "schnell" kommt dann auch "glücklich": Superpowered Scrum-Master.

Superpower #2: Product Owner mit UX-Design

Bei allen Features mit Business-Value für Endbenutzer ist UX wichtig. Coding ist dafür da, dass die Funktion funktioniert. Aber "glücklich" werden Benutzer durch gutes UX-Design, nicht nur schöne GUIs, sondern vor allem gute Workflows. Ein Product Owner gießt die Stakeholder-Anforderungen in User Stories. Bei fast jeder Story ist UX-Design nötig, zumindest Grundkenntnisse, besser umfassende. Eine gute UX-Designerin kann lernen, wie man User Stories schreibt und vielleicht sogar wie man mit Stakeholdern redet. Aber ob ein Product Owner UX lernt? UX-Design ist ein Beruf und gottgleiches User-Story Schreiben eine Berufung. Erst die klassische Ausbildung: gute Anwendungen entwerfen, dann die agile Spezialfähigkeit: User Stories und Kommunikation: Superpowered Product Owner.

...und weil wir schon dabei sind. Das wäre auch toll:

Superpower #3: Visual-Designer mit Frontend-Programmierung

Wenn die Visual-Designerin gut ist, wird die Anwendung schön. Wenn sie das, was designed wurde, auch umsetzen kann, ist es toll für alle. Denn dann muss sie das Design nicht an den Entwickler übergeben. Es gibt keine Rückfragen, keine Verzögerung, keinen Mind-Bruch. Sie kann beim Design gleich die technischen Randbedingungen berücksichtigen. Keiner muss der CSS-Sklave für die Designerin sein. Die Arbeitslast ist viel ausgeglichener, so dass man kann sich eine ganze Designerin exklusiv pro Team leisten jund nicht mehr UX-Designer zwischen Teams teilen muss: Superpowered Designer.

Superpower #4: Entwicklungsleiter mit Technik-Coach für Product Owner

Viele Product Owner kommen nicht aus dem technischen Bereich. Das ist gut so, um die Entwicklung mit dem Produktmanagement zu verzahnen. Auf der anderen Seite ist es von Vorteil, wenn die User Stories so geschrieben werden, dass sie 1. in die Gesamtarchitektur passen und 2. die Entwickler verstehen und machen, was gemeint war. Für beide Fälle ist es gut, wenn jemand aus der Technik den Product Owner bei der Formulierung der User Stories berät. Eigentlich sind die Entwicklerinnen die technischen Berater des Product Owners. Aber das kostet Entwicklerzeit, oft von allen. Deshalb bürden wir das lieber der Entwicklungsleiterin auf. Die Entwicklungsleiterin kennt die Gesamtarchitektur, die IT-Strategie und sie versteht wie Entwickler denken. Sie schreibt nicht die Stories um. Nur der PO schreibt User Stories. Aber eine Entwicklungsleiterin kann durch Fragen den Product Owner dazu bringen, die Stories so zu schreiben, dass die Entwickler die Stories verstehen und dass sie in das Gesamtkonzept passen. Eine Stunde pro Woche und Team reicht, um die technische Qualität der User Stories deutlich zu verbessern. Die Entwicklungsleiterin kann so wissen was passiert und gleichzeitig etwas steuern. Die Stunde pro Woche mit dem PO ist das effizienteste Steuerungswerkzeug der agilen Entwicklungsleiterin, ohne den agilen Prozess zu verletzen. 

Heute sind viel mehr Fertigkeiten nötig. Man muss Fähigkeiten zusammenlegen. Nicht nur bei den Entwicklern, denn die sollen entwickeln. Alle müssen mehr machen und mehr können als bisher. 

Niemand hat gesagt, dass Superkräfte einfach sind.

#SuperPoweredAgile

_happy_powering()

Feature Flags

(Image: bytearrays.com)

In one of my projects I just stumbled across the topic "Feature Flags".

Feature flags (aka Feature Toggle, aka Feature Switch) let you enable program/web site features selectively. This is especially important in continuous delivery environments where code is always committed and deployed even if a feature is not ready for prime time. It can be useful if you have a large user base and want to introduce the feature incrementally by enabling the feature for sub-sets of users. Feature flags are useful in anything beyond toy apps.

Feature flags are not new. They are widely known since Martin Fowler blogged about the pattern. He did not invent them. Many good developers have been using feature flags or alike for a long time. But Martin Fowler recognized feature flags as a remarkable pattern. Writing about feature flags was a good idea, because other developers who are not aware of the pattern can learn from it. That was 2010.

Guess what, in 2006 a lonely Weblin programmer added feature flags to the Weblin portal. Weblin has been using feature flags from the start.

_happy_flagging()

Entwickler Kennenlernen

Bei Startups ist das Team meistens klein. Da hängt der Erfolg des Unternehmens von jedem Einzelnen ab. Deshalb versuchen wir immer wieder ein starkes Team zusammen zu stellen, das alle Entwicklungsherausforderungen meistern kann.

Am Anfang ist es sehr schwer Entwickler/innen einzuschätzen. Der eine behauptet, eine Programmiersprache zu kennen, hat sie aber nur in der Vorlesung gesehen. Die andere gibt an "nur so ein bisschen zu programmieren", aber nicht richtig. Später kommt heraus, dass sie die Benutzerverwaltung für das Wohnheim als Webanwendung nebenbei gemacht hat und auch noch eine iPhone App dafür.

Und dann gibt es noch so viele Technologien. Keiner kann alles abdecken. Es ist fast unverschämt eine Web-Entwicklerin nach XAML zu fragen oder einen Hobby-Gamemodder, der gerade von der Schule kommt, nach Scrum. Trotzdem haben alle, die offen, aktiv und selbstmotiviert sind, das Potential großartige Developer zu sein.

Aber irgendwo muss ja anfangen. Deshalb hier meine kurze Liste von Themen, die mich brennend interessieren, wenn ich jemand von der programmierenden Menschheit kennen lernen will.

1. Technologie

Wie gut würden Sie Ihre Fähigkeiten als Programmierer/in einschätzen.

Auf der Skala von:

- Thema bekannt (gelesen, gehört, Vorlesung in der Uni)

- Etwas Praxis (probiert, Übungsaufgabe, mal verwendet)

- Viel Erfahrung (Profi-Level, kenne ich ziemlich gut)

- Ausgezeichnet (Wizard-Level, könnte das Ding selber schreiben)

Wizard-Level bedeutet, z.B. bei XML einen XML Parser selbst zu schreiben, nicht "nur" einen XML Parser zu benutzen. Wizard-Level heißt den PHP Interpreter selber schreiben können, einen HTTP-Server, JUnit nicht nur benutzen, sondern eine alternative Unit Test Library selbst schreiben

Java, C#
MySQL
HTTP
HTML/CSS
SOAP
XMPP
JSON
OAuth
TCP/IP
boost, STL
Eclipse
CVS, Subversion, Git
Win32, MFC, COM, XAML
3D-Engines, welche?
Selenium
PHP, Python, Ruby on Rails, Perl
MS SQL Server, Oracle
XML
JavaScript
REST
Ajax
COMET, BOSH
Objective-C , Scala, Groovy, Erlang
C, C++
gcc
Profiling
EC2, S3, SQS
wxWidgets, Qt, Gtk
Maven, Ant, Hudson/Jenkins
Spring, Hibernate
Javascript Libraries, jQuery, ExtJS, andere?
Netzwerk Programmierung, sockets, andere?
Concurrency, Mutex, pthread, andere Thread-APIs?
Assembler, welche?
DevStudio, welche Versionen?
Text Editoren, was verwenden Sie zum Programmieren/Scripting?
Web-Server, Application Server, Tomcat, Apache, andere?
Template Engines, welche?
Caches, Memcache, Redis, Terracotta, andere?
Browser Extensions, für welche Browser?
Unit Test Frameworks, JUnit, NUnit, andere?
Logging Frameworks, log4net, log4j, andere?

2. Methodik

Wie gut kennen und wenn ja, seit wann verwenden Sie:

Objektorientierte Entwicklung
Agile Entwicklung
TDD
BDD
SOLID
DRY
MVC
Refactoring
Unit Tests
Automatisiertes UI Testing
Automatisierte Integrationstests
Code Coverage Analyse
Coding Conventions
Frequent Releases, wie "frequent"?
Pair Programming
Software Design Patterns
Scrum als Developer, Scrum Master, PO
Refactoring- und Coding-Werkzeuge in Entwicklungsumgebungen

3. Allgemein

Haben Sie Computer zuhause?
Welche(s) Betriebssystem(e)?
Einen Rechner oder ein Netzwerk?
Haben Sie eine Website? welche URL?
Bloggen, Twittern Sie oder benutzen Sie andere Social Networks?
Können Sie Linux installieren und verwalten? Welche Distribution?
Auf welchen Plattformen programmieren Sie? Windows, Mac, Linux, iOS?
Haben Sie Cross-Plattform Erfahrung?
Programmieren Sie gerne?
Programmieren Sie viel? wie viel? gut? sehr gut?
Haben Sie an Open-Source Projekten mitgearbeitet? welche?
Gibt es öffentlich zugängliche Projekte? URL?
Können Sie Code oder andere Arbeitsproben zeigen?

Neue Wege im IT-Management: Artikel im VentureCapital Magazin 12/2009

Im aktuellen Heft vom VentureCapital Magazin ist mein Artikel über Scrum erschienen (Volltext wegen Copyright nicht frei verfügbar).
Keywords: IT-Management Agile Entwicklungsmethoden Investoren Internet-Startups Softwareentwicklung Pitch Projektsteuerung Scrum Cloud-Computing Open Source Kapitalgeber Time to Market Scrum eliminiert Unproduktivität "The Mythical Man-Month" Frederick Brooks wenige Funktionen Output mit Scrum verbessert Scrum-Prinzipien doppelte Geschwindigkeit Games- und Internetbereich Microsoft, Intel, Yahoo, Accenture, Adobe und GE Healthcare Enfant Terrible Mainstream Jeff Sutherland OpenView Venture Partners Venture Capitals Erfolgschance Investments Qualität Effizienz Due-Diligence Prüfung Impediments Hindernisse Heiner Wolf Gründer CTO virtuelle Welt weblin 3 Mio. User Chief Scientist Open Virtual World Projekt Social Games und Virtual Goods

High-tech Businesslogik bei bluehands

Am Freitag habe ich meine alte Firma bluehands in Karlsruhe besucht und ich bin sehr beeindruckt. Bluehands macht Softwareentwicklung auf hohem Niveau. Die Kernkompetenz liegt bei der Umsetzung von Projekten mit .NET für Webanwendungen, Datenbank- und Backend, sowie komplexe branchenspezifische Businesslogik. "Umsetzung" ist dabei ein zentrales Wort. Denn das beginnt bei der Planung und Denken mit und für den Kunden und endet erst wenn das System im Produktiveinsatz läuft.

Selten habe ich so "dichte", kontrollierte und hochwertige Softwareentwicklung gesehen. Die Zahl der Projekte ist beeindruckend. Die hohe Qualität bei dieser Geschwindigkeit ist nur zu halten durch Agile Entwicklungsmethoden und ständige Innovation. Mittel wie Scrum, Nightly Builds, Unit Tests, automatische Codeanalyse, Versionskontrolle, DRY, KISS, Continuous Integration sind selbstverständlich. Dazu kommen Research-Projekte, Coder-Seminar, Effizienzanalyse und interne Weiterbildung. Aktuelles Beispiel: die Clean Code Developer Initiative.

Wer also eine Visualisierungslösung braucht, z.B. im Energiebereich oder in verarbeitenden Gewerben, wie Metall und Bau, oder ein komplexes Planungstool, wer will, dass bei der Planung mitgedacht wird und, dass das System installiert wird und dann läuft, dem kann ich www.bluehands.de nur empfehlen.

Und wir anderen Coder (zumindest die meisten) können da noch was lernen. Wir sind ja auch nicht schlecht organisiert (zumindest die meisten), aber da kann man sich eine Scheibe von abschneiden. Das ist den Jungs bei bluehands selbst wahrscheinlich gar nicht so bewußt. Two thumbs up.

happy_coding()

The Lean Startup

Just hear this talk...
http://www.slideshare.net/venturehacks/lean-startups-at-web-20-expo?type=powerpoint

That was our plan. Much was implemented. But it was totally warped because a "great manager" knew better than anyone else, even better, than successful companies in the same field.

Barcamp Hannover 2008

Am Wochenende war Barcamp Hannover. Sehr angenehme Atmosphäre, etwas kleiner aber entspannter. Wieder viel gelernt und viel diskutiert.

Selbst eine Session gemacht zum Thema "Agile Development, Scrum, Unit-Testing" und dabei vorgestellt, wie wir die Techniken bei Zweitgeist anwenden bzw. umsetzen. Volle Session, Gute Diskussion.

Snippets von den Dingen, die ich mitgenommen habe:
- OpenID wäre eine coole Sache für Weblin. Nicht der Stein der Weisen bei Usergewinnung, aber es zeigt in die richtige Richtung. OpenID, OpenSocial, Mashups, SocialGraph sind wichtige Themen für weblin. Zum Teil sind wir sogar schon dran.
- HTML ist der Assembler des Web. Browser die Prozessoren. Es wird Zeit, dass wir mit Compilern arbeiten, die den Code generieren. Web-Programmierer sollten nicht "echo
" schreiben müssen, sondern aufgrund von Benutzereingaben und Zustandsänderungen Displayzustände beschreiben, die dann je nach Endgerät in HTML 4/5, XML, Braille, Mobile, etc. ausgegeben werden.
- Trete 3 Meter zurück und sieh dir deine Website an. Leser sehen das was du jetzt noch siehst. Es soll wichtigsten Punkt geben, ein Produkt, das worum es geht, nicht 100 gleichstarke Optionen oder gar viel Beschreibungstext.
- Während wir eine Menge Theorie über "Virtuelle Güter" gelernt haben: Idee entwickelt zum Thema "Kopierschutz bei verteilter Datenhaltung ohne vertrauenswürdige Clients". Digitale Signatur über UserID und Daten zur Echtheitsverifizierung. Das geht solange sich genügend Clients daran halten und sich Kopieren nicht lohnt, weil der Content bei genügend Benutzern nicht angezeigt wird.
- Twitter ist überall. Warum hat niemand früher ein 1-to-many Messaging gemacht? Instant Message 1-to-1 gab es schon lange, 1-to-many Bloggen auch. Aber es hat bis 2006 gedauert bis die Welt die Power des 1-zu-n Channels erkannt hat? Der Hype kommt aus der Kombination des 1-zu-n "FanOut", dass ich sende in Verbindung mit dem m-zu-1 Trichter, den ich empfange, Filtern dazwischen und sehr einfachen I/O APIs. Sehr cool. OK, Jabber-PubSub war schon da, aber zu komplex. Simplifikation !
- Wie bei jedem Barcamp sind alle überrascht, dass nur 60% kommen. Welches Orga-Komitee traut sich als erstes zu überbuchen? wie jedes Hotel, jede Fluggesellschaft, jede Privatparty. Was kann im "Worst-Case" passieren? Die Schnittchen gehen aus und die Räume sind zu voll. Und dann war es ein Erfolg.

_happy_camping()

Twincoding Light

Twincoding ist eine der "Empfehlungen" der Xtreme Programming Methodik. Twincoding heißt, dass 2 Programmierer vieles zusammen programmieren.

Aber kann man es sich überhaupt leisten zwei Programmierer mit der gleichen Sache zu beschäftigen? Ich kann ja nicht meinem Kunden sagen: Bei uns ist alles doppelt so teuer, weil wir Twincoding machen. Twincoding muss, um überhaupt konkurrenzfähig zu sein, mindestens so produktiv sein, wie Einzelcoding. Das ist nicht einfach, aber möglich.

Die Theorie sagt, dass man Programmierfehler vermeiden kann durch das zweite Augenpaar. Die Vermeidung der Fehler wiegt den Mehraufwand wieder auf. Das kann nur stimmen, wenn man beim Twincoding keine Fehler macht und beim Einzelcoding mindestens 50 % der Zeit ineffizient mit Fehlern und Problemen verbringt, die man zu zweit nicht gehabt hätte.

Die Annahme, dass beim Twincoding keine Fehler auftreten ist sicher nicht ganz richtig. Teilen wir die Fehlerzeiten ein in Flüchtigkeitsfehler, Denkfehler und Blockaden. Flüchtigkeitsfehler kosten sehr oft wenig Zeit. Sie fallen meist schon beim Compilerlauf auf und werden schnell behoben. Dafür geht es aber um sehr viele Ereignisse. Flüchtigkeitsfehler werden bei Twincoding tatsächlich stark unterdrückt. Hier liegt Twincoding klar vorne. Die Behebung von Denk- und Architekturfehlern kostet wesentlich mehr Zeit, als die von Flüchtigkeitsfehlern. Und nicht nur die Korrektur kostet Zeit, sondern auch die Produktion des Fehlers. Erfahrungsgemäss reduziert sich die Wahrscheinlichkeit für Denkfehler deutlich, aber sie verschwindet nicht. Auch 2 Leute können sich gegenseitig von Unsinn überzeugen. Trotzdem ist sicher die Denkfehlerzeit geringer im Twincoding. Der Vorteil wird allerdings meistens mit einem höheren Kommunikationsaufwand bezahlt, das sich 2 Leute über Modelle und Architekturen verständigen müssen. Der Aufwand ist nicht unerheblich, wenn die beiden nicht sehr kompatibel sind. Die dritte Fehlerzeitquelle sind Blockaden, wenn Detailprobleme den Fluss unterbrechen. Diese können von Tools, Fremdfehlern (z.B. Libraryfehler) oder Informationsdefiziten herrühren und unheimlich viel Zeit und Motivation kosten. Oft kann eine zweite Sichtweise und ein komplementäres Wissen den Konten viel schneller lösen.

Flüchtigkeitsfehler kosten nur wenige Sekunden oder Minuten. Denkfehler kosten zig Minuten oder Stunden, selten Tage. Blockaden kosten oft Stunden oder Tage. Bei allen Fehlerarten kann Twincoding deutlich helfen. Ich schätze, dass gute Programmierer, die Dinge programmieren von denen sie etwas verstehen, aber trotzdem nicht die Hälfte Ihrer Zeit mit Fehlern verbringen, die durch Twincoding vermieden worden wären. Denn ein Teil der Programmierzeit besteht aus Routinearbeiten und Tests, die sich nicht beschleunigen lassen . Ob Twincoding wirtschaftlich gerechtfertigt ist, hängt vom Einzelfall ab. Oft müssen Routinetätigkeiten ins Einzelcoding verschoben werden mit der Gefahr von geringem Synchronisationsverlust. Selbst für den Spezialfall von zwei guten und gut abgestimmten Programmierern kann man keine klare Aussage treffen aufgrund der Reduzierung von Fehlerzeit. Die Effizienz von Twincoding ist fraglich.

Entscheidend ist der Faktor Motivation. Zwei Programmierer lassen sich weniger ablenken. Sie fangen früher an und bleiben länger bei der Sache. Mit anderen Worten: sie lesen nicht morgens Onlinezeitung und 10 mal am Tag zwischendurch Email. Sie verlagern projektunabhängige Wartungstätigkeiten auf den Abend und lassen sich weniger von Zwischenrufen anderer Kollegen ablenken, weil man den Partner nicht gerne warten lässt. Gemeinsame Motivation kann Twincoding ins Plus schieben.

Trotzdem sind 150 Euro pro Team-Programmierstunde ziemlich viel. Wenn man die Kosten reduziert, dann geht Twincoding deutlich ins Plus. Wir ersetzen deshalb gerne einen der zwei Programmierer durch einen Aufpasser. Der Aufpasser muss nicht ein erfahrener Programmierer sein, sondern z.B. ein guter Praktikant. Der Aufpasser vermeidet genauso gut Flüchtigkeitsfehler. Er hat etwas weniger Einfluss auf Denkfehler und Blockaden. Ist der Aufpasser nicht beteiligt an der Architektur, dann kann er wenig helfen Denkfehler zu vermeiden. Andererseits hat der Leadprogrammierer die Chance bei Erklärungen die Denkfehler selbst zu entdecken. Der korrigierende Einfluss des Aufpassers auf Blockaden kann genauso gut sein, wie bei einem erfahrenen Programmierer. Der Aufpasser hat eher ein komplementäres Wissen, als ein langjähriger Kollege und kann deshalb manchmal besser sein, als der zweite Programmierer. Die Motivationsfunktion wird vom Aufpasser genauso gut ausgefüllt.

Zusammenfassend verliert Twincodig-Light wenig Performance gegenüber traditionellem Twincoding während die Kosten deutlich sinken.

_happy_coding_

Understand what you are doing

Bluehands bildet aus. Wir haben BA Studenten und Praktikanten. Wer bei uns arbeitet, lernt viel. Wir bringen niemandem das Programmieren bei und schon gar nicht den Spass am Programmieren. Was man bei uns lernt sind Technik und Methodik. Wir zeigen wie man richtig programmiert. Wir nehmen uns dafuer viel Zeit, denn wir haben einen Qualitätsanspruch. Wer bei bluehands gelernt hat, versteht sein Handwerk und kann solide Programmieren. Wir versuchen gute Hobbyprogrammierer zu Profis zu machen.

Eine der wichtigsten Lektionen ist dabei, dass Programmieren kein Gluecksspiel ist. Programmieren is bewusste, kontrollierte, zuverlaessige Konstruktion. Die Programmiererin MUSS verstehen was sie tut. Sie muss jede Zeile begruenden koennen. Code, der nicht mehr gebraucht wird, fliegt raus. Wer Code stehen laesst nur weil es momentan so funktioniert, ohne zu wissen warum und welche Teile wirklich wichtig sind, versteht nicht, was er tut. Das ist ein schlechtes Zeichen, denn auch ueberfluessiger Code tut etwas, und zwar genau dann wenn man nicht damit rechnet, weil man ihn ja nicht verstanden hat. Unverstandener Code ist heimtueckisch. Er springt einen von hinten an, wenn man ihm den Ruecken zudreht; besonders gerne nach dem Deployment der Software beim Kunden.

Deshalb: keine Macht dem unverstandenen Code. Understand what you are doing. Always!

_happy_coding_

Immer anstaendig bleiben

Immer wieder kommt es vor, das mal mal eben so nen Code schreibt, um was zu testen, mal eben schnell was kleines zu fixen und was herzuscripten. In solchen Faellen ist man doch immer versucht das mal eben schnell hinzuschreiben ohne auf Formatierung, korrekte Namensgebung, Fehlermeldungen usw. zu achten. Man return-ed mal eben wo es so passt und laesst die Fehlerbehandlung grad mal weg. Die ruestet man ja spaeter nach, falls der Code was dauerhaftes wird. Dann kann man auch gleich alles noch mal richtig benennen. "Ich mach das jetzt mal und wenns laeuft mach ich die Fehlerbehandlung". Pfui.

Das bringts nicht, weil...
1. Wir sind nicht dumm und oft laeuft der Code tatsaechlich.
2. Der meiste hingesketchte Code wird doch nie mehr weggeschmissen sondern weiterentwickelt und wird irgendwann produktiv.
3. Es ist echt uncool spaeter nochmal ueber den Code zu gehen und Fehlerbehandlung nachzuruesten. Dann muss man sich nochmal in alles genau hineindenken. Was fuer eine Zeitverschwendung.
4. Code lebt laenger als man denkt. Was total nervt sind Provisorien, die einem Jahre lang peinlich sind.
5. Ordentlicher Code ist stabiler als unordentlicher. Das gilt auch fuer Testcode.

Nur mittelgute Programmierer, die sowieso viel Code wegwerfen und ueber vieles nochmal drueber gehen muessen, damit es geht, koennen sich das erlauben. Gute Programmierer haben gar keine Zeit dafuer. Die programmieren es gleich richtig, ordentlich und anstaendig.

_happy_coding_