Velicity

Ich glaube oft ist es einfach die Kombination aus eher kleinem Laden, in Kombination mit kundenspezifischen Umsetzungen. Im jeweiligen Projekt sind dann eben wenige Leute wirklich drin, man hat nicht viele Leute zum hin- und herschieben und um mögliche Probleme auszubügeln bleiben nur (Über)stunden. Ist dann eben eher ein Wechsel von ruhigen Zeiten und stressigen bzw. crunch Zeiten. Man kann das auch schlecht dem Auftraggeber als Risiko oben drauf rechnen, das wäre gar nicht bezahlbar. Ergo ist es mal ruhige Kugel schieben und mal extreme Überstunden. Bezahlung, Überstunden usw. kenne ich auch alles, obwohl wir keine Webagentur sind. Ausstattung ist ebenfalls bescheiden aber geraucht wird hier nicht und Hygiene ist i.d.R. auch kein Problem.

@userbig Kann nur für mich sprechen. Mit SCRUM hatte ich bis dato nix am Hut bzw. generell mit Agile Frameworks, wobei die Arbeit im KMU nicht soviel anders ist und man sich täglich den Ball hin und her wirft, sei es mit dem Kunden, anderen Schnittstellenpartnern usw. Als Sozialphobiker hatte ich zumindest außerhalb des beruflichen Umfelds deutlich mehr Probleme. Man hat halt so schon mal was gemeinsam. Erleichtert es für mich unendlich. Heißt nicht dass ich davon im Beruf nix merke, hier und da schnallt der Puls mal hoch, die Luft wird etwas dünner und man nimmt mich sicher auch als stiller war aber eingeschränkt hat es mich zumindest nie. Wie gesagt werde da mit Leuten der gleichen Branche deutlich schneller warm und ein großer Teil der Kommunikation ist eben schlicht technisch. Muss bei anderen oder anderen Krankheitsbildern und Problemen nicht genauso sein und hat auch wenig mit der IT zutun, sondern eben wie gesagt mit der Gemeinsamkeit und dem roten Faden.

Habe bis dato nur in einen kleinen Laden gearbeitet, kenne Größere nur von außen, sprich als Kunden aber man kriegt ja ein wenig mit. Schlechteres Arbeitsklima habe ich eher erlebt bei größeren Firmen. Da gab es dann IT1 und IT2, die sich gegenseitig die Schuld in die Schuhe schieben usw. Fand ich sehr unangenehm. Die brauchten dann in der Pflichtenheftphase externe Moderatoren um miteinander zu reden. Muss natürlich nicht immer so sein, habe sowas aber 2-3 mal in großen Unternehmen gesehen, noch nie in einen kleinen. Dazu eben längere Entscheidungswege und meist weniger Flexibilität und Abwechselung. Dafür zahlen größere meist besser, es gibt i.d.R. einen Betriebsrat, Arbeitsschutzgesetze werden für voll genommen. Überstunden fallen meist seltener an. Abgesehen vom Gehalt und Überstunden gefällt es mir in einem kleinen Laden besser, sicher gibt es da auch andere Läden und Ausnahmen, wie immer. Habe persönlich aber Spaß dran die ganzen Prozesse zu sehen, zu verstehen und mit zu erleben.

Denke sowas ist oft gar nicht so ein großes Problem, zumal es meist stark fachlich angehaucht ist. Kommt natürlich auf die konkreten "Defizite" an. Habe da ebenfalls mein Päckchen und im Bezug auf Smalltalk kann man mich da vermutlich vergessen. Je technischer es wird, desto leichter fällt es mir dann.

Ich würde es begrüßen. Finde mit dem Gesieze hält man Leute noch zusätzlich künstlich auf Abstand. Wir sind eh schon ein relativ kühles Völkchen. Denke gerade den etwas introvertierteren erleichtert das Duzen dann auch ein wenig das warm werden mit den Leuten. Ich sieze natürlich in so einem Umfeld, weil ich es so gelernt habe. Genauso wie ich mich beim Kunden entsprechend kleide usw. Generell widerspricht es aber eher meinen Ansichten.

Da bin ich voll bei dir aber es wird sicherlich nicht so sein, dass Leute die häufiger krank sind immer die Top Performer sind. Würde mir persönlich durchaus eine vernünftige Bemessung von Leistung wünschen und Bezahlung die sich daran orientiert. Ist in unseren Bereich aber glaube ich gar nicht so einfach. Stimmt, ist aber auch nicht die Schuld des AG, wenn der AN das quasi aus Geldgier so macht. Geben tut es das sicher. Wobei ein Kranker MEIST wohl auch noch mehr leistet, wenn er da ist, als wenn er nicht da ist. Auf der anderen Seite wird dann sicher auch seltener blau gemacht, weil man auf ein Konzert möchte, ein neues Computerspiel rauskommt oder wofür die Leute sonst mal "krank" sind. Verstehe das schon alles aber eben auch die andere Seite. Klar irgendwo möchte man Gehälter eher runter schieben und motivieren, eben über zusätzlich erreichbare Boni. Hat alles immer Vor- und Nachteile. Ist in der Arbeitswelt eben leider alles komplexer und abstrakter als zur Schulzeit, wo sich Fehler in der Klausur zählen lassen und daran genormt eine Note zurückkommt. Was anstecken angeht, i.d.R. ist man glaube ich eh schon kurz vorher ggf. nachher ansteckbar, sprich am Ende passiert das meist eh.

Warum nicht? Lohn gibt es für Arbeit oder? Klar sucht sich das keiner aus aber in Summe sollte es doch bei allen in etwa gleich enden, mal der, mal der. Und bei vielen Sachen spielt sicherlich auch der Lebensstil da stark mit rein bzw. man legt es gerade zu drauf an krank zu werden. Sicher gibt es da auch Ausnahmen. Aber von der anderen Seite gesehen ist es nicht fair, dass derjenige am Ende mehr hat, der mehr Kohle reinholt bzw. mehr zum Erfolg beiträgt? Geht ja hier nicht ums Grundgehalt, sondern Boni. Es kriegt also keiner weniger, für weniger, sondern nur mehr für mehr. Ist bei uns genauso. Also kriegst du wenn es gut läuft dein Gehalt + X. Ansonsten eben dein Gehalt, obwohl du im Zweifel sogar durch Krankheit weniger Stunden geleistet hast als du in deinem Vertrag hast. Am Ende sind die Gründe und ob sich jemand was aussucht glaube ich da relativ egal. Ich hab mir auch nicht ausgesucht nicht als reicher Hotelerbe mit goldenen Löffel im Mund geboren zu werden, einen Anspruch habe ich dadurch darauf trotzdem nicht. Verstehe zwar das man als Arbeitnehmer immer ganz, ganz stark pro Arbeitnehmer argumentiert und die Arbeitgeber immer die Bösen sind, finde es aber relativ normal. Beim Grundgehalt ist das was anderes, zumal man damit meist fest plant usw.

Imo gibt es da nicht "den Job". Unternehmen unterscheiden sich schon sehr, sehr stark untereinander. Aber ja. Wir haben hier auch schon Leute mit Master in der Probezeit gehen lassen, weil sie nicht in der Lage waren sich reinzufuchsen, auf der anderen Seite haben wir Quereinsteiger, die mit zu den Stärksten zählen. Das kann aber auch schlicht eine Schwäche vom Cheffe sein. Man verliert eben fix aus den Augen was man selbst schon alles weiß, wo man angefangen hat und wie komplex manche Sachen sind. Ist eben ein gängiges Problem der Objektorientierung. Bei all den Vorteilen kommt eben auch eine riesige Menge an Code drauf der nur integriert und "nix" macht aber erstmal mentaler Ballast ist beim Verstehen oder Debuggen. Ggf. fängst du mal von der anderen Seite an, sprich nicht Top-Down, sondern ganz unten, wo wirklich was passiert und hangelst dich von dort aus nach oben zu den einzelnen Submodulen, so dass du nicht gleich ein riesigen breiten Fächer hast, der dir durch den Kopf rumspukt und die ganze Applikation beschreibt.

Ganz normal denke ich, vor allem in so kleinen Läden, wo es keine wirkliche Einarbeitung gibt. Dachte die ersten Tage auch, ich werde niemals etwas verstehen und die Probezeit niemals überleben, wenn die merken, dass ich keine Ahnung von nix habe. Riesige Legacy Codebase, die 20 Jahre gewachsen ist, über verschiedene Sprachen hinweg. Die Sprache die am meisten genutzt wurde, mit der hatte ich noch nie was gemacht usw. Hab auch angefangen, Kollegen alle in der heißen Phase eines Projektes, mir wurde dann gesagt so kannst du dich mit unserer Datenbank verbinden, das ist die IDE, das sind 2-3 der großen Tabellen, von 100+, viel Spaß, hier in der Entwicklungsumgebung kannst du nicht viel kaputt machen. Dann kamen dann auch langsam die ersten Aufgaben rein. Hat sich aber mit der Zeit alles ergeben. Mir hat es sehr geholfen mich in die IDE reinzufuchsen, mal nen Profiler laufen zu lassen und mir nur anzuschauen was wirklich an den Daten geändert wird in den dicksten Routinen und erstmal die ganze Validierung und was weiß ich zu überspringen, um einen groben Überblick bzgl. des Datenflusses zu haben, sonst hätte mich das wohl auch erschlagen. Die erste Zeit dann auch an Wochenenden entsprechend damit beschäftigt. Hat sich dann aber alles in den ersten Monaten ergeben und denke mittlerweile, nach ein paar Jahren bin ich abgesehen von den ganz alten Kundenprojekten, mit denen ich noch nie was zutun hatte wohl einer der fittesten hier. Mittlerweile fehlt eher die Herausforderung und bei den meisten Sachen langweilt man sich zu Tode. Denke das ist der ganz normale Lauf. IT ist nun einmal abstrakt und häufig komplex und vor allem auch immer sehr verschieden. Wenn noch Domänenwissen dazukommt usw. dann kommt eben immer viel Neues und man beginnt in gewisser Weise hier und da bei 0, häufig mit dem Ego und den Erwartungen von davor, aus der vertrauten Umgebung, sei es Schule, Studium oder der letzte AG.

Dabei ist zu erwähnen, dass ich auch nur eine schulische Ausbildung als Technischer Assistent für Informatik habe. Mache zwar dadurch nix anderes als die Leute mit FIAE/Studium oder verdiene hier dadurch weniger als Leute mit anderer Ausbildung, könnte aber anderswo durchaus negativ ausgelegt werden. Dazu Region + kleine Firma.

Nun du hast die Option, sofern du es zeitlich hinkriegst sie abzufeiern oder sie eben am Ende des Jahres bis zu doppelt ausgezahlt zu bekommen. Bis dato freut sich jeder über das Geld. Bei mir macht z.B. die Rufbereitschaft und die anderen Überstunden in Summe gut 10k aus, was von ~33k ein guter Sprung ist für den Aufwand. Davon ab, gerade die Stunden beim Kunden, da hockst du sonst eh in einen billigen Hotel. Ist nicht so als geht das gefühlt von meiner Freizeit ab. Ist ja nicht so als könnte ich spontan nachhause fliegen. Ansonsten klingelt halt ab und an nach Feierabend oder worst Case im Urlaub oder Nachts das Telefon. Hält sich aber auch in Grenzen. Macht dafür in Summe aber eben gutes Geld für den "Mehraufwand."

Nein uns ist nicht unglaublich langweilig. Anschließend haste halt deine 35-45 Stunden. Aber es können eben schlecht alle mal zwei Monate Gleitzeit machen. Abgesehen davon nehmen die meisten diese Überstunden wohl lieber freiwillig für den Jahresboni mit. Die meisten tendieren da doch eher zu mehr Geld, anstatt zu mehr Freizeit, zumal durch die Rechnung i.d.R. damit ein höherer Stundenlohn für diese Stunden rauskommt. Und wie gesagt bei Themen die man nicht parallelisieren kann und davon gibt es viele. Überstunden kommen wohl bei mir aus zwei Quellen. Projekte wo was schief läuft, wo du dann ein paar Wochen eben 15-20 Stunden hast, ggf. mit Wochenenden und weil ich in den meisten Projekten involviert bin die 24/7 Rufbereitschaft haben und da meist der Ansprechpartner bin und Kollegen mich eigentlich so gut wie immer hinzuziehen. Bei anderen kommt ggf. durch die Projektleitung und viel Reisezeiten während der Pflichtenheftphase ordentlich was dazu, dafür bimmelt bei denen das Telefon nach Feierabend seltener usw. Aber im Schnitt kommen wir alle in etwa auf 200-300 Stunden. Chef vermutlich auf ein wenig mehr aber das ist auch eine andere Gehaltsregion. Ist hier letztlich aber auch nicht Thema. Da hatten wir hier ja schon mehrfach festgestellt das einige Sachen nicht optimal laufen. Wüsste aber bei vielen Sachen davon auch keine gangbaren Lösungen bzw. bei jeder entsprechende Probleme. Und sofern ich nicht weiß wie es besser geht und man es ändern kann akzeptiere ich das erstmal so. Wie gesagt gehe stark davon aus, dass bei uns sicher alle lieber am Jahresende nochmal 1 bis 2 Gehälter zusätzlich mitnehmen als die Überstunden abzufeiern. Gerade wenn eh nicht soviel rum kommt macht das doch einen Unterschied.

Jo diese zusätzliche Vollzeitstelle brauchst du aber nur während der Inbetriebnahme beim Kunden und das nur, wenn ein anderes Gewerk über dir verkackt. Wie willst du das planen. Generell die doppelte Anzahl an jedes Projekt stecken, falls was passiert und das für lau? Davon kommen einige Stunden natürlich auch durch die Reisezeit drauf. Sind eben Geschichten ala größeres Gewerk über einen (Hardware/Maschinen/Stahlbau) hat Probleme und dadurch Verzug und reicht den schön weiter. Dann heißt es macht es in 2 Wochen statt 4 Wochen möglich oder das ist das letzte Projekt was ihr von uns seht. Dann werden aus 8-10 Stunden Tage eben gut das Doppelte. Dann nochmal 2-3 Leute Monate lang einarbeiten in das Projekt kannst du nicht. Und zuvor auf gut glück, das rechnet sich nicht, zumal du für die Umsetzung vorne eben nicht so viele brauchst und natürlich andere Arbeit ansteht die Geld reinspült. Unseren Aufwand planen wir eigentlich sehr, sehr gut. Auch mit einen entsprechenden Puffer für uns und unsere Fehler. Aber wenn du dann noch mal für jedes Gewerk über dir einen Puffer aufschlägst, dann ist das nicht bezahlbar. Mal davon ab, dass du viele Sachen eben nicht parallelisieren kannst. Wenn ich im Zusammenspiel mit einer Maschine etwas umsetzen und testen muss und die Maschine noch nicht da ist oder ich noch keinen Zugriff habe, dann ist das so. Da werden dann am Ende zwei Mitarbeiter oder auch fünf am selben Codestück nicht mehr ausrichten. Und die Maschine wird sich auch nicht drei mal so schnell bewegen, damit ich fixer durchkomme. Tests im Sinne von TDD nicht machbar. Weder etwas ala Unittests, noch als automatisierte Integrationstest. Wird aber letztlich alles manuell getestet. Bei den Punkten bin ich aber generell bei dir, da könnte bei uns eine Menge gemacht werden. Aber auch immer wieder eine Geldfrage und ob man Geld jetzt nimmt oder "in die Zukunft investiert" und dafür ggf. auf Umsatz, Jahresboni/Weihnachtsgeld und co. verzichtet, der Kunde wird es nämlich nicht bezahlen wollen, das zahlen dann am Ende eben die Mitarbeiter.

War gemeint in Bezug auf Leuten, die deutlich weniger durch die Krankheit haben. Massive Überstunden kommen i.d.R. bei uns durch Inbetriebnahmen zustande. Unter 200-300 Stunden (ohne Abzug durch Krankheit berücksichtigt) kommt da wohl keiner aus dem Jahr. Das liegt dann an verschiedensten Sachen, meist an Problemen beim Kunden oder anderen Gewerken und das wir die schwächsten in der Kette sind und man uns Druck machen kann. Davon ab werden eher die Leute, die was auf den Kasten haben deutlich stärker eingebunden und haben eher mehr Stunden als anders herum. Ist ja nicht so als gäbe es nur Arbeit für 8 Stunden, ist ja ein endloser Strom.

@kylt bin ich voll bei dir. Gut finde ich das so sicher nicht. Auch wenn es mich persönlich bis dato nie betroffen hat, da ich noch nie krank war, seit ich hier bin. Man kann es eben nur immer relativieren und probieren da irgendwo einen Sinn drin zu sehen. Gibt ja i.d.R. auch keine brauchbaren Kennzahlen womit man wirklich die Leistung von Mitarbeitern messen kann und leistungsgerecht bezahlen könnte. Ganze Thema Geld ist nun einmal immer ziemlich abstrakt im Vergleich zu Punkten und Noten in der Schule, wie man es davor gelernt hat. Ist alles ein zweischneidiges Schwert. So haste niemanden der blau macht, dafür auch Leute die sich ggf. krank zur Arbeit schleppen. Bestrafen, keine Ahnung. Letztlich geht es um die höhe eines freiwilligen Boni, nicht um das Festgehalt. Und wer deutlich mehr Stunden gekloppt hat, der findet das hier und da ggf. auch gerecht, wenn er mehr dazu kriegt, unabhängig einer Schuld der Krankheit. Wobei das natürlich auch viel Spielraum bietet, wenn wir mal nach Japan gucken, wo Übergewicht da mit einbezogen wird usw. Bzw. damit der Lebensstil und wie wahrscheinlich z.B. manche Krankheiten sind, wo man selbst Einfluss drauf hat.

Ist keine Klausel aber wir kennen die Berechnung, sag ich es mal so. Läuft hinaus auf: MIN(Überstunden - 2 * Krankheitsstunden, 174) * Stundenlohn * x Wobei x dann eben vom Gesamtergebnis abhängig ist. I.d.R. was um 1,5 bis 2,0. Klar wird keiner beabsichtigt krank. Bei großen Zeitunterschieden wird aber meist auch derjenige mit massiv mehr Stunden vermutlich auch mehr am Ergebnis beigetragen haben.

Hier gammeln sie krank alle im Büro und stecken sich dann gegenseitig an, ist dann aber auch fix vor rüber für alle. Hat hier vermutlich aber auch den Hintergrund, dass die Krankheit sich auf Jahresboni auswirkt.

Lügen muss man nicht, wie man Sachen umschreibt, wie auch schon von @PVoss gesagt kann natürlich einen Unterschied machen. Ich persönlich fahre z.B. auch nicht in den Urlaub. Gibt mir stand jetzt einfach nix, ggf. ändert sich das mal. Nutze meinen Urlaub dann für Hobbyprojekte, sei es was in der IT, Gitarre spielen, was an der Wohnung machen, wo sich ja auch immer genug anstaut oder mal bei den Eltern vorbei zu schauen. Groß verwerflich finde ich das nun nicht. Mache mir da hin und wieder zwar auch Gedanken, wenn man nach Urlaub und co. gefragt wird und alle anderen waren aber was solls. Soll ich nun lügen oder für andere in den Urlaub fahren, wenn ich die Zeit lieber für anderes nutze?

Am Ende streiten sich ja alle nur um die Definition und die wird zumindest von der Bundesregierung und Wissenschaft seit gut 20 Jahren so definiert, dass als (Einkommens)reich gilt, wer 200% des äquivalenzgewichteten mittleren Einkommen hat. Rein nach der Wortdefinition, sprich Reichtum als Überfluss bzw. mehr als der Bedarf wären wir ja schon viel früher da. Der Rest sind eben einfach unsere Bilder der Gesellschaft, meist gemessen an Extremen. Da Vermögen nicht richtig erfasst wird und es immer nur um Gehälter geht, reden wir eben eigentlich immer nur von Einkommensreichtum. Das ist es was erfasst wird und da sind die Zahlen nun einmal wie sie sind und darunter sind auch Aussagen korrekt wie reich sind immer die anderen und die meisten ordnen sich falsch ein. Problem ist also wahrscheinlich, dass das Kind meist nicht beim Namen genannt wird und wir eben nicht von einkommensreich sprechen. Also ja jemand mit einem mittleren Einkommen wird jemanden mit dem Doppelten höchstwahrscheinlich als reich ansehen. Derjenige wiederum sieht den über sich als reich etc. pp. Reich/arm usw. sind doch letztlich immer nur Worte die einen Sinn machen, wenn wir vergleichen. Wenn alle gleich viel haben ist keiner reich. Damit ist wohl jeder für sich schlicht die Mitte, sofern es nicht wirklich massiv drückt oder man Geld verbrennen kann, ansonsten wird sich wohl keiner klar als in Armut lebend oder im Reichtum lebend betiteln bzw. keinen finden den er im Vergleich zu sich selbst als reich oder arm ansieht. Wir können natürlich das Ganze auch umdrehen, wenn wir Reichtum so weit weg schieben, dass das erst jemand ist, der Milliarden auf der hohen Kannte hat, sprich zig tausend mal mehr als die Mitte, dann drehen wir das mal in Richtung Armut, sprich wer mehr als ein paar Cent hat, soll sich nicht anstellen, er gehört zur Mittelschicht. Oder vielleicht tut er das doch nicht und wir schieben den Begriff Reichtum ein wenig zu hoch, ebenso wie die obere Grenze der Mittelschicht? Ansonsten reden wir natürlich auch von Regionen. Bei sowas ala für 900k kriegt man kein ordentliches Haus, dafür gibt es im Norden oder Osten eben einen Palast, wo man wahrscheinlich auf Personal angewiesen ist um den Laden sauber zu halten. Das wird natürlich auch nicht im Detail unterschieden in so Berichten. Ggf. wie hier Westen/Osten, eigentlich haben wir in Deutschland aber gut 5-6 Bundesländer die man gruppieren könnte bzgl. Einkommen und Mietpreise und dann natürlich Hotspots innerhalb dieser, die noch mal deutlich raus stechen.

Ist doch diesmal mit der Eingabemöglichkeit da unten sehr gut zu filtern. Die 5.160 Euro gelten da laut Artikel für Paare ohne Kinder. Finde das mal eine vergleichsweise gute Darstellung. Klar auf alles kann man nie eingehen, sonst hat man schlicht keine oder zuwenige Vergleichswerte.

@Crash2001 Genau das ist ja mein Reden. Das muss dann von oben entschieden werden, es brauch entsprechende Richtlinien, woran sich Entwickler, auch die eher nicht so starken lang hangeln können. Wirklich Sinn macht es nur, wenn gute Software schreiben nicht viel schwerer und unbequemer ist, als irgendwas zusammenfuschen bzw. man überhaupt die Möglichkeit dazu hat. So kämpft man eher darum, dass es sich nicht so schnell verschlechtert, als dass man wirklich was verbessert. @Errraddicator Der "Fancy OO-Kram" ist eben oft nützlich, gerade wenn man bei jeden Projekt kundenspezifischen Code in den Core reinferkelt. Den Code dann frei von diesen Sachen zu haben und entsprechende Funktionen übergeben zu können, für kundenspezifischen Code, würde es an vielen Stellen sehr viel einfacher machen. Davon ab müsste wie gesagt auch das Interface der meisten Sachen geändert werden, weil Stand nun Funktionen z.B. mit einem Datensatz arbeiten, intern etliche Abfragen für diesen einen Datensatz ausführen usw. Sprich willst du sowas für 100 verschiedene Daten machen kannst du nicht einfach ein Array übergeben, mit holistischer Abarbeitung arbeiten, sondern hast dann von außen rum eine Loop über deine 100 Sachen, die diese tolle Funktion aufrufen. Sorgt natürlich auch für viele Kontextwechsel und entsprechender Performance. Heißt konkret es ist kein seltener Vorgang, dass du bei uns in der Anwendung auf einen Button klickst und das UI für 5-10 Minuten einfriert und du wartest bis der Kram fertig ist. Daher arbeitet z.B. auch im Fehlerfall keiner von uns mit unserer eigenen Anwendung, sondern alle direkt auf der Datenbank, was auch ein Unding ist. Auch ist so eben nix testbar, da ich nix vorgeben kann. Wenn ich eine dieser größeren Funktionen testen wollen würde, so muss ich erstmal dafür sorgen, dass in 20+ Tabellen stimmige Daten sind. Sprich die Änderung der API ist einfach ein großer Punkt, der viele Sachen besser machen würde. So hast du ein Fehler, kannst reinsteppen, weißt gar nicht welche Daten von welcher Tabelle ausgewertet werden und zu deinen Fehler führen. Intern kannst du natürlich umstellen was du möchtest. Wobei gerade bei den großen Routinen eh keiner weiß was da alles passiert und es sicher auch viele Kombinationen gibt, die so nie gedacht waren, weil sie eben auch über die Daten gesteuert werden und nicht ausschließlich über das was von außen reinkommt. Davon ab möchte ich als Aufrufer auch gar nicht wissen müssen was iMode1 und iMode2, die jeweils 4-5 Modes haben in welcher Kombination was machen und welche der 10 Parameter ich für die jeweilige Kombination füllen muss und in welcher Tabelle welche Datensätze verfügbar sein müssen usw. Weiter geht es dann zum Datenbankschema wo viele Sachen drin sind, die redundant sind, für Fehler sorgen oder schlicht technisch nicht möglich sind mit aktuellen Aufbau aber oft gebraucht werden. Aber auch da gleiche Thema, es würde viele Funktionen im inneren beeinflussen, als auch die APIs, da bestimmte Felder in einigen Tabellen nicht mehr verfügbar wären, sie in anderen wären, ggf. noch Tabellen dazwischen wären usw. Natürlich auch die Gruppierungen in welchen Packages die einzelnen Funktionen sind, was nun ein paar generische Dinger sind ala Tools, Libraries usw. die jeweils hunderte Funktionen beherbergen. Fix ein Fehler bei einer Sache und es wird erstmal etwas kompiliert, was hunderte Rechner betrifft, die Connection Pools sind im Eimer, die Clients müssen neu connecten usw. Konflikte in der Versionsverwaltung macht es natürlich auch nicht seltener. Das Ecosystem ist natürlich auch kleiner. Viele Funktionen, z.B. für Arrays und Strings sind so fertig nicht vorhanden, ergo selbst implementieren. Soviel OpenSource gibt es da auch nicht, also Rad meist neu erfinden. Auch hast du natürlich kein generisches Array. Der eine arbeitet mit einem Array wo drin ein VARCHAR2 Feld ist von TabelleA.FeldB%TYPE, der andere hat eine andere Tabelle, ein anderes Feld, eine andere VARCHAR2 Größe. Wenn du nun eine Funktion zur Sortierung schreibst, dann ist die an dieses Interface gebunden. Du hast also kein ArraySort, sondern ein ArrayTyp1Sort, ArrayTyp2Sort etc. pp. Oder es muss eben jeder zu seinem speziellen Fall zwei Konvertierungsfunktionen schreiben zu einem Standard VARCHAR2 Array, das mit der maximalen VARCHAR2 Größe arbeitet. Oder wir arbeiten alle gleich mit diesen und haben keine Überprüfung auf die erlaube Größe, was dann im späteren Programmverlauf für Probleme sorgt. Es gibt einfach viele Punkte die es einen schwerer machen, sagen wir es mal so. Und das sind ja nur Kleinigkeiten die mir nun On-The-Fly einfallen, da gibt es ja im täglichen Einsatz noch viel, viel, viel mehr. Wie gesagt um kleine Änderungen geht es mir bei dem Ganzen nicht, die mache ich wo ich kann. Mir geht es um große Änderungen. API Umstellen, das als Firmenagenda mal durchziehen, Richtlinien und Tools schaffen, die dafür sorgen, dass der neue Code sauberer ist, das kundenspezifische Sachen entsprechend ausgelagert sind, das man ggf. ein Core hat, den man hirnlos abgleichen kann zwischen den aktuellen Projekten, wo man Fehler nicht per Hand in zig Projekten nachziehen muss, dass man bei neuen Projekten nicht Wochen lang Sonderlocken vom alten Kunden ausbaut, das vor allem große Funktionen testbar sind, so dass man sich wieder traut an diese ran zu gehen, dass die Performance einen akzeptablen Rahmen bekommt. Aber selbst wenn das dann alles optimal innerhalb von PL/SQL gemacht wäre, so findest du doch schwerer PL/SQL Entwickler, als welche für andere Sprachen, gerade ein holistischer Ansatz, anstatt Row-By-Row Abarbeitung ist vielen auch Fremd, die von anderen Sprachen kommen. Davon ab, dass die Performance immer noch bescheiden ist, gerade für Kommunikation mit Partnern die andere Zeiten gewohnt sind, wie SPSn usw. Unabhängig von PL/SQL oder nicht, so oder so gibt es viele Stellen und Entscheidungen, die da über die Verantwortung des einzelnen Entwicklers weit hinaus gehen. Und am Ende gibt es nur zwei Optionen BEI DIESEN Themen. So lassen, weil haben wir immer schon so gemacht oder anpacken, was sich MEINER Meinung nach definitiv lohnen würde und viele Bereiche positiv beeinflussen würde. So wird das Problem eben schlimmer. Die API gibt das was du brauchst nicht her, da will keiner ran, ergo ein Ranzen drum rum, den auch kaum wer kennt und weiß dass es existiert, weil dann irgendwo in einen Job oder Trigger oder was weiß ich kundenspezifisch nochmal was oben drauf passiert oder aus einen String in der Datenbank irgendeine Logik geparst wird oder was weiß ich. Auch hier drehen wir uns aber wieder im Kreis. Ich sage Kleinkram geht, das Problem sind in meinen Augen vor allem die großen Sachen und dann kommt als Antwort Kleinkram geht doch ohne Probleme. Diesbezüglich sind wir uns einig, viele Probleme gehen aber darüber hinaus. Aber am Ende kann ich eh nur jammern, denn entscheiden kann ich das nicht. Ggf. muss ich einfach lernen mich weniger daran zu stören, wenn der Gleiche Mist immer wieder passiert, der dann natürlich auch zu den Sachen führt, die im anderen Thread schon kritisiert wurden, wie Überstunden und ständige Erreichbarkeit.

Mir ging es mit hier um hier im Forum, sorry wenn das missverständlich war. Innerhalb des Unternehmens kommuniziere ich so Sachen, sehr, sehr konkret mit möglicher Lösung oder entsprechenden Ansätzen aber auch inklusive der Konsequenzen. Natürlich kannst du das. Irgendwann will man die API aber auch aufräumen und keine Funktion haben mit 10+ Übergabeparametern, die je nach Fall gefüllt sind oder nicht in Kombination mit iMode1 und iMode2, die Fluss im Programm steuern. Oder ggf. Daten von außen vorgeben, als sie innerhalb der Funktionen aus der Datenbank aus zig Tabellen zusammen zu selektieren. Was die Sprache angeht, wir reden was die Geschäftslogik angeht zu 99% von PL/SQL und 1% von C würde ich sagen. Mit dem Entwicklungsleiter/Geschäftsführer. Ist eben nur ein 10-15 Mann Unternehmen. Dadrüber haste noch den Vorstand aber "mein Chef" sitzt eben keine 10 Meter weiter und der entscheidet wo es lang geht. Ich besitze da schon relativ große Narrenfreiheit und bei allen überschaubaren wird eigentlich fast alles so umgesetzt, wie ich mir das wünsche aber an die großen Probleme will man eben nicht ran. Ich sag nicht 1-2 Projekte skippen und dann haben wir unseren Stand. Eher ein Stand mit den man dann kleinere Projekte umsetzen kann, muss dann eben wachsen. Die Projekte sind hier eh sehr stark kundenspezifisch, am Ende arbeitet man eh nen halbes Jahr am neuen Projekt. Nebenbei kommen ja auch noch Erweiterung, Wartung, Support und alles mögliche rein.

@Errraddicator hier im Rahmen lief das natürlich anders ab. Hier hilft es aber wohl kaum, wenn ich jede Methode und jedes Konzept und jede Umsetzung beschreibe und sage was daran falsch ist und wozu das führt. Mit der Zeit hat sich aber gezeigt das selbst gut umgesetzte Sachen hier aufgrund der technischen Limitierung noch sehr bescheiden sind und viele Sachen eben sehr, sehr tief im System stecken oder von der Grundüberlegung komplett falsch sind. Das sich das in einen halben Jahr ändert, das glaube ich auch nicht und erwarte ich auch gar nicht. Wenn es nach mir geht sehe ich aber ein Rewrite hier am Sinnvollsten. Dafür muss man aber auf ein paar größere Projekte verzichten und das wohl an kleinen Projekten entwickeln und den Funktionsumfang dann Stück für Stück aufstocken. Hängen ja wie gesagt auch andere Probleme dran, dass wir hier zig Sprachen haben, du nicht mal eben paar Kollegen dazu nehmen kannst, wenn nen Projekt droht gegen die Wand zu laufen, sondern das nur mit massiven Überstunden zu retten ist. Da hilft dir kein kleines Refactoring für. Kleine Verbesserungen kommen rein, auf der anderen Seite kommen neue Probleme rein, da bremst du maximal, davon ab, dass an den wichtigen Stellen nur wenige Leute ran können und es eben auch nicht unbedingt gewollt ist, weil i.d.R. was kaputt geht, wenn daran was geändert wird. Ergo kommen 20 Jobs oben drauf die Fehler aufräumen. Die kleinen Sachen mache ich schon nach besten Gewissen und Zeit, die Probleme sind dann aber die großen APIs, technische Limitierung, fehlende Richtlinien usw. Sachen die man gemeinsam bequatschen muss, die von oben beschlossen und abgesegnet werden müssen usw. So kommen natürlich auch viele Probleme nach. Hohe Stundensätze, ergo wird es als wenig Aufwand verkauft. Ergo läuft es hinaus auf Fusch in kostenpflichtig und anschließend als Gewährleistung noch etliche Stunden reparieren, wenn der Kunde Probleme hat. Am Ende ein Kampf gegen Windmühlen, wenn es kein Bruch gibt. Und bzgl. Projektion, dass ich Gründe verstehe heißt nicht, dass ich Sachen richtig finde. Glaube das versteht ihr teilweise falsch. Ich hinterfrage warum jemand so handelt und verstehe das. Mir ist klar, dass große Änderungen bedeutet Projekte ablehnen, weil sonst gar keine Zeit dafür da wäre. Mir ist klar das es dann kein "Weihnachtsgeld" gibt, weder für mich, noch für sonst wen. Ich für meinen Teil würde darauf verzichten. Mir wäre es lieber nicht bei jeden Projekt die gleichen Probleme zu haben. Nicht Wochen lang Sonderlocken vom Leitprojekt ausbauen. Nicht feststellen, dass man doch etliche übersehen hat. Nicht bei jeden größeren Update etliche Probleme einbauen, nicht alles noch langsamer machen, weil man sich an Stellen nicht ran traut, weniger Überstunden, weniger Supportanrufe, was vor allem Nachts angenehm wäre. Für mich wäre mal auf ein paar Tausender verzichten und anschließend mehr Spaß bei der Arbeit haben und das Unternehmen voran bringen können ein Gewinn. Neue Leute suchen und einarbeiten wäre leichter. Man könnte Projekte schneller umsetzen, würde weniger Zeit verschwenden mit Fehlerbehebungen etc. pp. Ich verstehe aber auch wenn mein Chef sagt den Stress tue ich mir die letzten Jahre vor der Rente nicht an und das Geld dran hängt, sowohl Umsatz als auch das Weihnachtsgeld von uns allen. Ebenso das man ein paar Altkunden hat, die man trotzdem noch pflegen muss. Wie gesagt um Kleinkram geht es mir nicht. Da nehme ich mir Zeit, sowohl bei neuen Sachen oder wenn ich über was stolpere. Es gibt aber einfach große Sachen, wo klar ist, dass etwas kaputt gehen wird, wo etliche Leute ihre Aufrufe ändern müssen und kein Mensch auch nur weiß, wo das alles aufgerufen wird und Technologien oder generelle Abläufe ändern ist noch einmal eine ganz, ganz andere Geschichte.

Klingt schön aber wie gesagt schon die Limitierungen der Sprache sind ein großes Problem. Dann der Code der nachkommt, da bräuchte es erstmal Richtlinien und Systeme, das neue Sachen anders gelöst werden, Leute müssten entsprechend erzogen werden. An die großen APIs kann man nicht ran, da darauf zig Anwendungen zugreifen und verschiedenste Leute ihre Anwendungen ändern müssen. Davon ab kommt es da sicher auch zu Fehlern, die auch ihren Weg ins Produktivsystem finden würden. Ist der Kunde natürlich auch nicht amused, wenn ne Stelle kaputt geht, wo eigentlich nix geändert werden soll, weil man es sich wartbarer strickt. Verbessere schon soweit ich kann aber an die Stellen, die wirklich wichtig wären, kann ich so nicht nach eigenen ermessen ran. Und sofern das keiner zahlt, ist eben Finger weg angesagt und da das alles so schon 30 Jahre klappt, geht es so auch weiter. Ist in Summe einfach was, das man größer aufziehen müsste und wie gesagt ich sehe da auch nicht unbedingt den Wert in der aktuellen Codebase/Sprache, kannst eben nur hart verdrahten. Schon alleine weil man bei Projekten sehr unflexibel ist und nur mit Überstunden gegen an kommt und nicht einfach weitere Kollegen dazu nehmen kann, weil die mit anderen Sprachen, IDEs usw. arbeiten.

Gibt sicher immer Risiken und ich verstehe auch meinen Chef, immerhin würde das bedeuten keine Boni usw. will auch keiner bei ohnehin schon niedrigen Gehalt drauf verzichten und eben die auch dort erwähnten Risiken. Fängt aber bei uns schon bei der Sprache an. Starr, imperativ, langsam, sehr langsam. Überhaupt nicht testbar und von 15 Leuten trauen sich ggf. 2-3 an die komplexeren Sachen ran und selbst für uns ist das kritisch, weil ausschließen, dass am Ende gar nix mehr geht kann man schlecht. Gerne riesige Methoden mit mehren Modi, die dann komplett andere Sachen machen usw. Alles auch immer abhängig von aktuellen State der Datenbank, was intern in den Funktionen ermittelt wird. Fehlendes Logging oder an anderen Stellen Exzessives und Unsinniges. Viele Fehler lassen sich kaum erfassen und man darf quasi beim Debuggen 30 Minuten lang zig Variablen rauskopieren um den Fehler nachzuvollziehen. Da steht dann auch gerne mal was anderes, während man debugged. Um viele Probleme wird nen Rucksack drum rum gemacht, weil man sich nicht traut die eigentlichen Problemstellen anzufassen. Macht das System auch immer verteilter, schlechter wartbar und langsamer. Quasi Jobs, die dann die Problemfälle finden und die kaputten Daten hinterher korrigieren.. Benutzerfreundlichkeit, Optik und Geschwindigkeit der UI ist auch kaum funktional. Kryptische Bezeichnungen aus dem Code und Stati gehen teilweise in die UI über, sprich der Benutzer muss was von Stati und Modi verschiedener Funktionen wissen. Und das ganze Datenbankmodel ist auch wenig konsistent, was immer wieder für Fehler sorgt und weit, weit, weit mehr Verantwortung in die Hand des Entwicklers als nötig. Und das sind nur einige Probleme. Datenschutz, Backupkonzept und viele andere Sachen sind auch mäh. Das läuft dann auch alles mit einem Leitprojekt, das den größten Funktionsumfang hat und am meisten Erweiterungen kriegt. Beim neuen Kunden wird das kopiert und angepasst. Natürlich sind da noch 10000 Sonderlocken vom letzten Kunden drin und das fliegt ein jedes mal wieder um die Ohren. Ganz ehrlich, wäre es meine Entscheidung. Rewrite und zwar in einer anderen Sprache, alle hier an einen Tisch holen und langsam mit ein paar kleineren Projekten starten. Gucken welche Sprachen und Technologien Sinn machen. Meiner Meinung nach könnte man leichter Leute einarbeiten, leichter neue Features implementieren, leichter neue Projekte umsetzen und hätte eine deutlich höhere Kundenzufriedenheit. Sind aber vermutlich mittlerweile Millionen von Zeilen an Code, gut 40-50 Prozesse, 20-30 Jobs, nen paar Webanwendungen, ne Android Anwendung und ne C# Anwendung und nen paar alte C Sachen. Aber eh alles Entscheidungen über meiner Gehaltsstufe und leider nicht in meiner Hand. Vielleicht stelle ich mir das auch zu einfach vor, wobei einfach ist es jetzt auch nicht ?