Wachsende technische Schulden in kleinen indischen Softwareunternehmen, die Apps und Websites entwickeln: Wer ist dafür verantwortlich?

Ich bin jetzt seit 10 Jahren in der indischen Softwaredienstleistungsbranche und während dieser ganzen Zeit habe ich gesehen, wie gute Projekte abgeschlossen wurden und Wunder bewirkten. Ich habe Skelettteams gesehen, die unter qualvollen Bedingungen unermüdlich daran arbeiteten, Produkte zu bauen, die von Menschen auf der anderen Seite des Planeten geliebt wurden. Und obwohl es in diesem Jahrzehnt großartige Erinnerungen an die Arbeit an einigen wunderbaren Projekten gab, habe ich auch erlebt, wie Projekte bergab gingen und Softwareprodukte aus verschiedenen Gründen völlig verpfuscht wurden. Es ist öfter passiert, als ich es mir gewünscht hätte, um mich herum und um Leute herum, die ich in diesen 10 Jahren gekannt habe.

Es wurde viel darüber gesprochen, dass Projekte schief gehen. Im Internet wimmelt es von Memen darüber, wie sich die gesamte Hierarchie wie eine Nahrungskette im Dschungel jagt. Einige Leute beschuldigen die Programmierer, fehlerhaften Code geschrieben zu haben, während andere Leute das Management verfluchen, weil es unpraktische Versprechungen gemacht hat, die unmöglich zu erfüllen sind. Manche werfen den Kunden sogar vor, die technischen Voraussetzungen und Abhängigkeiten dieser Branche nicht zu verstehen. Aber ich habe fast niemanden gehört, der über Technical Debt oder Code Debt spricht und mit diesem Thema auf zivilisierte Weise umgeht, ohne mit dem Finger auf den anderen zu zeigen. Nicht ein einziges Mal bin ich auf diesen Begriff der Tech-Schuld von Leuten in meiner Umgebung oder von den Veranstaltungen, an denen ich teilgenommen habe, oder den lokalen Blogs, die ich lese, gestoßen.

Auf diesen Begriff bin ich nur gestoßen, als ich Blogs und Zeitschriften aus dem Silicon Valley in den USA gelesen habe. Dies bedeutet, dass die meisten Programmierer und Software-Führungskräfte, die in kleinen und mittleren Softwareentwicklungsunternehmen in Indien arbeiten, bis jetzt noch nicht einmal von diesem Begriff gehört haben. Lassen Sie mich also damit beginnen, den Begriff selbst zu erklären. Technical Debt oder Code Debt ist ein Konzept in der Softwareentwicklung, das die implizierten Kosten zusätzlicher Nacharbeiten widerspiegelt, die dadurch entstehen, dass man sich jetzt für eine einfache (begrenzte) Lösung entscheidet, anstatt einen besseren Ansatz zu verwenden, der länger dauern würde.

Lassen Sie es mich aufschlüsseln, um es einfach zu machen. Es ist ein Konzept zur Berechnung der Kosten für die Lösung von Programmier- und Designproblemen, die möglicherweise entstanden sind, weil eine einfache Option zum Erstellen eines bestimmten Moduls oder eines gesamten Systems gewählt wurde, anstatt die beste und effizienteste Methode zum Erstellen zu wählen. Im Bereich der Softwareentwicklung tritt dieses Phänomen der Faulheit und Langsamkeit, die Sie in den Arsch beißen, viel häufiger auf als anderswo. Es ist fast so, als hätte Karma von Programmierern eine soziale Repräsentation von Zickigkeit bekommen.

Bitte verstehen Sie mich nicht falsch, ich gebe nicht den Programmierern die Schuld für die gesamte Code-Schuld. Es gibt sicherlich mehrere Einheiten, die für die Code-Schuld verantwortlich sind, die mit Sicherheit in über 90% der Projekte in kleinen Softwareentwicklungsunternehmen in Indien entsteht. Lassen Sie mich versuchen, einige davon kurz zu behandeln:

1. Ungeduldige & überschlaue Kunden

Ja, ich fange damit an, dass ich genau die Hand beiße, die füttert, und zwar rücksichtslos. Der Markt für kleine ausgelagerte Softwareentwicklungsprojekte ist riesig und stark fragmentiert. Es gibt wirklich gute Unternehmen, die diesen globalisierten Markt perfekt rechtfertigen, während andere nur Parasitenunternehmen sind, die sich von diesem vollkommen guten Arrangement ernähren, nur weil es unreguliert und unkontrolliert ist.

Dies führt dazu, dass die Kunden einen Fehler machen, wenn sie das richtige Unternehmen für eine Partnerschaft basierend auf ihren Bedürfnissen auswählen. Es ist zwar nicht ihre Schuld, dass sie keine angemessenen Überprüfungsfähigkeiten haben, aber es gibt niemanden, der dafür verantwortlich ist, dass sie keine grundlegende Straßenintelligenz haben, wenn es darum geht, eine Müllfirma von einer echten zu unterscheiden. Sobald sie sich bereit erklärt haben, mit einem untertalentierten Team weiterzumachen, würgen sie ihre unrealistischen Erwartungen und ihren Zeitplan an ihnen ab. Nicht nur das, einige von ihnen gehen sogar über Bord und zeigen, wie schlau sie sind, indem sie ihre eigenen Vorschläge in Design und Programmierung einbringen. (#notallclients )

Wenn Sie jemals Kunde einer Softwareentwicklungsfirma sind, bitte ich Sie demütig, sie in Ruhe zu lassen und ihnen zu erlauben, ihre Arbeit zu erledigen. Versuchen Sie, zu einem Arzt oder Anwalt zu gehen und ihnen zu sagen, was Sie gegoogelt haben und was dort über Ihr Problem gesagt wurde, und sehen Sie die Reaktion auf ihren Gesichtern. Kein Experte auf seinem Gebiet lässt sich gerne von einem Noob auf seinem Gebiet beraten. Software-Ingenieure sind da keine Ausnahme.

Wenn Sie ein gutes Softwareentwicklungsteam finden und es vielversprechend erscheint, geben Sie ihm seinen Freiraum, und es wird nicht den Drang verspüren, Abstriche zu machen, was zu weniger Codeschulden in Ihrem Projekt führen würde. Und raten Sie mal, meistens sind es Sie, die Kunden, die diese Code-Schulden bezahlen. Schon mal was von den Worten gehört: „Change Request“? Ich wette, die meisten von euch haben! Im Idealfall sollten Sie diese Worte niemals in Ihrem Leben hören. Aber das kommt selten vor. Und je öfter Sie diese Worte hören, desto mehr haben Sie es vermasselt, Kunde eines Softwareunternehmens zu sein.

2. FAULE & DEVIOUS MANAGER

Wenn ich hier Manager sage, ist das jeder in der Projektmanagement-Position von der Seite des Softwareentwicklungsunternehmens. Sei es ein Projektmanager, ein Teamleiter, ein Lieferleiter oder ein Firmeninhaber, wenn Sie jemals versucht haben, sich schnell die Hände von einem Projekt zu waschen, nur um es abzuschließen und Ihre Zahlung zu kassieren, sind Sie eine Partei auch an dieser Höhe von Tech Debt in Ihren Projekten schuld.

Das Traurigste hier ist jedoch, dass ihr niemals für die Höhe der Tech-Schulden bezahlen müsst. Entweder zahlt der Kunde dafür, indem er ein minderwertiges Produkt verwendet, oder er zahlt tatsächlich mehr Geld, um es reinigen zu lassen. Und wenn es nicht der Kunde ist, zahlen die armen Programmierer dafür, indem sie endlose Stunden weit über das hinaus arbeiten müssen, was sie tun müssen. Aber es sind fast nie diese mittleren Typen, daher sollten sie meiner Meinung nach die rechenschaftspflichtigsten Einheiten in diesem Tech-Schulden-Thema sein.

Wenn Sie jemals einen von ihnen einstellen, ist die größte Eigenschaft, die sie haben sollten, Moral. Wenn ihr moralischer Kompass in die richtige Richtung zeigt, werden sie Verantwortung übernehmen und die richtige Entscheidung zugunsten des Projekts treffen, was letztendlich zu weniger Tech-Schulden führen würde. Das erinnert mich an das berühmte Zitat von Jack Ma, in dem er davon sprach, sich dafür zu entscheiden, für die richtige Führungskraft zu arbeiten. Sehr passend in diesem Szenario hier.

3. Programmierer

Oh ja, ich würde dieses Thema nicht damit beenden, euch auch die Schuld zu geben! Aber hey, #notallprogrammers oder? Nun ja, aber fast 94 % der Programmierer. Das glaubt zumindest CP Gurani, der CEO von Tech Mahindra, als er vor ein paar Jahren die schockierende Enthüllung machte, dass 94 % der IT-Absolventen für den Job ungeeignet sind. Ich weiß nicht genau, wie er zu dieser Zahl kam, aber da ich ein Produkt der indischen Ingenieurhochschulen bin und das gesamte IT-Engineering-Ökosystem in den letzten 10 Jahren miterlebt habe, kann ich sagen, dass ich der Aussage von Herrn Gurani eher zustimme.

Ich versuche nicht zu diskutieren, ob es 94 %, 90 % oder 80 % sind. Aber um Ihnen eine Analogie zu geben: Fast alle von uns wissen, dass wir Mehl, Wasser und eine Prise Salz brauchen, um den Teig zu machen, und ein Nudelholz, um die Chapatis zu machen. Aber nur sehr wenige von uns können tatsächlich essbare Chapatis herstellen. Es ist ein absolut einfacher Prozess, erfordert aber dennoch ein gewisses Maß an Talent und jede Menge Übung, um sich darin zu behaupten. Genauso verhält es sich mit der Programmierung. Wir alle kennen das Rezept, aber nur wenige haben tatsächlich die Ärmel hochgekrempelt und sich die Hände schmutzig gemacht und es so lange geübt, wie es gedauert hat, dieses Handwerk zu beherrschen.

Selbst wenn ein durchschnittlicher Programmierer mit einem Projekt beauftragt wird, schreibt er daher unwissentlich Code mit darin eingebetteten technischen Schulden, die er erst später erkennt. Und wenn Sie sich fragen, wie gut die Branche insgesamt funktioniert, wenn die meisten Programmierer für den Job ungeeignet sind, dann liegt das an ihren effizienten Managern und ihren erfahrenen Senioren, die die Dinge auf die harte Tour gelernt haben. Sie helfen diesen frischen Händen und Köpfen beim Navigieren auf den tückischen Pfaden des Schreibens von optimalem Code und machen die Lieferung des Projekts machbar und halten es frei von belastenden Schulden. Und schließlich werden diese Neulinge mit der richtigen Pflege und Schulung gut in ihrem Job, oder sie verabschieden sich von der IT-Branche.

Abschließend denke ich, dass alle drei Hauptparteien in dieser Zusammenarbeit die Schuld für die Kompilierung von Codeschulden teilen. Nochmals, nehmen Sie dieses Stück nicht als Abrissstück für alles, was in der Branche falsch läuft. Es ist wie jede andere Branche auf der Welt mit einem fairen Anteil an Schrecken und Helden. Auch nach 10 Jahren würde ich immer noch nichts anderes mit meinem Leben anfangen. Ich liebe diesen Job, ich liebe es, ein kleines Unternehmen zu sein, das an spannenden Projekten von Kunden auf der ganzen Welt arbeitet.

Der Zweck bestand darin, alle drei Beteiligten stärker zur Rechenschaft zu ziehen und sie mit diesem zugrunde liegenden Soft Loss vertraut zu machen, der ihnen durch falsche Zusammenarbeit zugefügt wurde. Wenn ein Softwareentwicklungsteam seine Tech-Schulden genau berechnen und messen möchte, kann es einem strengen Prozessmodell folgen, das auf der Agile-Methodik oder sogar der Wasserfall-Methodik basiert. Wenn Sie diesem disziplinierten Ansatz folgen, können Sie diese Überarbeitungs- und Reparatursprints separat markieren und am Ende einer Phase genau berechnen, wie viele davon Sie benötigen, und leicht zur Sache kommen Grund dafür.

Ich werde dies mit diesem abschließenden Zitat von Samuel Beckett beenden: