Man sollte auch hinzufügen, dass z.B. die Abstraktionen, die zur Erweiterung des Quellcodes dienlich sind und dadurch auch gewisse Normen festlegen auch die Komplexität erhöhen. Erhöhte Komplexität bedeutet jedoch auf der anderen Seite steigende Kosten.
Schön finde ich die Passage von DudeMania der dabei darauf eingeht, dass auch der Verwendungszweck eine wichtige Rolle spielt. Will man ein universelles Produkt das zukünftig keine (geringe) Erweiterungen erhalten soll, so ist es unnötig bei einem kleinen Umfang viel Wert auf eine schöne Abstraktion bzw. Factoring Wert zu legen. Andererseits könnte man mit voller Absicht darauf abzielen, dass dieser Code möglichst von niemanden sonst erweitert werden soll. In beiden Fällen wird der Preis des Produkts dann billiger ausfallen können.
Programme die zukünftig leicht erweiterbar sein sollen stützen sich auch meist auf Patterns, sodass eben auch 3ten das weitere implementieren leichter fallen kann (nicht zwangsläufig muss). Bei so einem Produkt kann dann auch gerne einmal ein höherer Preis verlangt werden (sollte es verkauft werden. Dem Endanwender selbst geht es, wie schon oft gesagt nur darum das es funktioniert und nicht wie. Und ein Kunde der ein billiges Produkt kauft, kann erwarten, dass auch die Erweiterbarkeit begrenzt sein (kann).
Übrigens weil y0l0sw4gg3r es erwähnt: Man darf sich bitte nicht immer nur auf IT beziehen, denn auch EDV fällt darunter. Ein Programmierer ist nicht zwangsläufig ein ITler, sondern in erster Linie ein EDVler.
Irgendwo wurde auch das Thema Erfahrung angesprochen: Es kann sein, dass ein frisch gebackener Student / bzw. jemand der sich das Programmieren selbst beigebracht hat effizienter ist, als jemand der es bereits seit Jahren macht. Gerade Leute die aus der IT kommen wissen, dass man sich in diesem Bereich regelmäßig fortbilden muss um "up to date" zu sein. Alles andere ist zwangsläufig fahrlässig. Auch gibt es Programmierer denen die Abstraktionen vom Verständnis her zu komplex sind und von der teilweise mangelnden Dokumentation möchte man gar nicht reden. Inkompetent muss deswegen keiner von ihnen sein, denn alle könnten ein Top-Produkt liefern, ob es nun ein Legacy-System ist oder nicht sei dahingestellt. Auch merkt man oft, dass die Leute bestimmte Definitionen nicht wissen, trotz allem aber sehr gut mit der Materie umgehen können. Daher kann man ihnen auch nicht die Inkompetenz im Bereich des Programmierens unterstellen.
Die Frage ist immer : Was will man -> wenn man es schafft (kompetent)
Die andere Frage ist: Wie wurde es umgesetzt und warum -> hier zeigt sich dann in diesem Zusammenhang die Kompetenz. Ich kann ein verdammt guter Programmierer sein und ein Produkt zur Verfügung stellen, dass die Anforderungen erfüllt, aber extrem "hässlich" programmiert wurde, weil das Ziel genau diese Vorgehensweise voraussetzt. Ist man in diesem Fall inkompetent? Ich beantworte diese Frage mit einem klaren "Nein".
Wenn jemand 20 Jahre programmiert, sich aber nicht up to date hält und sich weigert auch nur einen Hauch von Neuem zu lernen, um seine Kompetenz in weiteren Gebieten zu steigern, ist er dann inkompetent? Nein, was das Programmieren angeht, aber Ja, was die Variation von verschiedenen Programmierstilen betrifft.
Übrigens ist es auch eine Kompetenz mit jeglicher Art von Code umgehen zu können, egal nach welchem Schema es programmiert wurde und es dann seinen Vorstellungen/Aufträgen entsprechend zu erweitern. Sollte also nicht eine relevante Grundfrage sein: Ist man inkompetent, wenn man einen Programmierstil nicht erweitern kann? Auch hier wäre meine Meinung: Ja, man ist inkompetent genau bei diesem Stil oder bei diesem Projekt, da man es hier nicht schafft (sofern es überhaupt erweiterbar ist).
Zitieren
