URL dieser Newsmeldung:

07.04.2008

Outsourcing und die Folgen: Hätte man mal ...


Das Outsourcing auch mal nach Hinten losgehen kann – insbesondere wenn man Folgekosten ignoriert und es möglichst billig sein soll – porträtiert Michael Kimsal aktuell in seinem Blog. Für einen Kunden hatte Michael ein QuickFix-Projekt angenommen – schnell ein paar Probleme ausmerzen und gut.

Wie sich aber herausgestellt hatte, hatte sein Kunde das Projekt zuvor von einem möglichst günstigen Outsourcing-Partner erstellen lassen; die Quittung dafür:

[...] the alternative he got was far worse, in that he’s out 3 months of product sales and marketing opportunities, still isn’t launched, and has a hell of a bad codebase.

Einen Auszug aus dem Code hat Michael ebenfalls veröffentlicht, wir drucken ihn einmal nicht ab.

Dabei beschreibt er auch das generelle Problem im Umgang mit Outsourcing. Denn häufig seien sich die Leute nicht bewusst, welchen Einfluss das auf die Qualität des Code hat. Treffender ausgedrückt:

To most people code is code, and I still struggle with how to explain differences to non-tech people some times.

Auf den ersten Blick sehe Code nun einmal wie Code aus und wie könne man z.B. einem IT-Entscheider, der nicht so sehr tief in der Technik drin steckt, klarmachen, dass dieser Code schlechter sei, als jener Code?

Hätte man mal ...

In der auf Michaels Horror-Story folgenden Diskussion ("westliche" Programmierer und "betroffene" aus IT-Billiglohnländern) treten dann auch noch ganz andere Aspekte zu Tage. Kann man in einem globalen Markt überhaupt noch von einer Gleichung Qualität == hoher Preis sprechen? Hier das Beispiel eines Rumänen, der aufgrund seiner wesentlich niedrigeren Lebenshaltungskosten eben günstiger produzieren kann. Für andere spiele hier auch eher das "klassische PHP-Problem" eine Rolle – die geringere Einstiegshürde in PHP an sich (im Vergleich zu Java beispielsweise) fördere zwangsweise auch ein breiteres Qualitätsspektrum.

Ist PHP zu simpel, um gute Qualität zu fördern? Kommen wir an einen Punkt, an dem wir wählen müssen zwischen Java-like Enterprise PHP und einer Billigvariante? Vielleicht ist das auch gerade der kritische Punkt – PHP entwächst seinen Kinderschuhen und muss sich damit den Problemen der "großen" stellen. Vielleicht kann man denen ja noch das ein oder andere abgucken?

[rl]
 http://michaelkimsal.com/blog/ (http://michaelkimsal.com/blog/)



© 2008 Software & Support Verlag GmbH. Vervielfältigung nur mit Genehmigung des Verlags. Fragen?