Ich bin selbst Softwareingenieur und meiner Erfahrung nach gibt es bei uns Entwicklern erst mal ein grundlegendes Problem zu lösen.
Dazu eine kleine Anekdote
Vor ein paar Monaten kamen kurz hintereinander 3 Emails von der Hotline, die alle auf den selben kritischen Bug zurück zu führen waren. Da es eine recht kleine Firma ist dachte ich mir, ich gehe kurz rüber zu den Kollegen von der Hotline und informiere sie bevor ich mit Bug Reports zu gespamt werde. Als ich ins Büro kam sind blitzartig alle 10 Hotline Mitarbeiter zusammen gezuckt und haben sich hinter ihren Monitoren versteckt. Nach einer gefühlten Ewigkeit hat einer dann ganz vorsichtig gefragt, wie er mir behilflich sein könnte.
Die waren schlicht geschockt/überrascht, weil sie noch nie erlebt haben, dass einer der Entwickler vorbei kommt und sie über irgendetwas informiert. Nach dem Schock folgte de Begeisterung.
Meiner Meinung nach ist es eines der größten Probleme in der Softwareentwicklung, dass die Entwickler unter sich bleiben und schlicht nicht mit Kollegen aus anderen Bereichen reden. Das dürfte wohl generell die größte Hürde dabei sein den Entwicklungsprozess offener zu gestalten.
Dabei ist es für wirklich gute Software essentiell Kollegen, die engen Kontakt zu den Kunden/Anwendern haben, mit in die Planung/den Entwurf mit einzubeziehen, um als Entwickler auch die Arbeits. und Denkweise der Anwender zu verstehen. Was nützen die besten Funktionen, wenn das Programm nicht genutzt wird, weil niemand mit der Bedienung klar kommt.
Hoffen wir mal, dass diese Ansätze zumindest langfristig ein Umdenken bewirken.
Das sehe ich sehr ähnlich: Paketierer und Programmierer, Kunden und die beiden erst genannten und so weiter. Keiner kommuniziert mit irgendwem und wenn, dann eher kontraproduktiv. (Freie) Software wird von Menschen gemacht, von Menschenteams.
Das da die Kommunikation untereinander fundamental für alles auf der Softwareebene ist, kann sich eigentlich sogar ein kleines Kind denken.
das fängt doch schon bei den Entwicklern an. Da weiss doch oft niemand, was der am Nachbartisch eigentlich treibt.
Als Beispiel war einer in einem sehr speziellen Kundenprojekt und hatte einige richtig gute Funktionen umgesetzt, die auch in anderen Projekten (wie auch meinem) nützlich gewesen wären. Nur habe ich das erst per Zufall entdeckt, als ich ihm bei einem anderen Problem geholfen hatte. Aber glaub nicht der Code bzw. Lib wäre allen anderen zur Verfügung gestellt worden. Da hätte er "sein Baby" ja mit anderen teilen müssen.
Ein interner git-server mit vernünftiger Doku würde in manchen Firmen sicher die Codequalität steigern und viel Zeit reduzieren.
git-server meine ich keinen Server, auf dem Projekte Teams vergammeln. Eher ein internes github mit ordentlicher Doku und öffentlicher Info, wenn über neute Versionen einzelner Libs.
Ich bin selbst Softwareingenieur und meiner Erfahrung nach gibt es bei uns Entwicklern erst mal ein grundlegendes Problem zu lösen.
Dazu eine kleine Anekdote
Vor ein paar Monaten kamen kurz hintereinander 3 Emails von der Hotline, die alle auf den selben kritischen Bug zurück zu führen waren. Da es eine recht kleine Firma ist dachte ich mir, ich gehe kurz rüber zu den Kollegen von der Hotline und informiere sie bevor ich mit Bug Reports zu gespamt werde.
Als ich ins Büro kam sind blitzartig alle 10 Hotline Mitarbeiter zusammen gezuckt und haben sich hinter ihren Monitoren versteckt. Nach einer gefühlten Ewigkeit hat einer dann ganz vorsichtig gefragt, wie er mir behilflich sein könnte.
Die waren schlicht geschockt/überrascht, weil sie noch nie erlebt haben, dass einer der Entwickler vorbei kommt und sie über irgendetwas informiert. Nach dem Schock folgte de Begeisterung.
Meiner Meinung nach ist es eines der größten Probleme in der Softwareentwicklung, dass die Entwickler unter sich bleiben und schlicht nicht mit Kollegen aus anderen Bereichen reden. Das dürfte wohl generell die größte Hürde dabei sein den Entwicklungsprozess offener zu gestalten.
Dabei ist es für wirklich gute Software essentiell Kollegen, die engen Kontakt zu den Kunden/Anwendern haben, mit in die Planung/den Entwurf mit einzubeziehen, um als Entwickler auch die Arbeits. und Denkweise der Anwender zu verstehen. Was nützen die besten Funktionen, wenn das Programm nicht genutzt wird, weil niemand mit der Bedienung klar kommt.
Hoffen wir mal, dass diese Ansätze zumindest langfristig ein Umdenken bewirken.
Das sehe ich sehr ähnlich: Paketierer und Programmierer, Kunden und die beiden erst genannten und so weiter. Keiner kommuniziert mit irgendwem und wenn, dann eher kontraproduktiv. (Freie) Software wird von Menschen gemacht, von Menschenteams.
Das da die Kommunikation untereinander fundamental für alles auf der Softwareebene ist, kann sich eigentlich sogar ein kleines Kind denken.
das fängt doch schon bei den Entwicklern an. Da weiss doch oft niemand, was der am Nachbartisch eigentlich treibt.
Als Beispiel war einer in einem sehr speziellen Kundenprojekt und hatte einige richtig gute Funktionen umgesetzt, die auch in anderen Projekten (wie auch meinem) nützlich gewesen wären. Nur habe ich das erst per Zufall entdeckt, als ich ihm bei einem anderen Problem geholfen hatte. Aber glaub nicht der Code bzw. Lib wäre allen anderen zur Verfügung gestellt worden. Da hätte er "sein Baby" ja mit anderen teilen müssen.
Ein interner git-server mit vernünftiger Doku würde in manchen Firmen sicher die Codequalität steigern und viel Zeit reduzieren.
git-server meine ich keinen Server, auf dem Projekte Teams vergammeln. Eher ein internes github mit ordentlicher Doku und öffentlicher Info, wenn über neute Versionen einzelner Libs.