Vorgehensweisen diskutieren / hinterfragen

Hier sind nur einige Gedanken zusammengetragen, für eine Diskussion. Aus meiner langen Erfahrung hinterfrage ich gerne aktuelle Vorgehensweisen. Diese sind durchaus provokant.

Und Alter muss nicht unbedingt Weisheit bedeuten, aber es schließt diese auch nicht aus.

Und alle Punkte sind einfach nur Ideen zum Diskutieren.

Gang of Four

• Sind diese wirklich wie Götzen zu behandeln und sind ihre Thesen ein Allheilmittel. Wie oft wird mit Methoden gearbeitet, die für das Projekt völlig unnötig sind.

Scrum

• Ist dies wirklich Mehrwert oder nur von Firmen, welche Scrum Master ausbilden künstlich erschaffener Aufwand.
• Planning Poker - kann das eigentlich funktionieren
• Sprints – Wie oft werden dies überhaupt eingehalten und wie groß ist der Aufwand im Verhältnis zum Nutzen.
• Was kann man sonst noch auf den Prüfstand stellen.

Unit Tests

• Wie sinnvoll werden diese eingesetzt.
• Werden sie nur dazu benutzt, eine Methode zu verifizieren, anstatt zu brechen
• Werden sie nur für Testabdeckungen angelegt
• Werden sie so gefaked, dass sie eigentlich gar keinen Nutzen haben
• Werden zu oft System Tests vernachlässigt (gerade, wenn man mit MS Office Objekten arbeitet)

Aufwände in Strukturen

• Wird zu oft mit Kanonen auf Spatzen geschossen
• Es gibt immer wieder die Aussage, dass man einen Code möglichst zukunftssicher machen sollte. Mit allen möglichen Mitteln wie Services etc…. Aber wie lange wird der Code, denn überhaupt so von Nutzen sein.
• Frameworks werden für Frameworks benötigt die wiederum Framewoks zur Unterstützung möchten. Und für was?
• Wird zu viel theoretischer Unsinn betrieben, anstatt praktischer Umsetzung,

Allgemein Einschätzung von der Langlebigkeit

• Software-Schulden – eines der Worte, mit welchem alles mögliche begründet wird, aber nie wirklich sinnvoll. Sieh man die Entwicklung in der Programmierung, muss man sich fragen ob überhaupt Software-Schulden aufgebaut werden können.
• Wie schnell wird die Entwicklung, z.B. in der KI, aktuelle Programmierung überholen.
• Wird nicht sowieso innerhalb einer überschaubaren Zeit Refactoring notwendig, da sich neue technische Möglichkeiten ergeben.

Projektdenken

• Ein wichtiger Weg für das Ziel
• Werden die Programmierer „dumm“ gehalten, was die Zusammenhänge angeht, oft mit unsinnigsten Begründungen.
• Ist im Team das Projekt verinnerlicht und verstanden.
• Können sich die Teammitglieder mit dem Projekt identifizieren.

Programmierer und deren Fähigkeiten

• Immer wieder wird von unerfahrenen Programmierern gesprochen, welchen man keinen zu tiefen Einblick geben kann, bzw. die auf Schienen gelenkt werden müssen. Das Resultat ist, dass unerfahrene Programmierer unerfahrene Programmierer bleiben und sich auf die Dauer auch gedanklich verabschieden.
• Werden sie gefordert und gefördert
• Aber wird ihnen auch mal der Zahn gezogen, dass sie von der Schule kommend, die Größten und Besten sind.

Meetings – welcher Nutzen

• Was wird in den Meetings besprochen, wird über Unsinniges diskutiert
• Zu oft, zu lange
• In zu großen Gruppen

Provokant

• Stimmt es, dass wo früher 1 Programmierer 1 Woche gebraucht hat, nun 5 Programmierer 5 Wochen brauchen.

Wie wäre es mit einem Workshop zu diesen Themen?