VBA Projektdokumentation

[Zwenn]

Hallo Käpt'n Blaubär,

das schloss ich aus Post Nr. 9. Allerdings hast Du Recht, den Auftrag für die Software kann trotzdem jemand anders im Haus gegeben haben. In sofern gebührt das T-Shirt im Allgemeinen dem Auftraggeber :32:

Ich habe das geschrieben, weil es mir ein Rätsel ist, wie man auf die Idee kommen kann jemandem eine komplexe Aufgabe zu übertragen, der keine Ahnung von der Materie hat. Ich will damit ausdrücklich nix gegen StrammerMax sagen, denn er kann ja nix dafür. Wie bekannt, werden Fehler in einem Softwareprojekt immer teurer, je später sie entdeckt werden. Nun, ein früherer Zeitpunkt als die grundlegende Entscheidung einen Laien zu beauftragen, gibt es quasi nicht. Das blöde an solchen Sachen ist, dass der Ausführende in solchen Fällen der Dumme ist. Der muss es nämlich ausbaden, nicht der Auftraggeber.

Viele Grüße,

Zwenn

[Zwenn]

...
Natürlich hätte man das auch extern vergeben können... aber ihr wisst doch wie das läuft.. es darf nichts kosten - also muss es intern gemacht werden.

Das Tool ist essentiell und wird nahezu täglich genutzt. Insgesamt gibt es über 100 User.
Da sollte es natürlich auch funktionieren. Und das tut es auch --> solange niemand anfängt selbst daran rumzuspielen

Das ist leider ein weit verbreiteter Irrglaube. Man lässt eine Kernkomponente für den Erfolg des Unternehmens nicht professionell entwickelt, weil das zu teuer erscheint. Das muss man sich mal auf der Zunge zergehen lassen. Es ist ja gut, dass Du es so hinbekommen hast, dass es funktioniert. Aber spätestens wenn etwas geändert oder erweitert werden soll treten Probleme und damit Kosten auf, die man sehr leicht hätte vermeiden können.

Aber darum geht es hier ja eigentlich gar nicht. Ich wünsche Dir für die anstehende Dokumentation alles Gute

[Klaus-Dieter]

Hallo zusammen,

diese Aussage(n): 

Das ist das 2. Mal in meinem Leben, dass ich überhaupt mit VBA arbeite - und dafür finde ich wirklich erstaunlich, was ich in der Kürze der Zeit auf die Beine gestellt habe - das soll mir erst mal jemand ohne VBA Kenntnisse nachmachen.

muss man sich mal auf der Zunge zergehen lassen. Sie sagt alles, über Max, "sein" Projekt und auch seine Firma.

[Käpt'n Blaubär]

Hallo Klaus-Dieter,

diesen Geschmäckle bekam ich auch gleich auf die Zunge, als ich das gelesen habe.
Aber ich glaube, Max ist mit seiner Aufgabe schon gestraft genug.
Drum bin ich nicht weiter drauf eingegangen. :21:

[Klaus-Dieter]

Hallo Peter,

wie ich vermute, hat er sich beim Chef selbst ins Gespräch gebracht, wie sollte der sonst darauf gekommen sein, ihm das "aufzuhalsen"? Wenn ich überlege, wie viele Stunden wir hier im Forum mit dem Projekt schon verbraten haben. 

[schauan]

Hallöchen,

wie man sicher merkt, gibt es hier keine fachlich begründete Antworten mehr. Da sich der Thread nicht nur langsam in eine Richtung entwickelt, wo es eher darum geht, wer hier was mit welchen guten oder eher schlechten Hintergedanken gemacht hat, schließe ich den Thread.

Erste Ansätze "unfachlicher" Bemerkungen gabs schon in #2. Da wird sinngemäß behauptet, codes sind nur unter 10.000 Zeilen gut. Wenn das eine allgemeine Ansicht sein sollte, dann ist das fast schon ein Affront gegen alle, die anscheinend etwas mehr mit Excel zu tun haben. Ich möchte mal 22.120 Codezeilen von meinem bisher längsten Projekt in den Raum werfen, dass ich betreue, mit Kommentaren sind es 26.312 Zeilen. Die codes sind natürlich nicht so umfangreich kommentiert wie man es von mir häufig im Forum sieht. denn Kommentare für Laien sollte es nur im Forum geben
Enthalten in meinem langen Projekt sind übrigens 37 Module und 13 Dialogen, darin 805 Prozeduren und 637 Steuerelemente.

Mit der Dokumentation und Kommentierung halte ich es im Prinzip wie in #5 und #8 beschrieben.

In meinem Umfeld läuft auch eins mit ca. 6MB, könnten hochgerechnet über 150.00 Codezeilen sein. Wenn ich jetzt nix verwechsle, läuft das bei Klaus-Dieters ehemaligem Arbeitgeber Und es gibt sicher noch größere