Nehmen wir mal an, man übernimmt (kauft) eine Firma, die ein erfolgreiches branchenspezifisches Softwareprodukt (Druckerei und Verlagswesen) am Markt hat, mit reichlich Bestandskunden und auch einigen Neu-Interessenten in der Warteschlange. Bei dem Produkt handelt es sich um eine Art Zwilling aus ERP- und Warenwirtschafts-System, also nichts, was mit der Übergabe eines Lizenzschlüssels erledigt ist, sondern umfangreiche Vor- und Nachbetreuung inkl. Customizing und Schulung beinhaltet. Nach der Übername stellt sich allerdings heraus, dass es sich um einen ziemlichen Sausstall handelt. Der bisherige Chef "bereitete" sich seit längerem af seinen Ruhestand vor und hat die Zügel erheblich schleifen lassen: - der vorhandene Sourcecode ist überwiegend auf den Arbeitsplatz-PCs der Mitarbeiter verteilt, keine zentrale Ablage, Versionierung, "GIT" o.ä. - keine interne Dokumentation, ausser hin und wieder ein paar Bemerkungen im Code - zu einigen Modulen sind die Entwickler nicht mehr verfügbar - Anwenderhandbücher sind auf dem Stand von vor 3..5 Jahren Das hat z.B. zur Folge - dass kaum noch Fehlerbehebung gemacht werden kann - dass eigentlich schon ausgelieferte Module neu programmiert werden mussten, weil mit dem Entwickler auch dessen "geheimes Wissen" verschwand - usw. ... den Rest der Nebenwirkungen kann man sich wohl selber ausmalen Frage nun: - wie bekommt man so einen Laden wieder "In die Spur"? Was man in Zukunft anders machen muss, das ist klar, aber wie kommt man dahin? - gibt es Werkzeuge/Tools und Strategien, um quasi fremden Soucecode zu re-erschließen? - ich wäre dankbar für ein paar Stichworte, um in die richtige Richtung zu recherchieren
> - der vorhandene Sourcecode ist überwiegend auf den > Arbeitsplatz-PCs der Mitarbeiter verteilt, keine > zentrale Ablage, Versionierung, "GIT" o.ä. Das sollte ja kein Problem sein, das einmal ordentlich zusammenzufassen, dann kann man es auch auf ein GIT umstellen oder was auch immer. > - keine interne Dokumentation, ausser hin und > wieder ein paar Bemerkungen im Code Zielorientierte Programmierung, wenn Du Dokumentation willst, kostet das Zeit, ich weiß auch nicht ob das bei älterem Code Sinn macht. Da müsste man den Programmierern für zukünftige Entwicklungen die Vorgabe machen, ihre Arbeit besser zu dokumentieren. Nachteil ist eine längere Entwicklungszeit. > - zu einigen Modulen sind die Entwickler nicht mehr verfügbar Auf deprecated setzen, neu schreiben. Geht schneller als fehlerlos nachzuverfolgen was die Dinger genau machen und was nicht. > - Anwenderhandbücher sind auf dem Stand von vor 3..5 Jahren Warum? Wurden neuere Module gar nicht integriert? Dann kannst Du die wegschmeißen und einmal neu schreiben, auf Basis des aktuellen Softwarestandes. Aber wie wichtig sind die Bücher bei customized Software? Da kann man sowieso fast jedem sein eigenes Handbuch schreiben, was die Anpassungen enthält. > - gibt es Werkzeuge/Tools und Strategien, um quasi > fremden Soucecode zu re-erschließen? Nur Dein Gehirn und eine verdammte Menge Arbeitszeit.
Ben B. schrieb: >> - gibt es Werkzeuge/Tools und Strategien, um quasi >> fremden Soucecode zu re-erschließen? > Nur Dein Gehirn und eine verdammte Menge Arbeitszeit. Erstmal danke für deine Antwort. Ich kenne aus eigener Praxis den permanenten Widerspruch hinsichtlich der empfohlenen Dokumentation von Sourcecode in Theorie und Praxis. Quasi "zähneknischend" muss ich aber eingestehen, dass es bei Entwickler-Fluktuation kaum etwas Wichtigeres gibt. Mal eben ein "schneller Hack" führt, sofern erfolgreich, temporär zu Hochgefühlen und Anerkennung beim Kunden, macht aber später nichts als Ärger. Man wird die (normgerechte) Doku-Pflicht wohl bei Projekten dieser Größenordnung mit eiserner Peische durchstzen müssen, bei Strafe des eigenen Unterganges ...
Wenn das in einer Sprache geschrieben ist, die doxygen versteht, einfach mal so drüber laufen lassen. Auch ohne Doku-Kommentare werden damit Klassenabhängigkeiten, etc. schon etwas klarer und man hat klickbare Referenzen auf alles inkl. Code.
Wichtig ist der Einsatz eines Versionsverwaltungssystems (z.B. Subversion SVN). Hier kann der unveränderte Quellcode als Urversion eingeplegt werden. Jede Programmänderungen und Kommentarergänzungen werden als Versionsänderungen gespeichert. So ist jederzeit nachvollziehbar was ab dem "Aufräumen" geändert wurde. Verschlimmbesserungen können leicht zurückgenommen werden. Jede Änderung kann dokumentiert werden. Die Datenbank des Versionsverwaltungssystems liegt auf einem Zentralen Sever mit entsprechender Datensicherung
Wichtig ist erst einmal eine Prioritätsliste der Produkte (nach wirtschaftlicher Wichtigkeit) aufzustellen, damit man mit dem Wichtigsten beginnen kann. Da alle verfügbaren Unterlagen sammeln, sichten und zuordnen. Meist entdeckt man dann auch, wo auf welche Vorarbeiten zurückgegriffen wurde. Diese dann in die Priorität mit aufnehmen. Dann beginnt die "Knochenarbeit", die Unterlagen strukturiert abzulegen, eventuell vorhandene Lücken zu schließen. Mit dem ersten Projekt erstellt man sinnvoll auch das Ablageschema (Pflichtenheft, Hardware, Mechanik??, Software, Dokumentation für Kunden, Serviceunterlagen), welches dann verbindlich für alle neuen Projekte gilt und nach dem dann auch die anderen Altlasten aufbereitet werden. Hat man das weitgehend selbt oder oder von (möglichst nur einem) Mitarbeiter unter strenger Aufsicht und Kontrolle erfolgreich erledigt, werden die anderen Mitarbeiter darin geschult. Von da an hat keiner eine Ausrede mehr, schlampig zu arbeiten. Dann muss man noch ein Projekt- und Qualitätsmanagementsystem einrichten. (Klingt schlimmer als es ist.) Dazu gehört, wie man an "Meilensteinen" im Projekt prüft, ob die jeweilige (Teil-)Aufgabe vollständig und sicher erfüllt wurde, ob geplante Terminstrecken eingehalten werden konnten (falls nicht: Woran lag es? Waren die Terminstrecken unrealistisch? Was lernt man daraus für die nächsten Projekte?) und ob der Kostenrahmen eingehalten wurde.
Ich verstehe nicht, wie in Zeiten von Hochsprachen neben dem Quelltext eine Dokumentation existieren soll. Natürlich gibt es Infos, die nebenher existieren, z.b. 100 Regalmeter Steuergesetze oder firmenprozesse, wenn das Kern der SW ist. Aber wenn der Code vernünftig gepflegt/refakturiert ist, braucht es kaum Doku. Wenn nicht, ist sie wertlos (oder die Sprache ungeeignet). Bei uns gilt: wer eine (interne) Doku braucht, schreibt sie sich bzw. updated die veraltete. Eine ausreichende Doku für andere zu schreiben, macht nur Sinn, wenn ein Dutzend Leute die auch lesen.
A. S. schrieb: > Ich verstehe nicht, wie in Zeiten von Hochsprachen neben dem Quelltext > eine Dokumentation existieren soll. Ist auch nicht praktikabel, da beide Dokumente (Quellcode, Beschreibung) mit der Zeit auseinander laufen können. begleitende Funktionserklärung als Kommentar im Quellcode, Beschreibung des Änderungsgrundes im Versionsverwaltungswerkzeug
Welche Sprache betrachtest du als für dokumentationslose Programmierung geeignet? Dabei berücksichtigend, dass diese Branchensoftware im Kern vielleicht schon Jahrzehnte alt ist.
Frank E. schrieb: > - wie bekommt man so einen Laden wieder "In die Spur"? Was man in > Zukunft anders machen muss, das ist klar, aber wie kommt man dahin? Ich würde mir auf jeden Fall Hilfe von außen suchen. Ich würde für eine begrenzte Zeit einen Freelancer einstellen, der Erfahrung darin hat, wie man heutzutage Software entwickelt. Der muss natürlich sehr gut sein und da würde ich auch nicht am falschen Ende sparen, wenn das teuer wird. Die notwendige Veränderung nur mit dem bisherigen Personal zu schaffen, halte ich für sehr mühsam. Da werden einem wahrscheinlich auch viele Steine in den Weg gelegt mit Denkweisen wie "das haben wir schon immer so gemacht".
Frank E. schrieb: > - ich wäre dankbar für ein paar Stichworte, um in die richtige Richtung > zu recherchieren Mal ganz ehrlich: was ist dein Job in dem ganzen Zirkus? Oliver
A. K. schrieb: > Welche Sprache betrachtest du als für dokumentationslose Programmierung > geeignet? Jede ab C. Wobei aber nicht jede für jede Problemart genügend ausdrucksstark ist. Es ist Aufgabe der Entwickler, die Umgebung zu schaffen, in der fortan in der Problemsprache gesprochen werden kann. Beispielsweise sind Übersetzungen (nicht Abkürzungen) von Begriffen ganz übel und zu vermeiden.
Frank E. schrieb: > - wie bekommt man so einen Laden wieder "In die Spur"? Evolution statt Revolution. Die vorhandenen Sw-entwickler kennen das Produkt, ein neuer kennt git oder svn. Bei allem darüber (scrum, Doku, Vorgehensmodell, codierrichlinien, ...) Kann man auch schnell übers Ziel hinaus schießen. Da brauchst Du schon ein paar Monate um nur zu erkennen, wer wichtig ist und wer so tut. Frank E. schrieb: > gibt es Werkzeuge/Tools und Strategien, um quasi fremden Soucecode zu > re-erschließen? Die gleichen, wie ein fremdes Buch oder einen fremden Schaltplan zu re-erschließen: jemanden daran setzen, der dir Sprache und die Aufgabe kennt. Es wird nur niemanden geben, der dir das so aufbereitet, dass es weder des einem noch des anderen Bedarf.
Es muß doch jemanden geben, der das Teil bei Änderungen kompiliert, der als einigermaßen den Überblick hat. Den lasse man die neueste Version erstellen, dann stehen die beteiligten Dateien fest, auf denen man aufbauen kann. Oder hat sich der neue Chef mit seinen Kollegen / Mitarbeitern überworfen? mfg
~Mercedes~ . schrieb: > Es muß doch jemanden geben, der das Teil > bei Änderungen kompiliert, der als einigermaßen den > Überblick hat. Wenn er Pech hat, dann ist das nicht eine einzelne monolithische Anwendung, sondern ein Konglomerat aus etlichen Komponenten, für das verschiedene Entwickler zuständig waren.
Er will dann doch nicht alle Komponenten auf einmal ändern, nicht wahr? Und wenn man ne Firma kauft, kauft man diese im Sack oder überprüft (läßt überprüfen) man doch, was man vorher kaufen will wenigstens grob... mfg
Frank E. schrieb: > - der vorhandene Sourcecode ist überwiegend auf den Arbeitsplatz-PCs der > Mitarbeiter verteilt, keine zentrale Ablage, Versionierung, "GIT" o.ä. Da der Sourcecode das Kapital der Firma ist unbedingt den jetzigen Stand sichern. Wenn es sein muss mit einer heimlichen nächtlichen Aktion oder Wochenendaktion bei der eine Fremdfirma die Platte jedes Entwickler-PCs dupliziert. Für den Rest müsste man unbedingt mehr über die Firma wissen, besonders die Entwickler. Wenn das ein Haufen "Helden" sind, dann wird es eventuell nicht ohne schmerzliche und teure Kündigungen und Neueinstellungen gehen. Mit notorischen Einzelkämpfern ist kein Staat zu machen. Es nützt zum Beispiel nichts ein Versionskontrollsystem einzuführen wenn die Helden es nicht benutzen. Ich habe selber schon Teams auf- und abräumen müssen, bei dem Programmierer über Jahre hinweg keine Commits im Versionskontrollsystem machten und nicht einsahen dass das absolut hirnrissiger Blödsinn ist. Das Gleiche gilt dann für das Buildsystem. Kein Buildsystem? Dann muss eins her. Die Programmierer basteln weiter die Software unkontrolliert von Hand zusammen oder lieben es sich in einer IDE einen Wolf zu klicken? Wer nicht hören will muss fühlen. > - keine interne Dokumentation, ausser hin und wieder ein paar > Bemerkungen im Code > - zu einigen Modulen sind die Entwickler nicht mehr verfügbar > - Anwenderhandbücher sind auf dem Stand von vor 3..5 Jahren Also Runde 3: Dokumentation. Benutzerdokumentation und interne Dokumentation. Wenn es um die externe Benutzerdokumentation geht kann man sich überlegen ob man die Programmierer nicht entlastet und einen Technische Redakteur einstellt. Für die interne Dokumentation muss man Standards setzen die bei neuen Modulen ab sofort zu erfüllen sind. Bei alten Modulen werden sie schrittweise, und wenn es sein muss mittels Reverse Engineering erstellt. > - dass kaum noch Fehlerbehebung gemacht werden kann > - dass eigentlich schon ausgelieferte Module neu programmiert werden > mussten, weil mit dem Entwickler auch dessen "geheimes Wissen" > verschwand Vierter Punkt: Tests. Es gibt so neun oder zehn Arten von Software-Tests. Daraus sucht man sich zuerst die am dringendsten benötigten raus. Bei Altsoftware würde ich als Erstes über Unit-Tests und Regression-Tests nachdenken. Für neue Module sind ab sofort Unit-Tests zu schreiben. Bei Bugfixes wird für jeden Bug ein Regression-Test hinzu gefügt und soweit es sich anbietet Unit-Tests nachträglich für das Modul entwickelt. Programmierer die das nicht einsehen, die Anordnung unterwandern oder umgehen usw. dürfen die Firma verlassen. > - usw. ... den Rest der Nebenwirkungen kann man sich wohl selber > ausmalen Ja, ist ein Sauhaufen. Ich habe eine Zeit lang mein Geld mit dem Retten praktisch gescheiterter Softwareprojekte verdient. Ein Fehler der immer und immer wieder gemacht wurde ist zu lange an Programmierern fest zu halten, die nicht mitzogen. Das gilt auch für Helden von denen man glaubt sie seien unersetzlich weil nur sie die Software kennen. > Frage nun: > > - wie bekommt man so einen Laden wieder "In die Spur"? Was man in > Zukunft anders machen muss, das ist klar, aber wie kommt man dahin? Am besten Schrittweise. Wenn das ganze aber komplett hoffnungslos ist und die Programmierer sich als die Herren im Haus aufführen "uns kann keiner", dann gibt es noch drei Methoden die sehr viel Mut erfordert. Erstens, man baut heimlich eine neue Entwicklung auf (anderer Standort, neue GmbH). Die bekommt zum Start den kopierten Sourcecode, darf den konsolidieren und wenn sie so weit ist wird die alte Entwiklung runter gefahren. Zweitens, man verkauft den Sauhaufen so schnell wie möglich weiter, notfalls mit Verlust. Drittens, man macht ihn einfach zu und trägt den Verlust wie ein Mann. > - gibt es Werkzeuge/Tools und Strategien, um quasi fremden Soucecode zu > re-erschließen? Es gibt Werkzeuge, aber vieles ist einfach Spielzeug. Sieht ganz toll und bunt aus, funktioniert wunderbar auf Powerpoint und mit 1000 Zeilen Code aber bricht bei 500000 hoffnungslos zusammen. Aber noch mal, Tools nützen nichts wenn die vorhandene Mannschaft sie nicht benutzt, die Benutzung hintertreibt, umgeht oder simuliert.
Oliver S. schrieb: > Mal ganz ehrlich: was ist dein Job in dem ganzen Zirkus? Naja Du weisst ja, bestimmt hat ihn der Bruder vom Bruder eines Bekannten gefragt. Ab und an könnte man meinen, der Frank trollt hier, fängt ein Thema an, antwortet noch ein oder zwei mal und dann hört man nix mehr. Rückmeldungen was aus einzelnen "Anfragen" geworden ist gibt es auch nie. Aber ganz ehrlich, wenn ich mir als Geschäftsmann, Ing., Techniker oder was auch immer selbst keinen Reim auf die eigenen Fragestellungen geben kann, dann sollte ich mir überlegen die Finger davon zu lassen.
Der ganzen Crew den Auftrag geben, sie sollen eine neue Version von Grund weg designen mit vielen Sitzungen und Vortraegen innerhalb der Gruppe. Erst mal nur das Design. Der ganze Prozess wir protokolliert. Dabei den besten Mitarbeiter evaluieren. Der soll das jetzige Produkt beim Kunden laufen lassen, und schulen. Wichtig ist nicht am Kunden vorbei irgend welche Sandburgen zu bauen. Dann kommt der wieder zurueck und laesst das gewonnene Wissen einfliessen. Dann werden die neuen Tools vorgestellt. Github. Ein Wiki. Ein Blog. Ein Bugtracking System. Mittlerweile hat sich herauskristallisiert, wer smart, motiviert und leistungsfaehig ist. Also .. weg mit den Pfeifen. Und weiter geht's
:
Bearbeitet durch User
Sven L. schrieb: > Aber ganz ehrlich, wenn ich mir als Geschäftsmann, Ing., Techniker oder > was auch immer selbst keinen Reim auf die eigenen Fragestellungen geben > kann, dann sollte ich mir überlegen die Finger davon zu lassen. So isses. Er könnte sich auch fragen, wie man ein Hotel auf dem Mond baut. Hat letzendlich genausowenig praktische Relevanz wie die aktuelle Fragestellung. Aber wenn er wirklich jemanden kennt, der das Problem hat, kann er den ja auf den Thread hier aufmekrsam machen. Es haben sich ja ausreichend viele (angebliche) Fachleute angeboten ;) Oliver
:
Bearbeitet durch User
Hannes J. schrieb: > keine Commits im Versionskontrollsystem machten und nicht einsahen dass > das absolut hirnrissiger Blödsinn ist Das Problem hatte ich auch, die Entwickler fühlten sich überwacht. Eine Differnenzanalyse zeigt den Umfang des neuen beziehungweise geänderten Code an. Das Arbeiten im Team wurde sehr erschwert, da der Code "auseinanderlief". Das führte dazu, dass Uneinsichtige gekündigt werden müsten.
:
Bearbeitet durch User
Gerald K. schrieb: > Das Problem hatte ich auch, die Entwickler fühlten sich überwacht. Eine > Differnenzanalyse zeigt den Umfang des neuen beziehungweise geänderten > Code an. Das ist ein Nebenprodukt. Aber hey, da müssen die hohen Herren mal von ihrem noch höheren Roß runter kommen. Jeder kleine Arbeiter wird jeden Tag an seinem Produktionsvolumen gemessen! Wenn gleich natürlich das sinnvolle Maß eines Softwerkers nicht die Menge an Source Code/Tag ist, sondern was an Funktionalität und Qualität rauskommt. Gute Leute haben mit dieser "Überwachung" kein Problem, nur die schlechten, die sich sowieso nur durchmogeln und Beschäftigung und Stress vortäuschen.
Falk B. schrieb: > Gute Leute haben mit dieser "Überwachung" kein Problem, nur die > schlechten, die sich sowieso nur durchmogeln und Beschäftigung und > Stress vortäuschen. Genauso ist es. Bluffer werden sehr rasch entdeckt. Es wurde mehr Kommentar geschrieben (positiv), aber auch viel reduntanter und unnützer Code (negativ), THEN Pfad mit ELSE Pfad vertauscht, denn das brachte viele Änderungen im Code.
:
Bearbeitet durch User
Meine Meinung zum Thema: 1. Alles zunächst so weiter laufen lassen wie es ist, sofern die Firma noch Geld verdient. Ich habe beobachtet, dass zuviel Initiative schwer angenommen wird vom Bestandspersonal. Wenn Du am Ende alleine da stehst, hast Du nix gewonnen. 2. Einarbeiten in die Materie und die internen Abläufe 3. Bisher wurden ein paar gute Techniken genannt. Nach und nach Änderungen einbringen. Wenn sich(oder du) das Team zersetzt, hast Du erst recht verloren. Die Zeit geht nicht, sie kommt. Änderungen sind immer sehr träge. Ich gehe davon aus, dass Du mit der Firma Geld verdienen willst. my2cents
Frank E. schrieb: > Mal eben ein > "schneller Hack" führt, sofern erfolgreich, temporär zu Hochgefühlen und > Anerkennung beim Kunden, macht aber später nichts als Ärger. You get what you pay for. Wenn das Entwickler-Team ständig unter maximalem Termindruck gesetzt wird, wenn der "erfolgreiche" Projektabschluss beim Kunden einen höheren Stellenwert genießt als Investitionen und Qualität, dann passiert genau das. Der Fisch stinkt immer vom Kopf her. Es ist immer die Unternehmungsführung ursächlich für schlechten Code. Ich habe es noch nie anders in der Praxis vorgefunden. > Man wird die (normgerechte) Doku-Pflicht wohl bei Projekten dieser > Größenordnung mit eiserner Peische durchstzen müssen, bei Strafe des > eigenen Unterganges ... Das wird super funktionieren, bei Angestellten die nicht die dümmsten im Laden sind... Hören viele nicht gerne, ist aber halt so. Sie sind fast allen andern Angestellten intellektuell überlegen, wenn es um den Umgang mit langen Abhägigkeitsketten und Systemverhalten geht. Trotzdem sind Software-Entwickler natürlich Menschen mit allen ihren Eigenschaften wie Stolz, Faulheit, Gier etc. > wie bekommt man so einen Laden wieder "In die Spur"? Was man in > Zukunft anders machen muss, das ist klar, aber wie kommt man dahin? Das ist einfach. Es bedarf einem charismatischem Chef/Vorgesetztem mit großem Fachwissen und scharfen Verstand und Analysefähigkeiten der weiß wie Softwareentwickler ticken und ein 100% Commitment der Geschäftsführung zur Qualitätsoffensive. Da aber Geschäftsführungen in der Regel im Alltag mit die ersten sind, die gegen ihre eigenen Prinzipien verstoßen, weil irgendwo ein Euro mehr zu machen ist, ist das in den meisten Fällen zum Scheitern verurteilt.
Joe J. schrieb: > Meine Meinung zum Thema: > > 1. Alles zunächst so weiter laufen lassen wie es ist, sofern die Firma > noch Geld verdient. Das reicht nicht, das haben schon viele Firmen böse erfahren. Mit laufen lassen verlierst du mit jedem Tag Handlungsspielraum. Das Geld, welches du heute verdienst, wird mit der Software verdient die in der Vergangenheit geschrieben wurde. Womit wird morgen das Geld verdient? Mit Software die heute geschrieben werden muss. Wenn die Entwicklung heute nicht läuft sieht die Zukunft morgen dunkel aus.
Hannes J. schrieb: > Womit wird morgen das Geld verdient? Mit Software die heute geschrieben > werden muss. Wenn die Entwicklung heute nicht läuft sieht die Zukunft > morgen dunkel aus. Das Eine schließt das Andere nicht aus.
Ich wollte mich nur mal "lebend" melden. Ich habe hier nicht viel beizutragen (war ja eine Frage) und lese gespannt mit. Spannend!
Frank E. schrieb: > Ich habe hier nicht viel beizutragen (war ja eine Frage) Oliver S. schrieb: > mal ganz ehrlich: was ist dein Job in dem ganzen Zirkus?
Jetzt mal Butter bei die Fische: - wieviel Umsatz? - wieviel Leute? - wieviel Gewinn vor Steuern? Vllt. klärt sich bereits einiges nach Kenntnis dieser doch ziemlich wichtigen Parameter. Nochwas: das Aufräumen muss vor der Übernahme geschehen! Man darf mutmaßen, warum.
> Nach der Übername stellt sich allerdings heraus, dass es sich um einen > ziemlichen Sausstall handelt. Der bisherige Chef "bereitete" sich seit > längerem af seinen Ruhestand vor und hat die Zügel erheblich schleifen > lassen: Sag jetzt bitte nicht, dass du den Laden bereits gekauft hast!
Bernd G. schrieb: >> Nach der Übername stellt sich allerdings heraus, dass es sich um einen >> ziemlichen Sausstall handelt. Der bisherige Chef "bereitete" sich seit >> längerem af seinen Ruhestand vor und hat die Zügel erheblich schleifen >> lassen: > > Sag jetzt bitte nicht, dass du den Laden bereits gekauft hast! Die ganze Geschichte macht doch wenig Sinn. Warum kauft man einen SW Laden? Entweder man will das Know How der Leute. Dann ist die Codebasis egal. Oder man will den Code (dann kennt man den aber und weiß was man kauft). Oder man will einfach X SW Entwickler auf einmal einkaufen. Dann ist der Code auch egal.
Cyblord -. schrieb: > Warum kauft man einen SW > Laden? Entweder man will das Know How der Leute. naja, oder man hat von SW keine Ahnung, investiert in einen in leuchtenden Einhornpupsfarben schimmernden Laden und stellt dann fest, dass man von SW keine Ahnung hat, aber auf jeden Fall mehr, als die, die (warum auch immer) damit jahrelang ihr Geld verdient haben (und am Ende sogar einen Käufer fanden).
> Warum kauft man einen SW Laden?
Vllt weil es einen Kundenstamm gibt, an den man ansonsten nicht
herankommt?
Vllt weil mit der vorhandenen SW noch über einige Jahre Gewinn generiert
werden kann oder zumindest die Hoffnung darauf besteht? Weil man die
Hoffnung hat, zuätzlich seine eigenen Erzeugnisse mitzuverkaufen?
Außerdem ist es meist weniger anstrengend, eine eingeführte Produktlinie
zu übernehmen und auszubauen, als alles vom Urschleim an neu zu
erfinden, um dann festzustellen, dass es bereits einen Konkurrenten
gibt.
Nun ja, mit dem kaufmännischen Denken ist es bei Ings und Artverwandten
meist nicht weit her.
Unbekannt U. schrieb: > Trotzdem sind > Software-Entwickler natürlich Menschen mit allen ihren Eigenschaften wie > Stolz, Faulheit, Gier etc. und genau dort zu packen. Finde den Punkt und überleg wie er sich zur Motivation eignet. Mit Faulen kann man schaffen mit dummen nicht. Nutze genau diese Eigenschaften. Und lass die Herren ein automatisches Docusystem für ihren Saustall basteln. Sie werden wissen welche Leichen sie wo vergraben haben. Wenn nicht werden sie sie wiederfinden für jedes ordentlich die redocumentierte Fragment gibt es ein nutzenbezogenes Bobon nach dem Gusto des Aufkehrenden. Namaste
Winfried J. schrieb: > Mit Faulen kann man schaffen mit dummen nicht. Nutze genau diese > Eigenschaften. Und lass die Herren ein automatisches Docusystem für > ihren Saustall basteln. Sie werden wissen welche Leichen sie wo > vergraben haben. Du Träumer! Du hast weder Ahnung von Menschen, noch Softwerken noch Firmensanierungen. Man kann nicht die Frösche fragen, wenn man den Sumpf austrocknen will! Die Aufgabe ist von der psychiologischen und auch arbeitsrechtlichen Seite DEUTLICH schwieriger als der technische Kram!
Ich hatte mal das "Vergnügen", in einer Firma anzufangen, wo ich ein Projekt weiterführen sollte. Als ich am 2. Tag mal nach Doku fragt, sagt der Ex-Entwickler, "komm dann mal mit Papier und Bleistift vorbei, ich erzähl dir was". Ohje! Es gab NULL Dokumentation! Nicht mal ein paar Skizzen auf einem Schmierzettel! ALLE Parameter schwirrten nur in den Köpfen von Leuten rum, die irgendwie mal was damit zu tun hatten. Es gab für mich als Hardwerker nur die Schaltpläne der Platinen und VHDL-Code! Ich hab dann schrittweise über Wochen und mit viel Trial & Error sowie Mitarbeit bei der laufenden Produktion am Gerät per Reverse Engineering eine Doku erstellt, so gut es halt ging. Und den ganze Schlamassel hat die Geschäftsleitung voll gedeckt, je geradezu mitgetragen!!!! Aus dem Laden war ich nach 6 Monaten wieder verschwunden, Gott sei Dank!
Es ist sehr informativ, eure Meinungen zu dem Fall zu lesen. Mehr Details möchte ich jedoch nicht ausbreiten, sorry. Wie eine Firma organisiert sein sollte, wie man effizient oder "agil" Software entwickelt ... darüber gibt es endlos kluge Bücher, Kurse, Vorträge usw. Nirgendwo ist jedoch beschrieben, wie man einen existierenden "Sauladen" mit möglichst wenig Kollateralschäden dahin überführt. Das ist wahrscheinlich sogar schwieriger, als ber Null anzufangen ...
:
Bearbeitet durch User
Frank E. schrieb: > Nirgendwo ist jedoch beschrieben, wie man einen existierenden "Sauladen" > mit möglichst wenig Kollateralschäden dahin überführt. Das ist > wahrscheinlich sogar schwieriger, als ber Null anzufangen ... Deshalb kauft man keinen Sauladen. Ganz einfach.
Cyblord -. schrieb: > Frank E. schrieb: >> Nirgendwo ist jedoch beschrieben, wie man einen existierenden "Sauladen" >> mit möglichst wenig Kollateralschäden dahin überführt. Das ist >> wahrscheinlich sogar schwieriger, als ber Null anzufangen ... > > Deshalb kauft man keinen Sauladen. Ganz einfach. So einfach ist das in der Realität nicht. Das Produkt ist bisher gut im Markt, es existieren auch rentable Wartungs- und Customizingverträge .. usw. Allerdings zeigen sich erste Unzfriedenheiten bei Kunden, weil Bugfixes oder kundenspzifische Anpassungen aufgrund fehlender Sourcecodes/Dokus nicht oder nur sehr schleppend umgesetzt werden können. Deshalb ist es höchste Zeit, etwas zu unternehmen. Richtig ist wohl, dass der Käufer aufgrund eines bisher guten persönlichen Verhältnisses zum Vorbesitzer nicht mit dieser Art von Problemen gerechnet hat ... um es mal dezent auszudrücken. Bücher und Bilanzen sehen tatsächlich sehr gut aus und das entspricht auch (noch) den Tatsachen. Nur ist der aktuelle Grad der internen "Organisiertheit" offenbar bisher nicht Gegenstand einer Unternehmensbewertung.
:
Bearbeitet durch User
Frank E. schrieb: > Nirgendwo ist jedoch beschrieben, wie man einen existierenden "Sauladen" > mit möglichst wenig Kollateralschäden dahin überführt. Meine persönliche Meinung dazu: Das wird wohl nur funktionieren, in dem du die Leute mit nimmst, bzw auf deine Seite ziehst. Ich denke mal, dass es in der Firma schon den einen oder anderen gibt, dem der "Saustall" derzeit nicht so passt, mit denen wirst du leichtes Spiel haben. Bei vielen anderen wirst du mehr oder weniger Überzeugungsarbeit führen müssen, ggf. ist da auch "Zuckerbrot & Peitsche" von Nöten. Und dann gibt es natürlich die unbelehrbaren, das kann dann der Kollateralschaden werden. Dass es der Chef hat schleifen lassen, wird auch nix unbekanntes sein. Aber du als neuer Besitzer/GF der Firma bist für die Leute der größte Unsicherheitsfaktor: wie bist du drauf? Was erzählst du, was du vor hast? Was hast du wirklich vor? Müssen Leute gehen? Willst du langfristig agieren oder eher Heuschrecke?
> Nur ist der aktuelle Grad der internen "Organisiertheit" offenbar bisher > nicht Gegenstand einer Unternehmensbewertung. Das wäre der Part des Erwerbers gewesen, sich darüber kundig zu machen.
Bernd G. schrieb: > Das wäre der Part des Erwerbers gewesen, sich darüber kundig zu machen. So ist es. Und da der Laden ja anscheinend bisher durchaus wirtshcaftlich gesund war, war das bisherigen Vorgehen wohl nicht so ganz verkehrt. Alles ist ein Kompromiß. Immer. Die Kunden zahlen nicht für Git, die zahlen für jemanden, der ihre Probleme löst. Wie man das intern organisiert, ist bei einer Softwarebude die originäre Fragestellung für einen Unternehmner. Wenn der nicht weiß, was er machen soll, ist der da fehl am Platz. Er darf natürlich jemanden fragen, der sich auskennt, wobei guter Rat halt teuer ist. Der TO ist das sicherlich nicht. Oliver
:
Bearbeitet durch User
Frank E. schrieb: > Es ist sehr informativ, eure Meinungen zu dem Fall zu lesen. Mehr > Details möchte ich jedoch nicht ausbreiten, sorry. > > Wie eine Firma organisiert sein sollte, wie man effizient oder "agil" > Software entwickelt ... darüber gibt es endlos kluge Bücher, Kurse, > Vorträge usw. > > Nirgendwo ist jedoch beschrieben, wie man einen existierenden "Sauladen" > mit möglichst wenig Kollateralschäden dahin überführt. Das ist > wahrscheinlich sogar schwieriger, als ber Null anzufangen ... Nein, es ist ein frage wie man das verbliebene Personal motiviert. Ich habe das hinter mir. Es hat mich 2 Jahre gekostet als Externer, neben meiner Firma in Österreich die Schweizer Firma eines Kollegen in Italien nach dem Fortgang von 3 Mitarbeitern mit nur einer unbedarften Sekretärin und einem durch mich neu besetzten Mitarbeiter wieder aufs Gleis zu bringen 5% der Kundschaft sind im 1. Jahr verloren. Seit 14 Monaten keine Kundenabgänge. Statt dessen erste Neukunden. Altanlagen mit mangelhafter oder ganz ohne Doku wieder genehmigungsfähig durch den TÜV zu bringen ist meine Passion geworden. Zuletzt hatte ich die TSX 17 mit einem von mir von Grund auf neu geschriebenen Progamm wieder in Betrieb gebracht, ohne Schaltplan oder Docu, nach dem der Mitbewerber die CMOS Batterie 30 Jahre nicht ersetzt hatte und auch kein Backup. Das brachte ein schönes Sümmchen. Trotzdem würde ich eine solche Firma erst übernehmen, wenn ich weis was im Sack ist. Namaste
:
Bearbeitet durch User
Winfried J. schrieb: > Trotzdem würde ich eine solche Firma erst übernehmen, wenn ich weis was > im Sack ist. Eine Katze? Vielleicht sogar eine schrödingersche? ;-)
Frank E. schrieb: > Erstmal danke für deine Antwort. Ich kenne aus eigener > Praxis den permanenten Widerspruch hinsichtlich der > empfohlenen Dokumentation von Sourcecode in Theorie > und Praxis. Schön. Und kennst Du eventuell auch die Begeisterung der Geschäftsführung über notwendige Aufräumarbeiten -- verglichen mit der Begeisterung über neue Features? > Quasi "zähneknischend" muss ich aber eingestehen, dass > es bei Entwickler-Fluktuation kaum etwas Wichtigeres > gibt. Mal eben ein "schneller Hack" führt, sofern > erfolgreich, temporär zu Hochgefühlen und Anerkennung > beim Kunden, macht aber später nichts als Ärger. Die Idee des Refactoring ist Dir unbekannt?! > Man wird die (normgerechte) Doku-Pflicht wohl bei > Projekten dieser Größenordnung mit eiserner Peische > durchstzen müssen, bei Strafe des eigenen Unterganges ... Es ist betrüblich, aber Tom DeMarco scheint doch Recht zu haben: Das Einzige, was Manager zuwege bringen, ist, Druck auf ihre Leute auszuüben.
A. S. schrieb: > Ich verstehe nicht, wie in Zeiten von Hochsprachen > neben dem Quelltext eine Dokumentation existieren > soll. Nun ja... so besonders innovativ kann Eure Software nicht sein, wenn ausschließlich Verfahren zum Einsatz kommen, die SO bekannt und verbreitet sind, dass ihre Kenntnis bei jedem durchschnittlichen Programmierer vorausgesetzt werden kann.
Frank E. schrieb: > Wie eine Firma organisiert sein sollte, wie man > effizient oder "agil" Software entwickelt ... darüber > gibt es endlos kluge Bücher, Kurse, Vorträge usw. Klar. Als angehender Geschäftsführer hat man es natürlich nicht nötig, die Bücher auch noch zu LESEN und deren Inhalt zu VERSTEHEN -- nein, solche niederen Tätigkeiten überlässt man dem Praktikanten. > Nirgendwo ist jedoch beschrieben, wie man einen > existierenden "Sauladen" mit möglichst wenig > Kollateralschäden dahin überführt. Du irrst. Dieses Problem hat jedes größere Projekt, das auf einem vorhergehenden aufbaut. Genau betrachtet hat es sogar (fast) jedes größere Projekt, das lange genug läuft -- es muss gar nicht unbedingt einen Vorgänger geben. Unordnung und Chaos entstehen von allein, wenn man nicht aktiv gegenarbeitet. Und eins fällt bei Deinen Einlassungen auf: Es ist kein Sterbenswörtchen von der völlig abstrusen Idee zu sehen, einfach mal mit den Entwickler zu REDEN . Das lässt tief blicken...
Egon D. schrieb: > Als angehender Geschäftsführer hat man es natürlich > nicht nötig, die Bücher auch noch zu LESEN und deren > Inhalt zu VERSTEHEN -- nein, solche niederen > Tätigkeiten überlässt man dem Praktikanten. Frank ist da wohl näher am Praktikanten als am Geschäftsführer. Zumindestens lässt das der Thread hier, und auch sein anderer, der gerade läuft, vermuten. Beitrag "Processing: Merkwürdiger Video-Fehler" Oliver
Egon D. schrieb: > Nun ja... so besonders innovativ kann Eure Software nicht > sein, wenn ausschließlich Verfahren zum Einsatz kommen, > die SO bekannt und verbreitet sind, dass ihre Kenntnis > bei jedem durchschnittlichen Programmierer vorausgesetzt > werden kann. Komplexität oder Bekanntheit der Verfahrenstechnik haben wenig mit der Umsetzung in SW zu tun. Und schon gar nichts mit der internen Dokumentation der SW, die der TO bemängelt. Wenn ich eine SW schreibe, die beispielsweise die Steuergesetzgebung irgendwie abbildet, dann sollte das Hauptaugenmerk darauf liegen, möglichst wenige Brüche/Übersetzungen zwischen Source-Code und Gesetzen zu haben. Wenn ich irgendwann aus Performance-Gründen trickreiche Mathe-Hacks brauche, ja dann muss ich die gut dokumentieren. Oder wenn ich mir meine eigene Sprache/Programmiersprache kreiere, ja dann brauche ich dazu meist mehr Zeit für Doku als ich spare. Aber der meiste Code sollte nicht so aussehen, sondern in Aufbau und Benamung der Aufgabe entsprechen. Was der Code macht, ist ja (meist) beschrieben. Wie er das macht, sollte man erkennen. Es geht auch kaum anders: Quelltext-Dokumentation ist von Sonderfällen abgesehen meist ausdrucksschwächer.
A. S. schrieb: > Egon D. schrieb: >> Nun ja... so besonders innovativ kann Eure Software nicht >> sein, wenn ausschließlich Verfahren zum Einsatz kommen, >> die SO bekannt und verbreitet sind, dass ihre Kenntnis >> bei jedem durchschnittlichen Programmierer vorausgesetzt >> werden kann. > > Komplexität oder Bekanntheit der Verfahrenstechnik haben > wenig mit der Umsetzung in SW zu tun. Ich habe da vielleicht einen eingeschränkten Blickwinkel. Die numerischen Grundverfahren sind ja in der einschlägigen Literatur beschrieben, aber zu der Arbeit, die reine Numerik zu verstehen, kommen ja noch zwei Fragen dazu: Liegen in meinem Anwendungsfall überhaupt alle mathematischen Voraussetzungen vor, damit das Verfahren verwendbar ist? Und wie implementiert man das Verfahren am sinnvollsten? Normalerweise muss ich mir dazu dringend Aufzeichnungen zusätzlich zum Quelltext machen, damit das überhaupt etwas wird. > Und schon gar nichts mit der internen Dokumentation der > SW, die der TO bemängelt. Sehe ich deutlich anders. Für eine Methode oder ein Verfahren, das zum Lehrkanon gehört, genügt ein Hinweis auf den Namen oder eine Literaturstelle. Ein sehr spezielles (oder speziell angepasstes) Verfahren muss natürlich intern dokumentiert werden. Negativbeispiel: Eine FOSS-Programmsammlung enthält ein Tool für die Schwarz-Weiss-Wandlung von Graustufenbildern mittels adaptiver Schwellwerte. Der Quelltext ist -- glaube ich -- von 2006; als Literaturstelle ist die deutschsprachige Wikipädie angegeben. Super. Wenn ich das Verfahren verstehen will, muss ich dem Programmautor hinterherrecherchieren und den vor 14 Jahren gültigen Artikel wiederherstellen. Wäre es nicht etwas kollegialer gewesen, dem Quelltext eine kurze Verfahrensbeschreibung beizulegen? Anderes Beispiel: An jeder Ecke des Internet kann man die Aussage finden, dass es mittels Dekonvolution möglich ist, Digitalphotos nachträglich zu schärfen -- aber nirgendwo findet man eine allgemeinverständliche Erklärung, wie man das implementiert. (Nein, "Unscharf maskieren" genügt noch nicht...) Nach wochenlanger Recherche habe ich dann -- nicht zuletzt aufgrund glücklicher Zufälle -- herausgefunden, dass die van-Cittert-Dekonvolution aus der Neumann-Reihe herleitbar ist, und tagelanges Herumrechnen führte dann zu dem Ergebnis, dass das recht einfach als Fixpunktiteration darstellbar ist. Verglichen mit dem dornenreichen Weg der Herleitung ist das beschämend einfach zu implementieren -- aber ohne zusätzliche Beschreibung begreift keine Sau, WARUM das funktioniert. Man muss ja auch mal den den denken, der das testen soll. > Wenn ich eine SW schreibe, die beispielsweise die > Steuergesetzgebung irgendwie abbildet, dann sollte > das Hauptaugenmerk darauf liegen, möglichst wenige > Brüche/Übersetzungen zwischen Source-Code und Gesetzen > zu haben. Selbstverständlich. Das gilt für Software, die Arbeits- abläufe automatisiert, die außerhalb und unabhängig vom Computer definiert werden. Das "Verfahren" ist in diesen Fällen nicht spezifisch für seine Umsetzung in Software und ist bereits dokumentiert -- nämlich in Form der Gesetze. Aber: Nicht alle Software bildet interaktiv Geschäfts- abläufe ab. > Wenn ich irgendwann aus Performance-Gründen trickreiche > Mathe-Hacks brauche, ja dann muss ich die gut dokumentieren. Nun ja, Numerik ist schon noch etwas mehr als "trickreiche Mathe-Hacks". > Was der Code macht, ist ja (meist) beschrieben. Siehe oben: Bei Software, die Geschäftsabläufe automatisiert, trifft das meistens zu. Anders aber bei Software, die automatisiert Daten verarbeiten soll.
Oliver S. schrieb: > Egon D. schrieb: >> Als angehender Geschäftsführer hat man es natürlich >> nicht nötig, die Bücher auch noch zu LESEN und deren >> Inhalt zu VERSTEHEN -- nein, solche niederen >> Tätigkeiten überlässt man dem Praktikanten. > > Frank ist da wohl näher am Praktikanten als am Geschäftsführer. > Zumindestens lässt das der Thread hier, und auch sein anderer, der > gerade läuft, vermuten. Wer hier schon länger unterwegs ist und seine Threads kennt, weiß, daß mehr als oberflächliche Beschäftigung mit jedweden Themen nicht sein Ding ist. Er hängt sich in alles Mögliche rein, versteht aber nur sehr wenig, fragt dann hier nach Lösungen und zeigt sich wenig dankbar. Meist gibt er nicht mal ein Feedback. Wäre er nur Hobbybastler, würde ich mich nicht drüber auslassen. Das Fatale ist jedoch, daß Herr Esselbach für seine dilettantische "Arbeit" den Kunden Geld abknöpft. Mich persönlich kotzt sowas maßlos an, weil ich oft bei Kunden hinter genau solchen Murksern aufräumen muß, die von heute auf morgen verschwinden und die Leute mit ihren Problemen im Stich lassen.
Egon D. schrieb: > Anders aber bei Software, die automatisiert Daten verarbeiten soll. Du hast natürlich Recht, und jeder legt seine Erfahrungen zugrunde. Ich komme aus der embedded Steuerungstechnik (nicht Regelungstechnik) wo ein Großteil des Codes mit "wenn dies und das und jenes, dann so sonst so" geschrieben werden kann. Was ich aber oft sehe, ist, dass die externen Sensoren, Aktoren und Events bis zu Unkenntlichkeit umbenannt werden, quasi im Kopf DeMorgan und rein abstrakte, zufällig passende Kathegorisierungen darübergestreut werden und das ganze bei der Weiterentwicklung mit Ausnahmen verstümmelt wird, weil die Kathegorisierungen halt keine Entsprechung in RL hatten. Ein anderes Extrem sind Abstrahierungen, wo quasi für eine konkrete HW ein universelle abstrakte Maschine definiert wird, die zufällig am Ende doch nur die Eigenschaften der einen HW hat, aber jede Interaktion durch Zwiebelschichten mit Umbenennungen undurchsichtig macht. Meist sogar zu 90% dokumentiert.
Icke ®. schrieb: > Oliver S. schrieb: >> Egon D. schrieb: >>> Als angehender Geschäftsführer hat man es natürlich >>> nicht nötig, die Bücher auch noch zu LESEN und deren >>> Inhalt zu VERSTEHEN -- nein, solche niederen >>> Tätigkeiten überlässt man dem Praktikanten. >> >> Frank ist da wohl näher am Praktikanten als am Geschäftsführer. >> Zumindestens lässt das der Thread hier, und auch sein anderer, der >> gerade läuft, vermuten. > > Wer hier schon länger unterwegs ist und seine Threads kennt, weiß, daß > mehr als oberflächliche Beschäftigung mit jedweden Themen nicht sein > Ding ist. Er hängt sich in alles Mögliche rein, versteht aber nur sehr > wenig ... Na du musst es ja wissen, Superhirn. Das dämliche Gebabbel kannst du voll stecken lassen. Und wenn ich gelegentlich kein Feedback liefere, so liegt das nicht selten an solchen Kuscheltieren, wie dich. Wenn dir das Thema zu trivial ist, dann schweig doch einfach und wende dich Höherem zu ... Den anderen danke ich für ihre sinnvollen und erhellenden Antworten, durchsetzt mit vielen praktischen Erfahrungen. Die Realität ist oft viel schlimmer, als man sich das vorstellen mag. Wegen Mangels an geeignetem Personal, wurden in den letzten Jahren die wildesten Leute eingestellt und leider nicht domestiziert. Die waren allesamt weder dumm noch faul, aber meistens völlig team-unfähig, zumindest was das Prgrammieren betraf. In dem Projekt stecken inzwischen fast ein halbes Dutzend Programmiersprachen, je nachdem, was die geworbenen Superhelden gerade so konnten oder mochten: C++, Java, Python, C#, C, PL-SQL (massenhaft Trigger in Oracle) usw. Laut eines der verbliebenen Entwickler sei es ein Wunder, dass das System überhaupt noch läuft ...
:
Bearbeitet durch User
Nice, in that case do never stop a running system. As you know, this is a time bomb cluster with a vibration trigger. 1 Go away. 2 Go to the cemetery. Go straight there or mime the hero beforehand. ????? Namaste
:
Bearbeitet durch User
Eine bisher nicht beachtete Moeglichkeit. -Ausarbeiten eines neuen Konzeptes unter Einbezug der Kunden -Inszenieren dieses neuen Konzeptes als Durchbruch, mit vielen neuen Kunden. -Aufhypen -Ankuendigung eines Boersengangen, resp Aufstockung -Verkauf der vielversprechenden Firma -Abziehen einer guten Provision
:
Bearbeitet durch User
Frank E. schrieb: > Die Realität ist oft viel schlimmer, als man sich das vorstellen mag. Ist doch ganz einfach: neues Team bilden, Struktur reinbringen, Software und Doku neu schreiben. Dauert 3 Jahre und kostet 12 Mannjahre, also mit externer Beratung und allem sonstigen Kleinkram mal locker eine Million. Die Zeit und das Geld hat derjenige nicht, der das verantworten muß (und das bist nicht du). Du Firma muß Geld verdienen. Die Realität ist oft viel banaler, als du dir das vorstellen kannst. Oliver
Frank E. schrieb: > Die Realität ist oft viel schlimmer, als man sich > das vorstellen mag. Nun ja... sagen wir so: Meine Erfahrungsbasis ist nicht übermäßig breit, aber ich habe Dank meiner... ähhh... etwas "unstetigen Erwerbsbiographie" schon das eine oder andere Meisterstück deutscher Unternehmens- und Ingenieurskultur von innen gesehen... > Wegen Mangels an geeignetem Personal, wurden in den > letzten Jahren die wildesten Leute eingestellt und leider > nicht domestiziert. Die waren allesamt weder dumm noch > faul, aber meistens völlig team-unfähig, zumindest was > das Prgrammieren betraf. Das finde ich sehr verdächtig. Ich kenne kein Techniker-Team, in dem die MEISTEN völlig team-unfähig sind. Ich kenne dagegen sehr wohl Chefs, die weitgehend team-unfähig (bis an die Grenze zum Psychopathen) sind. > In dem Projekt stecken inzwischen fast ein halbes > Dutzend Programmiersprachen, je nachdem, was die > geworbenen Superhelden gerade so konnten oder mochten: > C++, Java, Python, C#, C, PL-SQL (massenhaft Trigger > in Oracle) usw. Ja und?! Weniger als drei Sprachen geht sowieso kaum: Eine SQL- Varianten für die Datenbanken, eine aus der C-Familie als Allzweckwaffe und eine Scriptsprache für den schnellen Hack zwischendurch. Bei langlebigen Produkten kann im Laufe der Zeit schon mal die eine und andere Sprache dazukommen. > Laut eines der verbliebenen Entwickler sei es ein > Wunder, dass das System überhaupt noch läuft ... Zeige mir ein BELIEGIGES DURCHSCHNITTLICHES Unternehmen, und ich zeige Dir ein Unternehmen, in dem die Mitarbeiter klagen und barmen, dass es hier aber BESONDERS schlimm und chaotisch ist... Ich gewinne allmählich den Eindruck, dass es mehr darum geht, mit Macht das Haar in der Suppe zu finden, damit man den Kaufpreis kräftig drücken kann.
A. S. schrieb: > Du hast natürlich Recht, und jeder legt seine > Erfahrungen zugrunde. Klar. Interessant finde ich, dass diese selbst bei Beschränkung auf das Gebiet "Software" offensichtlich nicht immer identisch sind. > Ich komme aus der embedded Steuerungstechnik (nicht > Regelungstechnik) wo ein Großteil des Codes mit "wenn > dies und das und jenes, dann so sonst so" geschrieben > werden kann. Naja, da ist ja schätzungsweise der Großteil der Funktion der Software schon durch die (geplante) Funktionsweise des zu steuernden Gerätes vorgegeben, oder? Soll heißen: Ich habe das Gefühl, dass man zu zwei Fehlschlüssen neigt: 1. Daraus, dass der Programmierer nicht eigenhändig die Dokumentation schreibt, wird gefolgert, dass keine Dokumentation erstellt wird. Das folgt aber gar nicht; häufig gibt es auch andere Leute als Programmierer, die Dokumentation schreiben. (Das können z.B. Tester sein, denn die bekommen schließlich zwangsweise mit, was die Software TATSÄCHLICH macht.) 2. Dokumentation muss nicht zwingend NACH dem Ausführen der Arbeit (--> Protokoll) erstellt werden, sie kann auch VORHER verfasst werden (--> Plan/Vorgabe). Punkt 2. musste ich in der alten Firma auf die harte Tour lernen; das Ergebnis eines wilden Kampfbastelprojektes (Geräteentwicklung mit Mechanik/Elektronik/Software), bei dem wir immer nur von Woche zu Woche improvisiert haben, bestand dann -- wie zu erwarten war -- in einem schlecht und recht funktionierenden Gerät und einer gähnenden Leere, wo eigentlich die technischen Unterlagen sein sollten. Wäre vorher weniger Druck aufgebaut worden, wäre mehr Zeit in eine PRAKTIKABLE Vorausplanung geflossen, wäre sowohl das technische Ergebnis besser als auch am Ende eine Dokumentation vorhanden gewesen. Spätere Projekte haben das bestätigt. > Was ich aber oft sehe, ist, dass die externen Sensoren, > Aktoren und Events bis zu Unkenntlichkeit umbenannt > werden, quasi im Kopf DeMorgan und rein abstrakte, > zufällig passende Kathegorisierungen darübergestreut > werden und das ganze bei der Weiterentwicklung mit > Ausnahmen verstümmelt wird, weil die Kathegorisierungen > halt keine Entsprechung in RL hatten. Es ist interessant, dass Du das schreibst -- ich glaube, das ist mir auch schon passiert. "Zurückführen der komplizierten Fälle auf Kombinationen von einfachen" ist ja eigentlich ein seriöses mathematisches Prinzip -- blöd ist halt nur, wenn die komplexen Fälle in Wahrheit eben NICHT NUR einfache Linearkombinationen der einfachen sind. Warum das passiert weiss ich nicht. Scheint mir irgendwie mit mangelnder geistiger Durchdringung der Anforderungen zu tun zu haben. > Ein anderes Extrem sind Abstrahierungen, wo quasi für > eine konkrete HW ein universelle abstrakte Maschine > definiert wird, die zufällig am Ende doch nur die > Eigenschaften der einen HW hat, aber jede Interaktion > durch Zwiebelschichten mit Umbenennungen undurchsichtig > macht. Meist sogar zu 90% dokumentiert. Overengineering.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.