Schon wieder diese Auto-Vergleiche 
Zugegeben: Die sind „gut“, weil sich viele Konzepte von „Softwareentwicklung“ und „Automobilbau“ aufeinander übertragen lassen. Man muss sich ja nur mal den ersten Abschnitt von Kanban: Historische Entwicklung durchlesen. Aber die Vergleiche können auch beliebig schlecht werden, je nachdem, wie „unsachlich“ oder „polemisch“ man einen Punkt rüberbringen will.
Ich weiß, dass meine Ansichten an vielen Stellen „idealistisch“ oder eben „unrealistisch“ sind. Es scheint (heutzutage) nicht mehr üblich zu sein, ein Stück Software als „Asset“ anzusehen - als etwas, was einen Wert hat, weil es die Manifestation vieler Stunden geistiger Arbeit ist und einen echten Nutzen und (Markt!?-) Vorteil bringt.
(Ein möglicher Auto-Vergleich: Dass sich jemand einen 190er Mercedes kauft und den 20 Jahre lang fährt, um nach 800000km einen Austauschmotor auf Kulanz zu bekommen, passiert nicht mehr. Stattdessen setzen alle auf „Transportation As A Service“ und fahren Taxi. Gut, das ist zwar langfristig gesehen teuer, aber wer will denn in so einer schnelllebigen Zeit noch eine langfristige Investition vertreten? Mit Taxis hat man immer ein neues Auto, nie so eine 20 Jahre alte Kiste. Und Taxis skalieren auch besser. Wenn man mal eine Fußballmannschaft transportieren will, ruft man einfach drei Taxis. Da ist man viel flexibler und kann besser auf neue Gegebenheiten reagieren…)
Die Begriffe sind jetzt natürlich sehr vage und können bei Bedarf ausdifferenziert werden, aber: Es gibt ja keine sinnvolle Möglichkeit, die „Kompetenz“ oder gar „Produktivität“ eines „IT-Verantwortlichen“ zu quantifizieren. Platt: Wenn jemand „viel Code schreibt“, ist das nicht gut (sondern oft eher schlecht). Viel, was in der IT gemacht wird, hat einen negativen net benefit.
Mein Eindruck ist, dass an vielen Stellen die „Kompetenz eines IT-Verantwortlichen“ gar niemanden interessiert. Diese Kompetenz kann ohnehin nicht „gemessen“ werden, und darum geht es nicht um echte (fachliche) Kompetenz, und auch nicht darum, „gute“, „richtige“ oder „sinnvolle“ technische Entscheidungen zu treffen oder Lösungen zu entwickeln, sondern den Eindruck von Kompetenz zu vermitteln. Ein Zitat von diesem ach-so-erfolgreichen Freiberufler aus dem oben verlinkten Artikel:
„Ich kann IT gut erklären, wirke daher kompetent.“
Schön. Wollen wir jetzt kurz über den Unterschied reden zwischen „kompetent wirken“ und „kompetent sein“?
Kompetent zu wirken kann recht einfach sein, wenn man mit Leuten zu tun hat, die keine Ahnung von IT haben. Und da gibt es nunmal viele. (So weit kein Widerspruch, oder? ). Und das hat eben zur Folge, dass schlechte Lösungen entwickelt werden. D.h. die Realität® wird IMHO durch xkcd: Software Development und xkcd: Containers recht gut beschrieben: Es gibt ein kleines technisches Problem (Problem - nicht „Herausforderung“!) das zu lösen ist. Und dann kommt jemand, der souverän und selbstsicher vorschlägt, die größten und dicksten und mächtigsten Frameworks, die es am Markt gibt, in Docker-Container zu packen und miteinander zu verdrahten. Und da wird dann viel Zeit und Geld verbrannt investiert. Und am Ende steht nicht mehr die nützliche und nutzbare (!) Lösung des Problems im Vordergrund. Stattdessen sinkt die Latte, die übersprungen werden muss, um von einem „Erfolg“ zu reden, auf das Level, aus dem (meiner Beobachtung nach) einige Leute eine … merkwürdige Art von „geekigem Stolz“ zu ziehen scheinen ( 
) - nämlich, dass jemand sagen kann: „Ich hab’s zum Laufen gebracht!!!111“. *langsam-sarkastisches Klatschen* : Toll gemacht. Hier ist dein Scheck. Und wer räumt den Scheiß jetzt auf?
Da setz’ ich mich eher mit einem Kaffeebecher und einem Pappschild an den Bahnhof…