Personenabhängigkeit bei selbstgeschriebenen Programmen
-
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.
-
Fletcher schrieb:
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!
Mit dem, was ich gleich schreibe, will ich nicht sagen, dass Excel ungeeignet ist für das, was tu machst, sondern nur die Argumentationsweise kritisieren.
Also, bei uns in der Firma wurde eigentlich nur in C++ programmiert (viel Bilderkennungskram usw., egal). Dann fing es bei mir an, dass ich hin und wieder kleine Wegwerfprogramme schrieb, um bestimmte statistische Daten aus Log-Files rauszuparsen und manchmal graphisch darzustellen. Anfangs hab ich das noch in C++ gemacht, weils halt da war und ich es konnte. Hat das Arbeitsleben auch erleichtert, weil es viel schneller ging als per Hand. Das hat aber nicht bedeutet, dass C++ wirklich toll dafür geeignet war. Mitlerweile mach ich sowas in Python und bin damit wesentlich effizienter. Das war das, was ich mit Hammer und Nägeln meinte.
-
Fletcher schrieb:
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."
Jetzt nicht auf deine konkrete Situation bezogen... Excel wird oft eingesetzt, wo es nicht wirklich Sinn macht und wo die Leute gar nicht wissen, wie man das anders machen könnte. In meiner alten Firma haben wir z.B. ab und zu Warenwirtschaftssysteme in Firmen eingeführt, die davor mit Excel gearbeitet haben. Und das waren keine 2 Mann Firmen, sondern mittelständische Unternehmen. Da wurden zehntausende Kunden und Produkte von Hand in Excel gepflegt, dann lauter Rechnungen, Lieferscheine usw. von Hand in Word geschrieben, Stornierungen usw. auch irgendwie über Dateisystem + Excel verwaltet, und dann natürlich irgendwelche Statistiken in Excel erstellt. Wofür Excel an sich schon zu gebrauchen wäre, wenn das ganze System nicht so ein Chaos gewesen wäre, das mit Excel nicht in den Griff bekommt. Dann nimmt mal halt ein ERP-System (muss nicht SAP sein, da gibts etliche kleinere), und dann geht sehr vieles plötzlich automatisch und geordnet und man bekommt noch viele Funktionen dazu, an die man gar nicht gedacht hätte, und dann kann man auch anfangen, das ERP System mit anderen Systemen zu integrieren, was mit Excel quasi unmöglich gewesen wäre. Deswegen ist denke ich schon eine gewisse Skepsis angebracht, wenn jemand von irgendwelchen komplexeren Lösungen in Excel erzählt.
-
Fletcher schrieb:
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.
Ich kann mir kaum eine Firma vorstellen, wo es nicht möglich wäre das .NET Framework oder ein Java SDK installiert zu bekommen, wenn es ein Abteilungsleiter anfordert.
Und mehr braucht man für .NET Zeugs nicht wirklich.
Ggf. noch einen Datenbank-Server irgendwo im Netz. Wobei theoretisch auch mit JET/SQLCE/SQLite Datenbanken auf ner File-Share arbeiten kann so lange das Datenvolumen und die durchzuführenden Abfragen ausreichend klein/wenig aufwendig bleiben.
Wenn man mit SQLCE anfängt kann man sogar ziemlich problemlos auf SQL Server Express (oder sogar eine "grössere" SQL Server Version) umsteigen (verwenden beide T-SQL, SQLCE kann nur viel weniger als der "echte" SQL Server).Die Anwendung liegt dabei einfach als .exe File irgendwo, und wird von dort gestartet. Genau so wie das Excel File irgendwo liegen muss von wo man es startet.
----
Bitte glaube mir einfach wenn ich dir sage: sich von unvernünftigen Einschränkungen einschränken zu lassen ist ganz grosser Topfen. Ich habe damit ein wenig Erfahung, und weiss wie viel Zeit und Produktivität man damit vernichten kann. Und die Einschränkung "wir können nix installieren" ist - in dieser absoluten Form - total unvernünftig.
Klar muss man aufpassen dass das ganze nicht "ausufert" - dass man nicht irgendwann 100 verschiedene Tools brauch, vielleicht noch in speziellen Versionen und mit zig PATH Einträgen und was nicht noch alles, nur damit irgend ein Stück in-house Software läuft.
Das Installieren des .NET Framework als "no-go" zu behandeln ist aber in den allermeisten Fällen einfach nur Quatsch.
----
Es ist auch nicht so, dass wir dir hier einreden wollen du müsstest irgendwas auf eine bestimmte Art und Weise machen. Nur deine Gegenargumente/Begründungen/Vorstellungen von bestimmten Technologien etc. sind oft einfach vollkommener Quatsch. Und darauf weist man dann halt mal hin.
-
@Dobi: Siehst du, du hast ein paar Kleinprogramme mit C++ gemacht, weil das für dich offenbar der schnellste Weg war; Phyton hättest du dir wahrscheinlich damals erst selbst lernen müssen. Bei mir ist es ähnlich: ich benutze manchmal Excel als Host für VBA, für Dinge die in Excel definitiv nicht reinpassen, ABER unterm Strich ist es für mich die Lösung wo ich am schnellsten zum Ziel gelange.
@Mechanics: Also dieses Warenwirtschaftssystem hätte ich auch nicht mit Excel realisieren wollen; mindestens mit Access (ich höre jetzt viele Leute schreien) , aber man muß sich auch über die Limits von Access bewußt sein. Nimmt man SQL Server Express, muß man wiederum das Frontend selbst zusammenzimmern.
Der ewige Vergleich "Access" vs "SQL Server" ist aber unfair, denn das eine ist eine passive Datei, das andere ein aktiver "Bibliothekar" der einen niemals direkt zu den Büchern läßt, sondern Werte immer nur selbst schreibt und liest.@hustbaer: Das .NET-Framework ist inzwischen bei jedem Windows dabei, ich denke du meintest die Entwicklungsumgebung für die beiden NET-Sprachen VB und C#. Daß die beiden Sprachen, nach Aufforderung eines großen Abteilungsleiters, nachinstalliert werden, wäre sogar bei uns vorstellbar; Aber in unserem speziellen Fall, gibt es nur 1 Mitarbeiter (mich) der damit umgehen können würde. Und somit landen wir wieder beim 1.Posting dieses Threads wegen der Personenabhängigkeit.
Für mein "7,5 Tonnen"-Projekt würde mich die Combo "VB.NET" mit Oracle-Datenbank tatsächlich reizen; aber hierfür muß unser Direktor von sich aus sagen, daß er das Ein-Personen-Risiko in Kauf nimmt.Kleiner Hinweis an alle: Die ursprüngliche Problematik der Personenabhängigkeit wurde ein paar Posts weiter oben schon geklärt; Wunderlösung gibt es aber keine.
-
Fletcher schrieb:
Also dieses Warenwirtschaftssystem hätte ich auch nicht mit Excel realisieren wollen; mindestens mit Access [i]
ERP ist viel mehr als nur die Datenbank, in so einem durchschnittlichen System werden auch dutzende Mannjahre Arbeit stecken. Ich würde sowas überhaupt nicht selber basteln wollen, sondern was fertiges nehmen
Auf dem System kann man dann allerdings meist recht einfach eigene Anpassungen und Plugins aufbauen.Fletcher schrieb:
Für mein "7,5 Tonnen"-Projekt würde mich die Combo "VB.NET" mit Oracle-Datenbank tatsächlich reizen; aber hierfür muß unser Direktor von sich aus sagen, daß er das Ein-Personen-Risiko in Kauf nimmt.
So gravierend seh ich das Problem jetzt in dem Fall allerdings nicht. Du bist vielleicht der einzige in eurer Abteilung, der das Projekt warten könnte, aber das heißt nicht, dass du der einzige Mensch auf der Welt bist, der sich da reindenken könnte. Wenn das dann wichtig genug ist, müsste es eben einer aus der Entwicklungsabteilung übernehmen. Bei so kleinen Projekten ist es doch überhaupt kein Problem, sich da reinzudenken. So arg viel wird es nicht können und die fachlichen Anforderungen kann man dann mit deinen Kollegen absprechen.
Es ist doch nicht ungewöhnlich, dass man fremden Code übernehmen muss. Und dann kommen meist schon am nächsten Tag die Beschwerden, was man da für einen Scheiß programmiert hat, obwohl die Leute eigentlich wissen, dass man das Projekt nicht geschrieben hat und noch fast gar nicht kennt
-
Fletcher schrieb:
@Dobi: Siehst du, du hast ein paar Kleinprogramme mit C++ gemacht, weil das für dich offenbar der schnellste Weg war; Phyton hättest du dir wahrscheinlich damals erst selbst lernen müssen. Bei mir ist es ähnlich: ich benutze manchmal Excel als Host für VBA, für Dinge die in Excel definitiv nicht reinpassen, ABER unterm Strich ist es für mich die Lösung wo ich am schnellsten zum Ziel gelange.
Der kurzfristig schnellste (preiswerteste) Weg kann langfristig halt manchmal der teuerste weg werden. Die Kunst ist halt, sich zu überwinden, und dann doch mal umzuschwenken, auch wenn es bedeutet, für sich selbst zugeben zu müssen, dass man es besser von Anfang an so gemacht hätte. So schlimm ist das aber gar nicht wenn man merkt, dass man damit keinen wirklichen Fehler zugibt, sondern die Entscheidung damals richtig war, weil es sich nicht abzeichnete, dass das so ein großes Ding wird. Wenn man dann überlegt, ob sich der Schwenk lohnt, muss man nur noch aufpassen, nicht der sunk cost fallacy zu unterliegen.
-
Auch wenn meine Meinung niemend hören will... Die ganze Diskussion über das Thema: "eigene IT für Kleinkram" finde ich überflüssig...
Bin selbst vor ein Paar Jahren in derselben Situation gewesen... Da hieß es dann Monopol-Wissen, und was ist wenn...
Angefangen hat es bei mir mit einem, wirklich unbedeutendem PiPi-Makro - ein Drei-Zeiler, wie man so schön sagt. Es tut nichts weiter, als die Zwischenablage von Windows über Forms-Objekt auszulesen, den Inhalt auszuwerten, und in einer Tabelle (eine Zeile, 4 Spalten) darzustellen... Und dafür habe ich meine ganze Mittagspause geopfert
Was danach kam, ist echt ein Abenteuer... Im Ernst, ich habe damit nicht gerechten: Das Makro hat beinah wie eine Bombe eingeschlagen
Es ging dann los mit Kleinkram, mach dies, mach das, und wie kann man ein Wordbrief opimieren oder Statistik usw. Alles kein Problem, in null komma nichts erledigt. Am ende hat die Sekretärin die ganze Statistik gemacht...
Und nebenbei, das Hauptprojekt: die E-Planung. War vor mir alles in Excel gelöst. Mehrere Tabelle, alles Verknüpfen, auswerten usw... Als Mittel hatte ich selbstverständlich auch nur Excel (noch 97).
Irgendwann hat der Chef dann mitbekommen, dass es nicht mehr Kleinkram ist (nicht alles ist einfach, was einfach aussieht), Und es ging dann los: "Machen Sie bloß nichts, was wir hierterher nicht mehr nutzten können. Was ist, wenn Sie morgen nicht da sind?"
Leider zu spät... Das Projekt war bereits im Gange... Die Auswirkungen waren deutlich sichtbar: die tel. Erreichbarkeit der Abteilung hat sich stabilisiert (vorher 10-20%, nachher 80-90%). Immer hin...
Bis dahin waren es 5 Monate vergangen... Danach konnte ich die Situation leider nur noch zu meinen Gunsten ausnutzen. Excel war bereits an seinen Grenzen (nur noch Dr. Watson)... Zum Gluck habe ich dann auf dem Rechner Perl entteckt (muss wohl ein Relikt sein, dachte ich). Und was mache ich? War ja klar: Perl-Tk und ODBC. Habe meine Kontakte mit BO ausgenutzt und mir eine MS-Sql DB angeschafft...
Zum Schluß hatte ich auf die beine gestellt: eine vollwertige (oder heißt es interaktive?) Oberfläche mit einer Datenbank als Backend (Datenvolumen um etwa 1/2 Mio. Datensätze pro Tag). Das Ganze in ca. 2 Jahren auf "learning by doing"-Basis...
Und was hat das ganze gebracht? Nichts! Der Chef hat erreicht, was er befürchtet hat... Ich musste aufgeben, weil die ganze Situation unerträglich wurde. Es war nichts mehr zu retten...
Fazit: Aus meiner Erfahrung kann ich nur berichten, dass es sich oft nicht lohnt IT-Spezis anzuheuern. Erstens: dauert zu lange und Zweitens: warum viel Geld ausgeben, wo es billiger geht.
Um das Problem auf lange Sicht zu lösen, einfach mal aktiv nach Leuten suchen, die VBA können - das reicht alle mal für den Anfang aus. Wer ausfällt, wird einfach ersetzt. So schwierig ist Programmieren nun auch wieder nicht - und schon gar nicht in VBA.
-
Fletcher schrieb:
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!
Die Pyramiden wurden auch ohne maschinelle Hilfsmittel gebaut und trotzdem wäre für ein heutiges vergleichbares Projekt die reine Muskelkraft nicht mehr das dafür geeignete Mittel.
Also hör auf hier zu Jammern, Excel nimmt man dafür nicht.
-
GanzEhrlich schrieb:
Aus meiner Erfahrung kann ich nur berichten, dass es sich oft nicht lohnt IT-Spezis anzuheuern. Erstens: dauert zu lange und Zweitens: warum viel Geld ausgeben, wo es billiger geht.
Gratuliere zu deinen Erfolgen im Bereich der Eigenprogrammierung "GanzEhrlich"!
Daß die telefonische Erreichbarkeit von 20% auf 80% erhöht werden konnte spricht für sich: Einwürfe wie "Excel ist dafür nicht geeignet" oder "Der Programmierstil läßt zu wünschen übrig" sind in dem Fall vollkommen überflüssig. Können die Kritiker ähnliche Erfolge vorweisen wie "GanzEhrlich"? Falls nicht gibt es dafür einen Ausdruck: "Bulls without Balls"!Wie man sieht, bist du aber genau an dem gleichen Punkt gelandet wo ich jetzt bin: Die Größe des nächsten Projekts nimmt Dimensionen an, bei er es für die Firma gefährlich werden kann, wenn das Programm einmal nicht funktioniert und niemand da ist, der sich damit auskennt.
Man muß die Ein-Personen-Problematik mit dem Chef besprechen: Gibt es keine Lösung dafür, muß man ab einer bestimmten Projektgröße die Weiterentwicklung stoppen; auch wenn einen die Kollegen ermuntern damit weiterzumachen.@Vendor Lock-In: Wie schon ein paar Posts vorher erläutert, stellt sich die Frage nicht, ob man jetzt Excel dafür nimmt oder nicht: Wir haben nichts anderes!
Wie kannst du das außerdem so bestimmt sagen, wo du das konkrete Programm/Tool noch gar nicht gesehen hast.Allgemein kommt es mir hier so vor, daß sich unter den Forenmitgliedern zwar viele "richtige" IT-Profis tummeln mögen, diese aber ihre Felle davonschwimmen sehen, wenn sie merken daß ihnen ein paar "Cowboy-Programmierer" das Wasser abgraben, was deren Freelancertum oder Selbstständigkeit gefährdet. Genau aus diesem Grund habe ich keinen eigenen "Laden" aufgemacht, wie es zuvor schon jemand gepostet hat.
