Personenabhängigkeit bei selbstgeschriebenen Programmen
-
Du hast einige Dinge richtig erkannt!
Bis vor gut 1 Jahr lief in unserer Firma quasi einiges falsch, bis endlich der sesselklebende eigennützige Direktor abgelöst wurde, und auch der lethargische Typ darunter, mein Ex-Chef. Den neuen Chef kenne ich seit 14 Jahren und habe mich schon immer gut mit ihm verstanden. Der neue Direktor ist auch OK, der räumt jetzt den "Müll" der letzen 20 Jahre weg......
Meine "Dienste" wurden damals gerade einmal für das Dienstplanprogramm in Anspruch genommen und das nur zaghaft "Brauchen Sie da eh nicht zu lange dafür?".
Ich habe es deswegen gemacht, weil die Mitarbeiter durch das Programm weitgehend ihre Lieblingsdienste erhalten haben (auch ich), ohne der Firma damit zu schaden.Jetzt mit neuem Chef und Direktor - beide interessieren sich für mein "Know-How" - kommt Schwung in die Bude. Ich habe meinem Chef die 1 Personen-Problematik jedenfalls erläutert, obwohl das gegen mich spricht. Die Lösung ist einfach, daß der Direktor versucht ein professionelles Programm anzuschaffen, das von internen und externen Leuten gewartet wird. Ein dezitiertes Front-End mit RDBMS-Backend.
Geredet wir darüber schon über 1 Jahr; jetzt gerade läuft erst die Ausschreibungsphase. Inzwischen kommt in meiner Abteilung zum 12.Mal in Folge der neue Dienstplan heraus, erstellt mit der neuesten Version meines Programms. Alle sind froh, daß es das gibt, denn sonst wären sie schon verrückt geworden. Es läuft so zuverlässig, daß ich auch 3 Wochen in Urlaub fahren kann, ohne das die etwas von mir brauchen!Es wird sich zeigen, was passiert wenn die Ausschreibung aus irgendeinem Grund ins Wasser fällt, denn es gibt bereits erste Anzeichen daß das passieren könnte........
-
Wenn du keinen offiziellen Auftrag hast etwas zu machen, die Firma eigentlich gar nicht will dass du das machst, deine Stellenbeschreibung es nicht mit einschliesst, deine Ausbildung es nicht abdeckt, du weder von der Firma vorgegebene Prozesse noch offiziell anerkannte Prozesse verwendest um es umzusetzen uswusf. - wie soll man das denn bitte schön sonst nennen?
Nennen wir es Notlösung; aus jener Not heraus, daß kein Geld und keine Zeit da ist um den offiziellen Weg zu gehen. Unserer Abteilung nützt es auf jeden Fall etwas, denn sonst würde mein Chef nicht erlauben daß ich sowas in meiner Normalarbeitszeit erledige.
Meine "Notlösung" ist jedenfalls so gut (ich weiß - Eigenlob), daß wir das SAP nur mehr als Schönschreibheft verwenden - als Pflichteingabe für die endgültige erbrachte Arbeitszeit zwecks Personalverrechnung. Solange im SAP alles richtig drin steht, wird keiner Fragen wie wir zu den Eingaben gekommen sind.
Mein Programm hat auch schon unser Personalcontroller gesehen, und ich habe ihm gesagt, daß die ausgeschriebene Software (um mehrere 100k-Euro!) dieses Tool bzw. "Notlösung", schlagen muß. Er meinte nur "Das ist eine gute Meßlatte!".
-
Ich sehe hier fast einen "Domänenexperte vs. Informatiker Mismatch". Domänenexperten schreiben oft Software, die bis zu einem gewissen grad genau das macht, was sie wollen, und mit der alle in der Abteilung zufrieden sind. Informatiker interessieren sich meist eher für die Architektur und den Stil des Programms, und interessieren sich oft überhaupt nicht für die eigentliche Fachdomäne. Deswegen würden sie zu dem was der Domänenexperte geschrieben hat pauschall "Bullshit" sagen, es komplett neu schreiben, sauberer und eleganter, aber leider aus Sicht des Domänenexperten schlechter, weil sie sich in die Thematik nicht tief genug renkdenken wollten. Auf lange Sicht hingegen sollte die Software des Informatikers so gut wie immer besser sein.
-
Guter Einwurf Mechanics!
Dann bin ich wohl ein "Domänenexperte". Der "Informatiker" paßt zu jenem Typ Professor den ich (leider) an der Schule im EDV-Unterricht hatte: Der interessierte sich kaum dafür, was das Programm genau kann, sondern wollte immer den Code sehen: "Wie haben sie das realisiert?" - "Ist doch Blunzen!" dachte ich mir, es funktioniert, es performt, was gibt's da noch zu fragen?
Etwas selbsterstelltes hat man von ihm natürlich nie gesehen, aber kritisieren konnte er gut. Spiele-Programmierer waren für ihn sowieso das letzte, nur wer sich an Datenbanken ran gewagt hat war für ihn eine Respektperson; so war zumindest seine Denke.Z.B. in MS-Office 97 soll in Excel noch der Bubble-Sort-Algorithmus zur Anwendung gekommen sein! Sowas gibt eine große Softwarefirma heraus?
Im "Notepad" von Windows-XP dürfte auch etwas nicht sauber programmiert gewesen sein: Wenn man Text in großen CSV-Dateien ersetzt hat (z.B. Punkt gegen Komma), stieg die zeitliche Dauer quadratisch mit der Größe der Datei! Auch "sehr professionell". Wie ist das durch die Microsft Qualitätskontrolle gekommen?
Auf lange Sicht hingegen sollte die Software des Informatikers so gut wie immer besser sein.
In dem Bereich wo ich arbeite (Flugzeugabfertigung) gibt es kein "auf lange Sicht" mehr. Ständig kommt aus irgendeiner Ecke (Airlinekunden, Behörden und firmenintern) ein neuer Blödsinn und es ist inzwischen alles so komplex geworden, daß niemand mehr zu 100% durchblickt. Daher stellen wir uns mit "Notlösungen" diesen Problemen entgegen, denn bis wir was offizielles bekommen würden, ist so viel Zeit vergangen, daß wir eventuell das ursprünglich geforderte nicht mehr brauchen und es außerdem ein neues Problem gibt......
-
Fletcher schrieb:
Der "Informatiker" paßt zu jenem Typ Professor den ich (leider) an der Schule im EDV-Unterricht hatte: Der interessierte sich kaum dafür, was das Programm genau kann, sondern wollte immer den Code sehen: "Wie haben sie das realisiert?" - "Ist doch Blunzen!" dachte ich mir, es funktioniert, es performt, was gibt's da noch zu fragen?
Dein Lehrer hatte hier Recht.
Denn guter sauberer wartbarer Code erkennt man nur daran, wenn man sich auch den Code anschaut und nicht nur die Oberfläche.
Etwas selbsterstelltes hat man von ihm natürlich nie gesehen, aber kritisieren konnte er gut.
Das ist doch toll!
Manche Informatikstudenten wären froh, wenn die Professoren mal ihren Code wirklich ansehen würden.
Wie soll man sonst lernen guten Code zu schreiben, wenn man niemanden hat, der einem auf Code hinweist, der schlecht umgesetzt wurde?
Sei also dankbar, dass du so einen Kritiker hattest!Spiele-Programmierer waren für ihn sowieso das letzte, nur wer sich an Datenbanken ran gewagt hat war für ihn eine Respektperson; so war zumindest seine Denke.
Okay, hier war er dann natürlich im unrecht.
Allerdings könnte es sein, das er immer die ganzen verbuggten Spiele im Hinterkopf hatte und deswegen so dachte.Im "Notepad" von Windows-XP dürfte auch etwas nicht sauber programmiert gewesen sein: Wenn man Text in großen CSV-Dateien ersetzt hat (z.B. Punkt gegen Komma), stieg die zeitliche Dauer quadratisch mit der Größe der Datei! Auch "sehr professionell". Wie ist das durch die Microsft Qualitätskontrolle gekommen?
Notepad wurde zu Win3.x Zeiten schnell dahingeschmiert, damit man wenigstens einen Editor in Windows 3.x hatte und diese Codebasis wurde dann weitgehend in neue Windows Versionen unverändert übernommen.
Oder anders gesagt, die ganze Manpower und Zeit wurde in die Windows Kernkomponenten investiert, Notepad war nur Beiwerk und somit nicht so wichtig.
Win3.0 mußte laufen, das unter DOS und einer 16 Bit Umgebung mit sehr wenig RAM.
Das hat genug Gehirnschmalz erfordert und als dann Win9x und WinNT entwickelt wurde, gab es schon wieder andere Prioritäten.Natürlich wäre es toll gewesen, wenn dann spästens bei WinXP das bis dahin zum Riesenkonzern mutierte Unternehmen wenigstens mal ein oder zwei gute Entwickler extra eingestellt hätte, um sich dem Notepad Problem mal ernsthaft anzunehmen und den Code neu zu schreiben, aber hier war man wohl zu geizig, denn im großen und ganzen funktionierte ja Notepad für die kleinen Sachen und wer mehr wollte, der hat sowieso immer nen gescheiten Editor verwendet.
Wozu also Geld investieren für etwas, wo es keinen Bedarf für gab?
WinXP hatte genug andere Baustellen, die es zu optimieren gab.Auf lange Sicht hingegen sollte die Software des Informatikers so gut wie immer besser sein.
In dem Bereich wo ich arbeite (Flugzeugabfertigung) gibt es kein "auf lange Sicht" mehr. Ständig kommt aus irgendeiner Ecke (Airlinekunden, Behörden und firmenintern) ein neuer Blödsinn und es ist inzwischen alles so komplex geworden, daß niemand mehr zu 100% durchblickt. Daher stellen wir uns mit "Notlösungen" diesen Problemen entgegen, denn bis wir was offizielles bekommen würden, ist so viel Zeit vergangen, daß wir eventuell das ursprünglich geforderte nicht mehr brauchen und es außerdem ein neues Problem gibt......
Guter Code ist sehr modular und sollte sich daher modular recht einfach und unkompliziert über Module, Plugins usw. erweitern lassen.
-
@Fletcher
Gerade wenn ihr Anforderungen habt die sich so schnell und so oft ändern wäre ein Programmgerüst angesagt mit dem man das entsprechend schnell und flexibel umsetzen kann.
Das dumme ist, dass sowas zu entwickeln ganz und gar nicht einfach ist, und auch einige Firmen die Auftragsarbeiten machen nicht wirklich sehr gute Softwarearchitekten haben. (Also nicht alle, einige natürlich schon.)Optimal wäre vermutlich eine eigene Abteilung aufzubauen die diese Software entwickelt, und möglichst eng mit den Anwendern im eigenen Haus zusammenarbeitet.
Das kostet aber auch ordentlich Geld, und vor allem ist es für nicht-IT Firmen alles andere als einfach eine IT-Abteilung so aufzubauen und zu betreiben dass die auch gut arbeiten kann.Von daher also auch sehr riskant.
-
...wäre ein Programmgerüst angesagt mit dem man das entsprechend schnell und flexibel umsetzen kann. Das dumme ist, dass sowas zu entwickeln ganz und gar nicht einfach ist, ....
Auf die Gefahr hin, daß ich dich jetzt (wieder?) verärgere; so ein Programm gibt es schon, es heißt Excel
Optimal wäre vermutlich eine eigene Abteilung aufzubauen die diese Software entwickelt, und möglichst eng mit den Anwendern im eigenen Haus zusammenarbeitet. Das kostet aber auch ordentlich Geld,...
Ja, wäre eine gute Idee, wenn sich mehrere Leute mit diversen Tools auskennen, aber wie du sagst: "kostet Geld". Und schon ist die Idee für die Manager nicht mehr so toll, und so dringend brauchen wir die Tools laut denen eh nicht, weil es nur "nice to have"-Dinge sind.
Es dürfte also wirklich so sein, daß wenn Personenunabhängigkeit gefordert ist, mehrere Leute da sein müssen, die sich mit jedem Detail auskennen, oder man läßt es bleiben, wenn weiterwurschteln ohnehin billiger ist.
Oder man läßt eben von nur einem einzigen Mitarbeiter alles machen, hat als Manager aber eine Rückfallebene, wo im Falle das Falles, zumindest zur Kundenseite hin, der Geschäftsbetrieb normal weiterläuft.
-
Sorry wenn ich was übersehen habe, aber wieso erklärst du deine Excel-Sachen nicht einfach noch zwei weiteren Kollegen? Die müssen ja nicht selbst schon so gut VBA und co. können wie du, aber zumindest die Denkfähigkeit und das Interesse dafür mitbringen, um wenn du dann (warum auch immer) mal weg bist, was damit anfangen zu können. Damit sie bis dahin nicht vergessen haben, was du ihnen erklärt hast, könntet ihr ja grob schriftlich festhalten, worum es ging.
-
Das wäre in unserem Fall die beste Idee - habe ich auch schon deponiert - aber auch unser Direktor muß sich an unternehmeneigene Spielregeln halten bezüglich Planposten. Er muß dann dem Vorstand erklären, warum er jetzt 2-3 neue Hanseln in ein Büro setzt.
Wegen dem Auskennen: In unserem Bereich haben wir einige hundert Angestellte, aber es mir ist noch keiner über den Weg gelaufen den VBA-Programmieren interessieren würde.
-
Muss ja kein VBA sein. Aber wenn irgendein Ingenieur generell Interesse am Programmieren hat, und auch hin und wieder sowas macht, sollte das ja schon irgendwie gehen, wobei ich natürlich nicht weiß, wie highly sophisticated die Sachen, die du da machst, sind.
Gehts denn darum, dass wenn du weg bist, jemand da sehr kurzfristig irgendwas drin machen können muss, oder hat er dann noch etwas Einarbeitungszeit?
-
Es gibt rein gar niemand bei uns der auch nur einfachste Sachen in VBA machen könnte. Du müßtest die Gesichter sehen, wenn ich auf deren PC zum ersten mal "Alt+F11" drücke (es öffnet sich der Makro-Editor); die haben gar nicht gewußt, daß es das gibt und wozu es gut ist.
Das bzw. mein Glück dürfte sein, daß meine Sachen doch weitgehend zuverlässig funktionieren, und mir im Laufe der Zeit daher immer wieder neue Kleinigkeiten anvertraut werden. Gäbe es nur Probleme mit meinen Tools würde das schon niemand mehr verwenden oder mich dafür konsultieren.
-
Mir scheint, deine Firmenleitung hat etwas gravierendes versäumt oder ist noch nicht darauf gekommen. Einen Mitarbeiter mit dem Anspruch "Ich bin unverzichtbar" darf es nicht geben. Geh weg und mache deinen eigenen Laden auf - viel Glück!
-
berniebutt schrieb:
Mir scheint, deine Firmenleitung hat etwas gravierendes versäumt oder ist noch nicht darauf gekommen. Einen Mitarbeiter mit dem Anspruch "Ich bin unverzichtbar" darf es nicht geben. Geh weg und mache deinen eigenen Laden auf - viel Glück!
Naja, vor 1 Jahr sind sie schließlich doch auf mich gestoßen, weil es in der Führungsriege (wie weiter oben schon beschrieben) einen großen Wechsel gab. Seitdem werde ich oft von der eigentlichen Arbeit befreit um mich verstärkt um die VBA-Sachen zu kümmern. Ein dauerhafter Planposten dafür ist noch in Schwebe.
Einen Mitarbeiter vom Typ "ich bin unverzichtbar" darf es in der Tat nicht geben; würde er zugelassen werden, wäre das Management erpressbar. Ich darf meine Stellung daher keinesfalls in dieser Richtung ausnutzen.
Das mit dem "eigenen Laden aufmachen" habe ich immer wieder überlegt, aber wenn ich auf meinen Gehaltszettel schaue, habe ich Zweifel ob ich diese Summen mit dauerhafter Regelmäßigkeit bei "einem eigenen Laden" erreiche. Abgesehen davon, kann ich, wenn ich will, 6 Wochen am Stück in Urlaub gehen und kein "Schwein" ruft mich an. (positiv)
-
Fletcher schrieb:
...wäre ein Programmgerüst angesagt mit dem man das entsprechend schnell und flexibel umsetzen kann. Das dumme ist, dass sowas zu entwickeln ganz und gar nicht einfach ist, ....
Auf die Gefahr hin, daß ich dich jetzt (wieder?) verärgere; so ein Programm gibt es schon, es heißt Excel
Auf die Gefahr hin, daß ich dich jetzt verärgere, oder wieder deinen "ach ich weiss es doch eh besser" Reflex triggere, aber: du hast keine Ahnung.
Excel ist ein nettes Spielzeug, mit dem man innerhalb von sehr engen Grenzen schnell was zusammenfummeln kann.
Wenn die komplexität der Aufgabenstellung steigt, stösst man mit Excel allerdings sehr schnell an bestimmte Grenzen, und der Aufwand steigt exponential.Optimal wäre vermutlich eine eigene Abteilung aufzubauen die diese Software entwickelt, und möglichst eng mit den Anwendern im eigenen Haus zusammenarbeitet. Das kostet aber auch ordentlich Geld,...
Ja, wäre eine gute Idee, wenn sich mehrere Leute mit diversen Tools auskennen, aber wie du sagst: "kostet Geld". Und schon ist die Idee für die Manager nicht mehr so toll, und so dringend brauchen wir die Tools laut denen eh nicht, weil es nur "nice to have"-Dinge sind.
Es dürfte also wirklich so sein, daß wenn Personenunabhängigkeit gefordert ist, mehrere Leute da sein müssen, die sich mit jedem Detail auskennen, oder man läßt es bleiben, wenn weiterwurschteln ohnehin billiger ist.
Äh, ja, was davon war dir jetzt nicht von Anfang an klar?
Bzw. natürlich kann man es auch über Dokumentation versuchen. Nur dass es auch ein riesen Aufwand ist alles so zu dokumentieren dass sich jmd. anderer da ausreichend schnell reinlesen kann.
Vor allem wenn man Bastellösungen mit Excel erstellt. Und dann bleibt immer noch das Problem dass man sich bei der Dokumentation nie sicher sein kann wie gut/verständlich/vollständig die wirklich ist, so lange man sie nicht von jmd. zweitem kontrollieren lässt der auch die erforderlichen Kenntnisse mitbringt.
Was den Aufwand wieder erhöht.
-
Von was für einer Komplexität reden wir hier überhaupt? Wieviele LOC VBA sind das? Vielleicht ist ja alles eigentlich relativ harmlos.
-
hustbaer schrieb:
Excel ist ein nettes Spielzeug, mit dem man innerhalb von sehr engen Grenzen schnell was zusammenfummeln kann.
Wenn die komplexität der Aufgabenstellung steigt, stösst man mit Excel allerdings sehr schnell an bestimmte Grenzen, und der Aufwand steigt exponential.Was für dich "sehr enge" Grenzen sind, ist für uns/mich doch ein größerer Bereich, wo wir uns Bewegen können. Hängt aber auch damit zusammen, daß wir die Daten immer irgendwie in einer Tabellen- oder Rasterform dargestellt brauchen, und dafür eignet sich Excel sehr gut.
Möchte ich Wasserwellen in einem Schwimmbecken simulieren, werde ich mit Excel nicht weit kommen.hustbaer schrieb:
Äh, ja, was davon war dir jetzt nicht von Anfang an klar?
Ich wollte diesen Fakt nur von anderer Seite bestätigt haben; hätte ja sein können daß es dafür irgendwelche gebräuchlichen Strukturen gibt, die mir nicht bekannt sind.
Dokumentation ist gut, aber wenn niemand da, der mit "Cells(y,x)=a" etwas anfangen kann, ist eine Dokumentation ziemlich sinnlos.
Dobi schrieb:
Von was für einer Komplexität reden wir hier überhaupt? Wieviele LOC VBA sind das? Vielleicht ist ja alles eigentlich relativ harmlos.
Beispiel für ein einfaches Projekt: (etwa 100 Zeilen)
Eine CSV-Datei wird von Excel automatisch importiert, und deren Daten in einer für uns gut lesbaren Form umgewandelt. Wegen dem komplexeren Regelwerk reichen die Excel-eigenen Umwandlungs- oder Filterfunktionen hierfür aber nicht aus; dafür gibt es dann den VBA-Code.Beispiel für ein mitteleres Projekt: (etwa 300 Zeilen)
40 Autos und 40 Funkgeräte sind täglich an die anwesenden Mitarbeiter zu verteilen. Ein Auto und ein Funkgerät ist grundsätzlich immer 2 Mitarbeitern zugeordnet. Dabei soll jeder möglichst sein "Stamm"-Auto und -Funkgerät erhalten. Dazu muß das Programm die Arbeitszeit eines jeden kennen (wird automatisch aus einer anderen Tabelle geholt). Es gibt fälle, wo sich beide Mitarbeiter am gleichen Tag nicht sehen (Früh- und Spätdienst), daher können beide "ihr" Auto und Funkgerät bekommen. Der Rest bekommt irgendein Auto.Beispiel für ein schwieriges Projekt: (3000 Zeilen)
Mein Dienstplanprogramm für bis zu knapp 200 Mitarbeiter. Es würde den Rahmen dieses Posts sprengen, wenn ich hier alle Features aufliste und erkläre.Mit diesem Projekt habe ich defacto die Grenzen von Excel erreicht; für weiterführende Funktionen bräuchte ich eine Datenbank im Hintergrund, wobei ich Access aber vermeiden möchte. Das Projekt würde dann zu komplex werden um es nebenbei zu betreuen, und es gäbe nur mich, der sich damit im Detail auskennt. Und genau dieses Projekt war der Grund warum ich diesen Thread eröffnet habe.
-
Fletcher schrieb:
Beispiel für ein schwieriges Projekt: (3000 Zeilen)
Ja und?
3000 Zeilen (LOC) waren einst in Lochkarten gerade einmal 2 Kästen gewesen. Für viele doch eher ein kleines Projekt. 
-
Ja, für einen hauptberuflichen Programmierer ist sowas ein kleines Projekt. Lies dir den Thread nocheinmal durch und schau unter welchen Umständen die 3000 LOC in meinem Fall entstanden sind.
Um dich zu beeindrucken müßte ich wahrscheinlich mindestens ein Windows 7 programmieren, von dem gesagt wird, daß es aus 40 Mio LOC besteht.
Ich glaube, daß wenn man den VBA-Code in Maschinensprache umwandeln würde, deutlich mehr als 2 Kästen mit Lochkarten herauskommen würden. Manche VBA-Befehle lassen im Hintergrund 2 verschachtelte For-Schleifen ablaufen wie z.B. vxA=Range("B1:AD175"), wenn "vxA" vom Typ Variant ist. Mit diesem kleinen Befehl wird ein zweidimensionaler Bereich am Excel-Blatt auf einen Rutsch in ein zweidimensionales Array im Arbeitsspeicher eingelesen.
Die Profis hier können mir ja den entsprechenden C++ Code dafür zeigen, denn lernen muß ich es eh noch , und dann dürfen sie sich noch die Köpfe einschlagen, ob ausreichende Vorkehrungen für Buffer-Overruns getroffen wurden, und ob der Code gut lesbar ist....
-
Sagen wir es doch einfach anders: Da hat jemand einen 1,5 Tonner Kleintransporter und macht damit erfolgreich Umzüge in seiner Stadt. Nun stösst er damit bei einigen Kunden auf seine Grenzen. Was macht er? Grösseres Fahrzeug anschaffen, LKW-Führerschein machen, Hebehilfen kaufen, Kooperationen suchen, etc. Du hast in unternehmerischer Richtung gefragt - was hier selten ist. Ich fürchte aber, dir fehlt dafür doch einiges. Wenn man mit etwas auf Grenzen stösst, sucht man etwas anderes leichteres! Proggen ist und bleibt: Mit den richtigen Werkzeugen bei geringstem Einsatz das bestmögliche Ziel anzustreben - sicher und auch zukunftsfähig.
daddeldu!
-
Fletcher schrieb:
hustbaer schrieb:
Excel ist ein nettes Spielzeug, mit dem man innerhalb von sehr engen Grenzen schnell was zusammenfummeln kann.
Wenn die komplexität der Aufgabenstellung steigt, stösst man mit Excel allerdings sehr schnell an bestimmte Grenzen, und der Aufwand steigt exponential.Was für dich "sehr enge" Grenzen sind, ist für uns/mich doch ein größerer Bereich, wo wir uns Bewegen können. Hängt aber auch damit zusammen, daß wir die Daten immer irgendwie in einer Tabellen- oder Rasterform dargestellt brauchen, und dafür eignet sich Excel sehr gut.
Nein.
Das ist oft falsch verstanden. Excel ist fuer sowas ungeeignet. Natuerlich kann man es dazu vergewaltigen, keine Frage - das ist sehr beliebt.Aber eine Datenbank im Hintergrund ist soviel maechtiger, schneller und klarer. Und vorallem: leichter aenderbar.
Excel-Insel-Loesungen sind neben Access-Insel-Loesungen wohl die schlimmsten Probleme...
Wir haben auch solche Insel-Loesungen bei uns in der Firma und wir arbeiten hart daran die wegzubekommen. Weil es einfach ein Zustand ist...
