Kategorien
Bugfixing outsourcen
Und schon wieder Wochenende. Also fast. Wir müssen nur noch ein paar Stunden durchhalten und dürfen dann durchstarten zu was immer wir wollen. Also zum Beispiel zuhause am PC sitzen und das gleiche machen, wie unter der Woche, nur freiwillig. Zumindest habe ich so schon einige Wochenende rumgebracht. Da ich euch gestern als Nerds beschimpft habe, muss ich mich ja auch outen.
Was ich mit euch heute mit euch durchspielen möchte dreht sich ums Outsourcing. Immer mehr Firmen lassen sich ihren Code in China oder Indien schreiben. Ist ja an sich nicht schlecht, auch wenn man oft Probleme mit der Qualität hat. In den meisten Fällen wird sich dort nicht so viele Gedanken gemacht, was Architektur und Wartbarkeit angeht. Funktionalität ist der König. Vielleicht kann man das auch gar nicht so pauschal sagen, will hier ja auch niemanden ans Bein pinkeln, aber gehen wir einfach mal davon aus, dass man mit der Qualität nicht unbedingt zufrieden ist. Übrigens die Leute, die in China gut sind, kosten auch das ähnliche wie in Deutschland, zumindest war das damals so.
Wie wäre es also, wenn man nicht Dinge wie Feature-Implementieren in fremde Hände gibt, sondern einfach nur das Fixen von Bugs? Ich meine da kann man nicht viel falsch machen. In den meisten Fällen ist das Finden ja das komplexe, nicht das Reparieren. Code verhunzen ist also eher schwierig. Natürlich müsste man die Applikation gut kennen, was seine Zeit dauern kann.
Meine Theorie ist also, dass man Bugfixing eher hinbekommen kann, auch wenn man ein schlechter Entwickler ist, als das Implementieren von neuen Features, also kann man das besser rausgeben. In Projekten in denen ich bisher gearbeitet habe, hätte das eine Menge Zeit gespart, in der die wirklich guten Leuten hätten innovativ sein können.
So jetzt wieder ihr! Was spricht für meine Idee, was dagegen? Habt ihr Erfahrungen gesammelt, die ihr teilen könnt? Ich bin gespannt.
puhh… bug fixen heißt aber auch gleichzeitig keine neuen einzuführen und den bug halbwegs sauber zu fixen – das heißt wiederum die Applikation zu kennen. wenn das ganze ohnedies über massive tests abgesichert ist, kann ich mir das auch schon eher vorstellen, aber werden dann auch neue tests geschrieben usw?
outsourcen an schlechtqualifizierte ist IMO nie eine gute Idee
„Ich meine da kann man nicht viel falsch machen. “
Ich meine, daß die Wirklichkeit täglich das Gegenteil beweist!
Naja, Bugs externen fixen zu lassen heißt ja auch, den Code rausgeben.
Dabei achte man auf folgende Möglichkeiten:
1. Firma hat nur ein Produkt: Die Gefahr ist dann groß, dass der „Kern“ kopiert wird und evtl. alleinstellungsmerkmale offen liegen; evtl. folgen erhebliche finanzielle Verluste dadurch.
2. Firma hat Kundenprojekte: Dann gibt man Kundendaten raus, die evtl. dann auch irgendwo auftauchen; darauf folgt ein Imageschaden, wenn der Kunde das spitzbekommt und den darauf folgenden finanziellen Schaden möchte ich mir gar nicht erst vorstellen.
Also, ihr merke, ich habe da nicht nur erhebliche Bauchscherzen, ich würde niemals Code an „externe“ abgeben, die ich nicht wirklich kenne und (nun kommt ein sehr wichtiger aspekt) den ich nicht evtl. verklagen kann – kenne mal die Rechtslage in China und vor allem „Recht haben, Recht bekommen“.
Kurz: Ich würde niemals die Empfehlung geben, Projekte an externe zu geben.
hi,
ich würde einen Schritt zurück gehen und nur das _finden_ der Bugs outsourcen.
Das fixen kann nach dem Finden des Bugs nicht mehr wirklich lange dauern, und so lange man ihn selbst fixt sollte auch die Qualität nicht darunter leiden.
MfG
Gerrit Addiks
Das Outsourcen von Bugfixes verletzt das Pfadfinderprinzip. Martin Fowler schreibt, dass Code die Tendenz hat zu verrotten. Das passiert natürlich auch bei Wartungsarbeiten. Und hat man erstmal Müll in einer Ecke stehen, kann der Nächste bedenkenlos seinen Müll dazustellen.
Diesen Kreis kann man mit dem Pfadfinderprinzip durchbrechen: Hinterlasse einen Platz immer sauberer, als Du ihn vorgefunden hast. Das berücksichtigt niemand, für den Funktionalität ausschließlich im Fokus steht. Eine Wohnung kann auch „verwohnt“ werden, obwohl die Architektur beim Neubau gestimmt hat. Und in einigen Bugfixes werden sogar Architekturentscheidungen getroffen, weil die Realität anders ist, als der Entwickler vorgesehen hat.
Neben Outsourcing gibt es aktuell auch viel Nearshoring. Dabei gibt man die Aufgaben nicht gleich nach Indien oder China, sondern meist an andere Europäische Länder, z.B. Ungarn.
Meiner Ansicht nach ist das Problem bei der Idee das Bugfixing dorthin abzugeben, dass es neben technischen Bugs (einfaches Beispiel wäre ein Vertipper bei einem Funktionsaufruf, oder ähnliches) auch fachliche Bugs gibt.
Zum Beispiel aggregiert man 2 Datensätze (von was auch immer) falsch und erkennt dies. Wenn man es selber fixt und den fachlichen Hintergrund hat wo der Fehler war, schaut man selbstständig auch an andere betroffene Stellen bzw. Stellen die mit dem Fehler zusammenhängen.
Wenn man einen Fehler findet und eine einfache Fehlerbeschreibung an den Outsourcing-Partner gibt, wird dieser auch nur das dort beschriebene Ändern. Ohne andere Stellen des Codes auch nur eines Blickes zu würdigen oder einen Gedanken daran zu verschwenden (siehe deinen Artikel zu Richtlinien).
Vom Motivationsstandpunkt her würde ich das ablehnen. Leute, die nicht motiviert sind, bauen nur Mist und wenn jemand dort den ganzen Tag sitzen sollte, um fremde Fehler zu finden, um dann nur die gefundenen Fehler weiter zu geben, dann findest Du niemanden, der das wirklich dauerhaft machen wird und wenn, kann der nicht alle Tassen im Schrank haben.
Die gleiche Erfahrungen hab ich auch mit ausländischen Entwicklern gemacht. Wenn man die nicht ausreichend bezahlt, dann liefern die auch nur Schrott ab. Ich bin auch kein Fan des Outsourcen an sichs und der Glaube, dass man beim Fixen keine Fehler machen kann ist wohl auch eher „in einer perfekten Welt“.
Meiner Ansicht nach kann ein unerfahrener Bugfixer durchaus Code mindestens genauso gut „versauen“ wie ein unerfahrener Entwickler unsauberen neuen Code schreiben kann. Die Erfahrung zeigt, dass gerade fachlich nicht besonders tief involvierte Entwickler der Ursache eines Problems nicht so weit auf den Grund gehen, bis sie die richtige Stelle zur Korrektur gefunden haben, sondern meist nur soweit suchen und dort korrigieren, wo das offensichtliche Symptom des Fehlers behoben werden kann.
Beispiel: wenn ein Controller beim Auftreten von Situation A statt des gewünschten Ergebnisses X das falsche Ergebnis Y bringt, dann wird gern einfach per if auf Situation A reagiert. Die Überlegung, ob vielleicht Situation A gar nicht auftreten darf, wenn das im Controller genutzte Modell korrigiert wird, wird oft gar nicht angestellt. Oder bei dieser Gelegenheit würde ein erfahrener „Bugfixer“ feststellen, dass auch die Situationen F und J noch gar nicht im Controller berücksichtigt wurden und für diese das richtige Verhalten mitimplementieren.
@Marek: Super Beispiel, genau sowas meinte ich.
Da bin ich auch der Meinung wie die Vorredner: Man kann neue Projekte leichter outsourcen weil man bei was neuem nichts Bestehendes kaputt machen kann. Ich würde nie einen fremden (und meist unmotivierten) Programmierer meine Bugfixes anvertrauen, da hier einiges kaputt gehen kann.
Zusätzlich kann es passieren, dass wenn man einen Bug in einem sehr umfangreichen System hat, dass der Programmierer wegen mangelndem Wissen des Projektes bzw der Programmiersprache das System nicht versteht und daher blind darauf los fixt.
Wegen dem Problem dass fähige Programmierer andauernd Bugs fixen müssen:
Falls dein Projekt mehr Programmierer hat, könntet ihr es ja so lösen wie wir es in unserem Team gelöst haben:
jede Woche ist ein anderer für Tagesgeschäft und Bugfixes zuständig. Das ganze folgt einem fixen Rotierplan (dh, Bugfixing ist keine Bestrafung fürs zu spät kommen, sondern gehört einfach dazu).
Der Vorteil bei der Sache war, dass jeder von uns in Bereiche reingeschnuppert hat in die er normalerweise keinen Einblick hatte. Weiters durften die anderen Programmierer in dieser Zeit von aussen stehenden Personen nicht angesprochen werden (dh, fragen gabs auch nur über diese Person) und die anderen Programmierer konnten sich wesentlich besser auf ihre Features konzentrieren und wurden kaum mehr gestört.
Wenn sich das einspielt, sehe ich die Gefahr eines Qualitätsverlusts durch Abwälzen der Verantwortung. „An dieser Stelle rieche ich zwar einen potentiellen Bug, aber keine Zeit: ich will schnell mit den Features weiter kommen. Ach, soll der externe Dienstleister das doch fixen. Dafür wird er ja bezahlt.“
Wenn das eigene Team immer mehr Lorbeeren erntet, weil Features immer schneller implementiert werden und man auf den externen Bugfixer schimpfen kann, weil der nicht nachkommt, möchte ich nicht für die mittelfristig entstehende Code-Qualität verantwortlich sein.
@danielj: +1!
Viel besser auf den Punkt bringen kann man es nicht. Gerade das Unterschätzen des Bugfixings ist einer der schlimmsten und häufigsten Fehler in Softwareprojekten!
Zu überlegen wäre, ob man die Bugfindung auslagert. Das Beheben sollte aber nicht ausgelagert werden, weil völlig kontraproduktiv!