Personenabhängigkeit bei selbstgeschriebenen Programmen
-
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.
-
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.
Ja ja, wer im Glashaus sitzt, sollte nicht mir Steinen werfen...Also ich, als Info Fachidiot, neige dazu eine Kampf gegen schlechten Programmierstil, mangelnde Doku aufzunehmen, nach mir die Sinnflut Mentalität aufzunehmen. Und meistens waren es Leute, die es nicht besser wussten.
Ob es nun einfach fachfremden Personen sind, oder Akademiker, vvermag ich nicht zu sagen. Aber mir wäre es lieber wenn ein paar (relativ junge) Leute von der Uni den Code entwickeln, denn denen wurde Projektentwicklung eingebleut.
-
Aber mir wäre es lieber wenn ein paar (relativ junge) Leute von der Uni den Code entwickeln, denn denen wurde Projektentwicklung eingebleut.
Aber diese (junge) Leute von der Uni, werden vermutlich nicht in so einer Firma sich blicken lassen :p
Es geht hier mehr darum, in einer Arbeitsumgebung ohne diese Spezialisten (die zu teuer und zu lahm sind) klar zu kommen. Hier müssen keine [Schwergeschütze] für die Nachwelt etwickelt werden. Das Problem hier ist, wenn plötzlich keiner da ist, der simplen Makro-Code verstehen kann.
Also ich, als Info Fachidiot, neige dazu eine Kampf gegen schlechten Programmierstil, mangelnde Doku aufzunehmen, nach mir die Sinnflut Mentalität aufzunehmen. Und meistens waren es Leute, die es nicht besser wussten.
Oft sind es welche, die gerade rausgefunden haben, wie ein Makro-Befehl ausgeführt wird - und schon laufen sie rum, als wären sie gerade in die höhere Liga aufgestiegen. Da ist es auch selbstverständlich, dass man Code schreibt ohne Kommentare und ohne vernünftigen Konzept dahinter. Man will ja nicht, dass jemand dahinter kommt und womöglich schneller ist
Nach einer gewissen Erfahrung, kommentiert man sein Code nebenbei, um sich selbst nicht die Steine in den Weg zu legen. Verliert man die Übersicht, bedient man sich Struktur-Diagrammen usw.
Und noch mal, hier werden Projekte angesprochen, die nicht der Aufmerksamkeit von Fach-IT-Informatiker bedürftig sind, oder sehe ich das falsch
-
GanzEhrlich schrieb:
Aber diese (junge) Leute von der Uni, werden vermutlich nicht in so einer Firma sich blicken lassen
Sie fangen schon oft in einer großkopferten Firma an, gehen aber nach 1-2 Jahren wieder weil sie sich aufgrund der Hausbräuche in solchen Firmen stark eingeengt fühlen und nicht so entfalten können wie sie sich das vorgestellt haben.
GanzEhrlich schrieb:
Es geht hier mehr darum, in einer Arbeitsumgebung ohne diese Spezialisten (die zu teuer und zu lahm sind) klar zu kommen. Hier müssen keine [Schwergeschütze] für die Nachwelt etwickelt werden. Das Problem hier ist, wenn plötzlich keiner da ist, der simplen Makro-Code verstehen kann.
Ganz genau!
GanzEhrlich schrieb:
Und noch mal, hier werden Projekte angesprochen, die nicht der Aufmerksamkeit von Fach-IT-Informatiker bedürftig sind, oder sehe ich das falsch
Fast. Hier werden Projekte angesprochen, die ganz knapp davor sind diese Schwelle zu überschreiten. Ist diese Schwelle überschritten, ist aber das Problem der Personenabhängigkeit bereits schwerwiegender als die fachlich richtige Programmierung. Deshalb gibt es diesen Thread hier, denn bevor die Personenproblematik nicht gelöst ist, braucht man keine Diskussionen führen wegen z.B.: Quicksort vs. Heapsort, geschweige denn Bubblesort.
-
Fast. Hier werden Projekte angesprochen, die ganz knapp davor sind diese Schwelle zu überschreiten. Ist diese Schwelle überschritten, ist aber das Problem der Personenabhängigkeit bereits schwerwiegender als die fachlich richtige Programmierung.
Also, wenn du mich fragst, bist du hier der Einzelfall. Ich war schon mal in so einigen Firmen tätig, wo einige "möchtegern Spezis" sitzen, und sich wehement dagegen wehre, wenn mal Einer so "1x1-Klug" deren Position streitig machen wollen...
Wenn du dir wirklich sicher bist, in der Lage zu sein das Projekt allein durchziehen zu können, dann mach es einfach. Nutze die Gelegenheit... Erfahrungsgemäß wird Keiner der Unternehmens-Vorstandäde was dagegen haben, wenn du eine effektive Lösung bieten kannst (idR. gehen sollche Projekte kostenmäßig in den 100 Tsd. Bereich).
Wenn ich dein Chef wäre, würde ich auf keinen Fall verkneifen. Ob dann noch Personal langfristig fehlt - sei zunächst mal dahin gestellt. Zur Not wirst du halt nebenbei auch eine Not-Lösung schaffen müssen :p
-
GanzEhrlich schrieb:
Wenn du dir wirklich sicher bist, in der Lage zu sein das Projekt allein durchziehen zu können, dann mach es einfach. Nutze die Gelegenheit...
Um es durchziehen zu können müßte mich mein großer Chef 1 Jahr von der regulären Arbeit freistellen bzw. gleich einen Planposten für mich schaffen. Das tut er momentan aber nicht, somit habe ich einfach keine Gelegenheit um sowas zu machen; und in der Freizeit setz' ich mich sicher nicht hin, mache etwas unbezahlt für die Firma, was dann trotz funktionierens nicht erwünscht ist.
In der Tat gehen solche Projekte in den x00.000 Euro Bereich; aktuell haben wir so eine Ausschreibung laufen und unser großer Chef wartet einmal das Ergebnis ab. Falls es aus irgendeinem Grund nichts wird, werden wir ja sehen wie er weiter entscheidet.
