Personenabhängigkeit bei selbstgeschriebenen Programmen
-
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.
-
Fletcher schrieb:
Können die Kritiker ähnliche Erfolge vorweisen wie "GanzEhrlich"? Falls nicht gibt es dafür einen Ausdruck: "Bulls without Balls"!
Ja. Wir ersetzen regelmäßig Excel kack durch sinnvolle Sachen - oft gehen die Sachen ja direkt mit den bestehenden Tools bereits, die Leute wussten es nur nicht - oder es gibt triviale fertig Lösungen.
Wir vernichten einige Excel Kacke pro Jahr. Leider entdeckt man nicht alles, weil die Leute sich da nicht zwischenreden lassen wollen. Es ist aber nicht nur Excel - es gibt alles mögliche dass missbraucht wird.
Wir haben auch Access Datenbanken die seit >10 Jahren gewachsen sind - die werden wir wohl nie rausbekommen. Dort ist die Argumentation exakt gleich wie deine. Aber was dort schon an Mannstunden reigeflossen sind, dafür hätte ich einen Programmierer 2 Jahre fix anstellen können...
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.
Du verkennst, wie immer, die Situation.
Das was du hier schreibst - sowas sehe ich sicher 3-4 mal pro Jahr. Und meine Erfahrung sagt mir: sowas gehört im Keim erstickt. Denn wenn so eine Pfusch-Lösung zu lange am Leben bleibt, dann wird sie zu einer Krake die unmöglich zu entfernen ist und alles beeinflusst.
Nochmals: ich sehe sowas oft. Und ich sehe es leider auch öfters sich entfalten und dann werden 2 Mann Monate in irgendwelchen Scheiß vergeudet wird und man es 1-2 Jahre später wieder wegschmeissen muss weil es unwartbar ist oder aber man schleppt es ein Leben lang mit und bekommt es nie wieder aus dem Unternehmen raus...
Was ich da schon alles gesehen habe - meistens mit Access, weil Excel nicht fähig genug ist, dass damit unersetzbare Software geschrieben werden kann - unglaublich. Und die Folgekosten sind horrend...
Excel Listen sind idR leicht zu ersetzen, da idR nur bestehende Sachen wie Projetkplanungstools oder Zeitplanungstools gebaut werden - die man einfach durch fertige Stock-Software ersetzen kann.
Einmal haben wir eine Excel Liste durch einen Kalender in unserer Groupware ersetzt... Hat 2 Manntage pro Monat eingespart...
-
Fletcher schrieb:
@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;
...
Fletcher schrieb:
@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!
Also was jetzt? Entscheide dich mal. Oder trollst du hier nur blöd rum?
ps: Und nein, ich meinte schon das Framework. Dass es möglich ist auf den paar wenigen Entwickler PCs Visual Studio installiert zu bekommen setze ich mal voraus. Denn wenn es sogar schon daran scheitert, dann kann die Firma vermutlich sowieso bald einpacken.
-
@Shade Of Mine: Also solche Probleme haben wir nicht. Vielleicht auch deswegen, weil wir es bisher nicht so weit getrieben haben, daß eines unserer Tools zu einer "Krake" wird.
Ein paar Tools sind in den letzten Jahren überflüssig geworden, weil sich der Geschäftsprozeß verändert hat und es nicht mehr gebraucht wurde. Diese Programme wanderten ins Archiv-Verzeichnis.
Projekt- oder Zeitplanungstools würde ich auch nicht mit Excel machen wollen, weil es sicher Standardsoftware dafür gibt; aber für das was wir brauchen, gibt es keine Standardsoftware.Bezüglich der Entwicklungskosten: In mein größtes Projekt (Dienstplan), sind in den 13 Jahren seines Bestehens höchstens 4 Mann-Monate hineingeflossen - hält sich also wirklich in Grenzen.
Wenn mir jemand sagt, daß er auch gerne dies und das in Excel automatisiert haben möchte, sage ich immer, daß vom unternehmerischen Standpunkt her die investierte Programmierarbeit sich nach 1 Jahr rentiert haben sollte. Wenn Zweifel bestehen, ob das Programm in 1 Jahr noch gebraucht wird, sollte man gleich gar nicht damit anfangen.
Ich hatte auch schon den Fall, daß ich etwas automatisieren sollte, das Regelwerk aber dann so komplex war und sich ständig änderte, daß ich sagte: Wir sollten das in dem Fall gar nicht mit dem Computer machen, sondern "schmiere" händisch mit dem Kugelschreiber auf den Zetteln herum.hustbaer schrieb:
Also was jetzt? Entscheide dich mal. Oder trollst du hier nur blöd rum?
(Seufz). Wir haben nur Excel-VBA zum Programmieren, und selbst wenn ich etwas anders zur Verfügung hätte, würde ich es trotzdem in Excel machen wollen, weil ich mich dort auskenne und unterm Strich am schnellsten zu einem Ergebnis komme. Bin ich der Meinung das Excel für einen bestimmten Fall nicht geeignet ist, werde ich es ohnehin kundtun und versuchen es auf eine andere Art zu lösen. Das kann auch eine Nicht-Computer-Lösung sein. Ich programmiere den Kübel zwar gerne, aber ich muß nicht alles mit Gewalt in die Bits-und-Bytes Welt hineinpressen.
hustbaer schrieb:
...denn wenn es sogar schon daran scheitert, dann kann die Firma vermutlich sowieso bald einpacken.
Hast grundsätzlich recht, aber bei unserer Firma handelt es sich um einen Ex-Monopol-Betrieb der aus den Kriegshandlungen des WK2 hervorgegangen ist und möglicherweise auch die Kriegshandlungen des WK3 erleben wird. (noch dieses Jahrzehnt?)
Daß so eine Firma wirklich einmal einpackt ist eher unwahrscheinlich.
