Forum: Offtopic Softwarefirma nach Übernahme "aufräumen", aber wie?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Frank E. (Firma: Q3) (qualidat)


Bewertung
-11 lesenswert
nicht lesenswert
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

von Ben B. (Firma: Funkenflug Industries) (stromkraft)


Bewertung
1 lesenswert
nicht lesenswert
> - 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.

von Frank E. (Firma: Q3) (qualidat)


Bewertung
-2 lesenswert
nicht lesenswert
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 ...

von Georg A. (georga)


Bewertung
3 lesenswert
nicht lesenswert
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.

von Gerald K. (geku)


Bewertung
0 lesenswert
nicht lesenswert
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

von Günter N. (gnatz)


Bewertung
0 lesenswert
nicht lesenswert
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.

von A. S. (achs)


Bewertung
-9 lesenswert
nicht lesenswert
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.

von Gerald K. (geku)


Bewertung
0 lesenswert
nicht lesenswert
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

von (prx) A. K. (prx)


Bewertung
2 lesenswert
nicht lesenswert
Welche Sprache betrachtest du als für dokumentationslose Programmierung 
geeignet? Dabei berücksichtigend, dass diese Branchensoftware im Kern 
vielleicht schon Jahrzehnte alt ist.

von Rolf R. (dankobum)


Bewertung
1 lesenswert
nicht lesenswert
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".

von Oliver S. (oliverso)


Bewertung
-2 lesenswert
nicht lesenswert
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

von A. S. (achs)


Bewertung
-2 lesenswert
nicht lesenswert
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.

von A. S. (achs)


Bewertung
0 lesenswert
nicht lesenswert
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.

von ~Mercedes~  . (lolita)


Bewertung
-3 lesenswert
nicht lesenswert
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

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
~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.

von ~Mercedes~  . (lolita)


Bewertung
-1 lesenswert
nicht lesenswert
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

von Hannes J. (Firma: _⌨_) (pnuebergang)


Bewertung
2 lesenswert
nicht lesenswert
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.

von Sven L. (sven_rvbg)


Bewertung
3 lesenswert
nicht lesenswert
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.

von Pandur S. (jetztnicht)


Bewertung
0 lesenswert
nicht lesenswert
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
von Oliver S. (oliverso)


Bewertung
-1 lesenswert
nicht lesenswert
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
von Gerald K. (geku)


Bewertung
0 lesenswert
nicht lesenswert
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
von Falk B. (falk)


Bewertung
2 lesenswert
nicht lesenswert
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.

von Gerald K. (geku)


Bewertung
-1 lesenswert
nicht lesenswert
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
von Joe J. (j_955)


Bewertung
2 lesenswert
nicht lesenswert
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

von Unbekannt U. (unbekannter)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Hannes J. (Firma: _⌨_) (pnuebergang)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Joe J. (j_955)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Frank E. (Firma: Q3) (qualidat)


Bewertung
-2 lesenswert
nicht lesenswert
Ich wollte mich nur mal "lebend" melden. Ich habe hier nicht viel 
beizutragen (war ja eine Frage) und lese gespannt mit. Spannend!

von A. S. (achs)


Bewertung
1 lesenswert
nicht lesenswert
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?

von Bernd G. (Firma: Bannerträger des Fortschritts) (berndg)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Bernd G. (Firma: Bannerträger des Fortschritts) (berndg)


Bewertung
-1 lesenswert
nicht lesenswert
> 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!

von Cyblord -. (cyblord)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von A. S. (achs)


Bewertung
0 lesenswert
nicht lesenswert
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).

von Bernd G. (Firma: Bannerträger des Fortschritts) (berndg)


Bewertung
-3 lesenswert
nicht lesenswert
> 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.

: Bearbeitet durch User
von Winfried J. (Firma: Nisch-Aufzüge) (winne) Benutzerseite


Bewertung
-4 lesenswert
nicht lesenswert
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

von Falk B. (falk)


Bewertung
1 lesenswert
nicht lesenswert
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!

von Falk B. (falk)


Bewertung
3 lesenswert
nicht lesenswert
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!

von Frank E. (Firma: Q3) (qualidat)


Bewertung
-4 lesenswert
nicht lesenswert
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
von Cyblord -. (cyblord)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Frank E. (Firma: Q3) (qualidat)


Bewertung
-1 lesenswert
nicht lesenswert
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
von Matthias S. (da_user)


Bewertung
4 lesenswert
nicht lesenswert
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?

von Bernd G. (Firma: Bannerträger des Fortschritts) (berndg)


Bewertung
-1 lesenswert
nicht lesenswert
> 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.

von Oliver S. (oliverso)


Bewertung
3 lesenswert
nicht lesenswert
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
von Winfried J. (Firma: Nisch-Aufzüge) (winne) Benutzerseite


Bewertung
-3 lesenswert
nicht lesenswert
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
von Falk B. (falk)


Bewertung
0 lesenswert
nicht lesenswert
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?
;-)

von Egon D. (egon_d)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Egon D. (egon_d)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Egon D. (egon_d)


Bewertung
0 lesenswert
nicht lesenswert
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...

: Bearbeitet durch User
von Oliver S. (oliverso)


Bewertung
-1 lesenswert
nicht lesenswert
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

von A. S. (achs)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Egon D. (egon_d)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Icke ®. (49636b65)


Bewertung
3 lesenswert
nicht lesenswert
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.

von A. S. (achs)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Frank E. (Firma: Q3) (qualidat)


Bewertung
-5 lesenswert
nicht lesenswert
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
von Winfried J. (Firma: Nisch-Aufzüge) (winne) Benutzerseite


Bewertung
-4 lesenswert
nicht lesenswert
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
von Pandur S. (jetztnicht)


Bewertung
0 lesenswert
nicht lesenswert
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
von Oliver S. (oliverso)


Bewertung
0 lesenswert
nicht lesenswert
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

von Egon D. (egon_d)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Egon D. (egon_d)


Bewertung
0 lesenswert
nicht lesenswert
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.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail, Yahoo oder Facebook? Keine Anmeldung erforderlich!
Mit Google-Account einloggen | Mit Facebook-Account einloggen
Noch kein Account? Hier anmelden.