Personenabhängigkeit bei selbstgeschriebenen Programmen



  • @Fletcher
    Gerade wenn ihr Anforderungen habt die sich so schnell und so oft ändern wäre ein Programmgerüst angesagt mit dem man das entsprechend schnell und flexibel umsetzen kann.
    Das dumme ist, dass sowas zu entwickeln ganz und gar nicht einfach ist, und auch einige Firmen die Auftragsarbeiten machen nicht wirklich sehr gute Softwarearchitekten haben. (Also nicht alle, einige natürlich schon.)

    Optimal wäre vermutlich eine eigene Abteilung aufzubauen die diese Software entwickelt, und möglichst eng mit den Anwendern im eigenen Haus zusammenarbeitet.
    Das kostet aber auch ordentlich Geld, und vor allem ist es für nicht-IT Firmen alles andere als einfach eine IT-Abteilung so aufzubauen und zu betreiben dass die auch gut arbeiten kann.

    Von daher also auch sehr riskant.



  • ...wäre ein Programmgerüst angesagt mit dem man das entsprechend schnell und flexibel umsetzen kann. Das dumme ist, dass sowas zu entwickeln ganz und gar nicht einfach ist, ....

    Auf die Gefahr hin, daß ich dich jetzt (wieder?) verärgere; so ein Programm gibt es schon, es heißt Excel 😉

    Optimal wäre vermutlich eine eigene Abteilung aufzubauen die diese Software entwickelt, und möglichst eng mit den Anwendern im eigenen Haus zusammenarbeitet. Das kostet aber auch ordentlich Geld,...

    Ja, wäre eine gute Idee, wenn sich mehrere Leute mit diversen Tools auskennen, aber wie du sagst: "kostet Geld". Und schon ist die Idee für die Manager nicht mehr so toll, und so dringend brauchen wir die Tools laut denen eh nicht, weil es nur "nice to have"-Dinge sind.

    Es dürfte also wirklich so sein, daß wenn Personenunabhängigkeit gefordert ist, mehrere Leute da sein müssen, die sich mit jedem Detail auskennen, oder man läßt es bleiben, wenn weiterwurschteln ohnehin billiger ist.
    Oder man läßt eben von nur einem einzigen Mitarbeiter alles machen, hat als Manager aber eine Rückfallebene, wo im Falle das Falles, zumindest zur Kundenseite hin, der Geschäftsbetrieb normal weiterläuft.



  • Sorry wenn ich was übersehen habe, aber wieso erklärst du deine Excel-Sachen nicht einfach noch zwei weiteren Kollegen? Die müssen ja nicht selbst schon so gut VBA und co. können wie du, aber zumindest die Denkfähigkeit und das Interesse dafür mitbringen, um wenn du dann (warum auch immer) mal weg bist, was damit anfangen zu können. Damit sie bis dahin nicht vergessen haben, was du ihnen erklärt hast, könntet ihr ja grob schriftlich festhalten, worum es ging.



  • Das wäre in unserem Fall die beste Idee - habe ich auch schon deponiert - aber auch unser Direktor muß sich an unternehmeneigene Spielregeln halten bezüglich Planposten. Er muß dann dem Vorstand erklären, warum er jetzt 2-3 neue Hanseln in ein Büro setzt.

    Wegen dem Auskennen: In unserem Bereich haben wir einige hundert Angestellte, aber es mir ist noch keiner über den Weg gelaufen den VBA-Programmieren interessieren würde.



  • Muss ja kein VBA sein. Aber wenn irgendein Ingenieur generell Interesse am Programmieren hat, und auch hin und wieder sowas macht, sollte das ja schon irgendwie gehen, wobei ich natürlich nicht weiß, wie highly sophisticated die Sachen, die du da machst, sind.
    Gehts denn darum, dass wenn du weg bist, jemand da sehr kurzfristig irgendwas drin machen können muss, oder hat er dann noch etwas Einarbeitungszeit?



  • Es gibt rein gar niemand bei uns der auch nur einfachste Sachen in VBA machen könnte. Du müßtest die Gesichter sehen, wenn ich auf deren PC zum ersten mal "Alt+F11" drücke (es öffnet sich der Makro-Editor); die haben gar nicht gewußt, daß es das gibt und wozu es gut ist.

    Das bzw. mein Glück dürfte sein, daß meine Sachen doch weitgehend zuverlässig funktionieren, und mir im Laufe der Zeit daher immer wieder neue Kleinigkeiten anvertraut werden. Gäbe es nur Probleme mit meinen Tools würde das schon niemand mehr verwenden oder mich dafür konsultieren.



  • Mir scheint, deine Firmenleitung hat etwas gravierendes versäumt oder ist noch nicht darauf gekommen. Einen Mitarbeiter mit dem Anspruch "Ich bin unverzichtbar" darf es nicht geben. Geh weg und mache deinen eigenen Laden auf - viel Glück!



  • berniebutt schrieb:

    Mir scheint, deine Firmenleitung hat etwas gravierendes versäumt oder ist noch nicht darauf gekommen. Einen Mitarbeiter mit dem Anspruch "Ich bin unverzichtbar" darf es nicht geben. Geh weg und mache deinen eigenen Laden auf - viel Glück!

    Naja, vor 1 Jahr sind sie schließlich doch auf mich gestoßen, weil es in der Führungsriege (wie weiter oben schon beschrieben) einen großen Wechsel gab. Seitdem werde ich oft von der eigentlichen Arbeit befreit um mich verstärkt um die VBA-Sachen zu kümmern. Ein dauerhafter Planposten dafür ist noch in Schwebe.

    Einen Mitarbeiter vom Typ "ich bin unverzichtbar" darf es in der Tat nicht geben; würde er zugelassen werden, wäre das Management erpressbar. Ich darf meine Stellung daher keinesfalls in dieser Richtung ausnutzen.

    Das mit dem "eigenen Laden aufmachen" habe ich immer wieder überlegt, aber wenn ich auf meinen Gehaltszettel schaue, habe ich Zweifel ob ich diese Summen mit dauerhafter Regelmäßigkeit bei "einem eigenen Laden" erreiche. Abgesehen davon, kann ich, wenn ich will, 6 Wochen am Stück in Urlaub gehen und kein "Schwein" ruft mich an. (positiv)



  • Fletcher schrieb:

    ...wäre ein Programmgerüst angesagt mit dem man das entsprechend schnell und flexibel umsetzen kann. Das dumme ist, dass sowas zu entwickeln ganz und gar nicht einfach ist, ....

    Auf die Gefahr hin, daß ich dich jetzt (wieder?) verärgere; so ein Programm gibt es schon, es heißt Excel 😉

    Auf die Gefahr hin, daß ich dich jetzt verärgere, oder wieder deinen "ach ich weiss es doch eh besser" Reflex triggere, aber: du hast keine Ahnung.

    Excel ist ein nettes Spielzeug, mit dem man innerhalb von sehr engen Grenzen schnell was zusammenfummeln kann.
    Wenn die komplexität der Aufgabenstellung steigt, stösst man mit Excel allerdings sehr schnell an bestimmte Grenzen, und der Aufwand steigt exponential.

    Optimal wäre vermutlich eine eigene Abteilung aufzubauen die diese Software entwickelt, und möglichst eng mit den Anwendern im eigenen Haus zusammenarbeitet. Das kostet aber auch ordentlich Geld,...

    Ja, wäre eine gute Idee, wenn sich mehrere Leute mit diversen Tools auskennen, aber wie du sagst: "kostet Geld". Und schon ist die Idee für die Manager nicht mehr so toll, und so dringend brauchen wir die Tools laut denen eh nicht, weil es nur "nice to have"-Dinge sind.

    Es dürfte also wirklich so sein, daß wenn Personenunabhängigkeit gefordert ist, mehrere Leute da sein müssen, die sich mit jedem Detail auskennen, oder man läßt es bleiben, wenn weiterwurschteln ohnehin billiger ist.

    Äh, ja, was davon war dir jetzt nicht von Anfang an klar?

    Bzw. natürlich kann man es auch über Dokumentation versuchen. Nur dass es auch ein riesen Aufwand ist alles so zu dokumentieren dass sich jmd. anderer da ausreichend schnell reinlesen kann.
    Vor allem wenn man Bastellösungen mit Excel erstellt. Und dann bleibt immer noch das Problem dass man sich bei der Dokumentation nie sicher sein kann wie gut/verständlich/vollständig die wirklich ist, so lange man sie nicht von jmd. zweitem kontrollieren lässt der auch die erforderlichen Kenntnisse mitbringt.
    Was den Aufwand wieder erhöht.



  • Von was für einer Komplexität reden wir hier überhaupt? Wieviele LOC VBA sind das? Vielleicht ist ja alles eigentlich relativ harmlos.



  • hustbaer schrieb:

    Excel ist ein nettes Spielzeug, mit dem man innerhalb von sehr engen Grenzen schnell was zusammenfummeln kann.
    Wenn die komplexität der Aufgabenstellung steigt, stösst man mit Excel allerdings sehr schnell an bestimmte Grenzen, und der Aufwand steigt exponential.

    Was für dich "sehr enge" Grenzen sind, ist für uns/mich doch ein größerer Bereich, wo wir uns Bewegen können. Hängt aber auch damit zusammen, daß wir die Daten immer irgendwie in einer Tabellen- oder Rasterform dargestellt brauchen, und dafür eignet sich Excel sehr gut.
    Möchte ich Wasserwellen in einem Schwimmbecken simulieren, werde ich mit Excel nicht weit kommen.

    hustbaer schrieb:

    Äh, ja, was davon war dir jetzt nicht von Anfang an klar?

    Ich wollte diesen Fakt nur von anderer Seite bestätigt haben; hätte ja sein können daß es dafür irgendwelche gebräuchlichen Strukturen gibt, die mir nicht bekannt sind.

    Dokumentation ist gut, aber wenn niemand da, der mit "Cells(y,x)=a" etwas anfangen kann, ist eine Dokumentation ziemlich sinnlos.

    Dobi schrieb:

    Von was für einer Komplexität reden wir hier überhaupt? Wieviele LOC VBA sind das? Vielleicht ist ja alles eigentlich relativ harmlos.

    Beispiel für ein einfaches Projekt: (etwa 100 Zeilen)
    Eine CSV-Datei wird von Excel automatisch importiert, und deren Daten in einer für uns gut lesbaren Form umgewandelt. Wegen dem komplexeren Regelwerk reichen die Excel-eigenen Umwandlungs- oder Filterfunktionen hierfür aber nicht aus; dafür gibt es dann den VBA-Code.

    Beispiel für ein mitteleres Projekt: (etwa 300 Zeilen)
    40 Autos und 40 Funkgeräte sind täglich an die anwesenden Mitarbeiter zu verteilen. Ein Auto und ein Funkgerät ist grundsätzlich immer 2 Mitarbeitern zugeordnet. Dabei soll jeder möglichst sein "Stamm"-Auto und -Funkgerät erhalten. Dazu muß das Programm die Arbeitszeit eines jeden kennen (wird automatisch aus einer anderen Tabelle geholt). Es gibt fälle, wo sich beide Mitarbeiter am gleichen Tag nicht sehen (Früh- und Spätdienst), daher können beide "ihr" Auto und Funkgerät bekommen. Der Rest bekommt irgendein Auto.

    Beispiel für ein schwieriges Projekt: (3000 Zeilen)
    Mein Dienstplanprogramm für bis zu knapp 200 Mitarbeiter. Es würde den Rahmen dieses Posts sprengen, wenn ich hier alle Features aufliste und erkläre.

    Mit diesem Projekt habe ich defacto die Grenzen von Excel erreicht; für weiterführende Funktionen bräuchte ich eine Datenbank im Hintergrund, wobei ich Access aber vermeiden möchte. Das Projekt würde dann zu komplex werden um es nebenbei zu betreuen, und es gäbe nur mich, der sich damit im Detail auskennt. Und genau dieses Projekt war der Grund warum ich diesen Thread eröffnet habe.



  • Fletcher schrieb:

    Beispiel für ein schwieriges Projekt: (3000 Zeilen)

    Ja und? 😕 3000 Zeilen (LOC) waren einst in Lochkarten gerade einmal 2 Kästen gewesen. Für viele doch eher ein kleines Projekt. 🕶



  • Ja, für einen hauptberuflichen Programmierer ist sowas ein kleines Projekt. Lies dir den Thread nocheinmal durch und schau unter welchen Umständen die 3000 LOC in meinem Fall entstanden sind. 🙄

    Um dich zu beeindrucken müßte ich wahrscheinlich mindestens ein Windows 7 programmieren, von dem gesagt wird, daß es aus 40 Mio LOC besteht.

    Ich glaube, daß wenn man den VBA-Code in Maschinensprache umwandeln würde, deutlich mehr als 2 Kästen mit Lochkarten herauskommen würden. Manche VBA-Befehle lassen im Hintergrund 2 verschachtelte For-Schleifen ablaufen wie z.B. vxA=Range("B1:AD175"), wenn "vxA" vom Typ Variant ist. Mit diesem kleinen Befehl wird ein zweidimensionaler Bereich am Excel-Blatt auf einen Rutsch in ein zweidimensionales Array im Arbeitsspeicher eingelesen.
    Die Profis hier können mir ja den entsprechenden C++ Code dafür zeigen, denn lernen muß ich es eh noch 😉 , und dann dürfen sie sich noch die Köpfe einschlagen, ob ausreichende Vorkehrungen für Buffer-Overruns getroffen wurden, und ob der Code gut lesbar ist....



  • Sagen wir es doch einfach anders: Da hat jemand einen 1,5 Tonner Kleintransporter und macht damit erfolgreich Umzüge in seiner Stadt. Nun stösst er damit bei einigen Kunden auf seine Grenzen. Was macht er? Grösseres Fahrzeug anschaffen, LKW-Führerschein machen, Hebehilfen kaufen, Kooperationen suchen, etc. Du hast in unternehmerischer Richtung gefragt - was hier selten ist. Ich fürchte aber, dir fehlt dafür doch einiges. Wenn man mit etwas auf Grenzen stösst, sucht man etwas anderes leichteres! Proggen ist und bleibt: Mit den richtigen Werkzeugen bei geringstem Einsatz das bestmögliche Ziel anzustreben - sicher und auch zukunftsfähig. 🤡
    daddeldu! 🙂



  • Fletcher schrieb:

    hustbaer schrieb:

    Excel ist ein nettes Spielzeug, mit dem man innerhalb von sehr engen Grenzen schnell was zusammenfummeln kann.
    Wenn die komplexität der Aufgabenstellung steigt, stösst man mit Excel allerdings sehr schnell an bestimmte Grenzen, und der Aufwand steigt exponential.

    Was für dich "sehr enge" Grenzen sind, ist für uns/mich doch ein größerer Bereich, wo wir uns Bewegen können. Hängt aber auch damit zusammen, daß wir die Daten immer irgendwie in einer Tabellen- oder Rasterform dargestellt brauchen, und dafür eignet sich Excel sehr gut.

    Nein.
    Das ist oft falsch verstanden. Excel ist fuer sowas ungeeignet. Natuerlich kann man es dazu vergewaltigen, keine Frage - das ist sehr beliebt.

    Aber eine Datenbank im Hintergrund ist soviel maechtiger, schneller und klarer. Und vorallem: leichter aenderbar.

    Excel-Insel-Loesungen sind neben Access-Insel-Loesungen wohl die schlimmsten Probleme...

    Wir haben auch solche Insel-Loesungen bei uns in der Firma und wir arbeiten hart daran die wegzubekommen. Weil es einfach ein Zustand ist...



  • Diese Aussagen, dass XYZ das entwickelt hat und man sich nicht damit auskennt, sind doch meistens nur Ausreden dafür, dass man sich nicht um etwas kümmern will.



  • @berniebutt: Guter Vergleich. Ja, ich bin erfolgreich mit meinem 1,5 Tonner. Für meinen potentiellen nächsten Auftrag würde ich einen 7,5 Tonner brauchen. Das zahlt sich nur aus wenn ich ihn immer wieder brauchen werde - sprich ich müßte, um das zu programmieren, hauptberuflich dafür abgestellt werden. Es geht nicht einmal darum, ob ich es kann - ich würde nämlich sagen JA - sondern um das Problem der Personenabhängigkeit der sich die Firma dann aussetzt; und genau diese Problematik diskutieren wir hier in diesem Thread.

    Die Ergebnisse lauten inzwischen: 1) Die Firma läßt noch zwei weitere Leute daran mitarbeiten. 2) Man kauft externe Software von einer Firma die nicht zu klein ist. 3) Die Firma geht das Risiko ein, hat aber eine Rückfallebene.

    Shade Of Mine schrieb:

    Excel ist fuer sowas ungeeignet. Natuerlich kann man es dazu vergewaltigen, keine Frage - das ist sehr beliebt.

    Es ist deswegen so beliebt, weil es sich doch besser dafür eignet als DU es glaubst. Eine hübsche sexy Frau wird eben eher vergewaltigt als eine Baustellen-Olga.

    Aber eine Datenbank im Hintergrund ist soviel maechtiger, schneller und klarer. Und vorallem: leichter aenderbar.

    Deswegen möchte ich im nächsten Schritt auf eine Datenbank umschwenken; diese (und den Rest drumherum) zu erstellen ist aber ein großer Aufwand. Die Zeit dafür will mir meine Firma (noch) nicht zugestehen.

    Excel-Insel-Loesungen sind neben Access-Insel-Loesungen wohl die schlimmsten Probleme...

    Versuche das Problem mit Papier und Bleistift zu lösen - wenn es dann einfacher geht, dann - und nur dann - handelt es sich um eine schlimme Insellösung.
    Irgendwo ist alles eine Insellösung. Windows ist auch nur eine Insel, ich habe aber gehört daß es noch einen anderen Kontinent gibt wo lauter Appleianer leben....



  • Fletcher schrieb:

    Shade Of Mine schrieb:

    Excel ist fuer sowas ungeeignet. Natuerlich kann man es dazu vergewaltigen, keine Frage - das ist sehr beliebt.

    Es ist deswegen so beliebt, weil es sich doch besser dafür eignet als DU es glaubst.

    Ich denke eher, dass für viele Leute alles nach Nagel aussieht wenn ein Hammer das einzige Werkzeug ist, dass sie schonmal benutzt haben. 😉



  • Fletcher schrieb:

    Es ist deswegen so beliebt, weil es sich doch besser dafür eignet als DU es glaubst. Eine hübsche sexy Frau wird eben eher vergewaltigt als eine Baustellen-Olga.

    Nope.
    Alleine die Vergwaltigungsaussage ist schwachsinn.

    Aber eine Datenbank im Hintergrund ist soviel maechtiger, schneller und klarer. Und vorallem: leichter aenderbar.

    Deswegen möchte ich im nächsten Schritt auf eine Datenbank umschwenken; diese (und den Rest drumherum) zu erstellen ist aber ein großer Aufwand. Die Zeit dafür will mir meine Firma (noch) nicht zugestehen.

    Es geht ja auch nicht gut. Du musst deinen Code wegschmeissen. Das ist ein weiterer Punkt warum Excel hier vollkommen ungeeignet war.

    Versuche das Problem mit Papier und Bleistift zu lösen - wenn es dann einfacher geht, dann - und nur dann - handelt es sich um eine schlimme Insellösung.
    Irgendwo ist alles eine Insellösung. Windows ist auch nur eine Insel, ich habe aber gehört daß es noch einen anderen Kontinent gibt wo lauter Appleianer leben....

    Nein, das ist wieder schwachsinn.

    Hoer bitte einfach auf deinen chef.



  • Irgendwie grotesk: Ich schreibe, daß wir uns seit über 10 Jahren das Arbeitsleben erleichtern indem wir/ich VBA-Programme schreiben. Dann kommen hier Leute mit dem erhobenen Zeigefinger und sagen "Excel ist dafür nicht geeignet." Wenn es so ungeeignet wäre, würde die Leute Excel nicht einmal anschauen!

    Viele Excel-Dateien existierten bereits in ihrer Grundform, als ich dort noch gar nicht angestellt war, also ab Mitte der 90er. Zu der Zeit wurde alles noch mit Formeln gemacht. Damals gab's auch nur die alte Makro-"Sprache", denn VBA kam erst 1997.
    Mit der Zeit wurde mehr und mehr automatisiert, bis ich schließlich loslegte und kleine Programme daraus wurden.

    Unabhängig davon on Excel jetzt geeignet ist oder nicht: Es handelt sich um PC-Arbeitsplätze die unsere IT-Abteilung einrichtet, und das einzige wo wir was programmieren können ist innerhalb des Microsoft Office-Enterprise-Pakets.


Anmelden zum Antworten