Personenabhängigkeit bei selbstgeschriebenen Programmen
-
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.
-
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.
