Hi, habe soeben mal die Software von einem Gerät von meiner Firma analysiert. Das Hauptprogramm läuft hier allen Ernstes in der Timer-ISR ab. Diese wird entweder periodisch, über einen Wakeup-Pinchange oder einen Tasterdruck aufgerufen. Wartbarkeit, Übersichtlichkeit oder Erweiterbarkeit: Furchtbar. Wurde aber auch nicht von einem Software-Fachman geschrieben, sondern von einem Naturwissenschaftler... Leider fehlt mir vermutlich auf Grund fehlender Ausbildung die Kompetenz hier was zu sagen. Ich hätte so Lust gute Software zu schreiben. Leider bin ich nur Facharbeiter mit zusätzlich abgebrochenem Studium (ET/TI). Schade. Wie ist die Softwarequalität bei euch so? Gruß
:
Verschoben durch User
@ EGS_TI (Gast)
>Wie ist die Softwarequalität bei euch so?
Willst du das WIRKLICH wissen? Die Wahrheit ist oft grauenvoll.
Natürlich nicht. Bei den Unternehmen die über Bastelbudenstatus hinaus sind gibt es getrennte Abteilungen für HW und SW.
Oder wie es mal jemand treffen formulierte. Die Liebhaber demokratischer Gesetze und Wurstwaren sollten besser nicht fragen, wie diese zustande kommen. Software ist die gleiche Pampe.
Falk Brunner schrieb: >>Wie ist die Softwarequalität bei euch so? > > Willst du das WIRKLICH wissen? Die Wahrheit ist oft grauenvoll. Ja.., ich will :)
Angehängte Dateien:
-
wtf.png
38 KB -
WTF_393C54F7.jpg
64 KB
Kannst ja auf meiner Webseite gucken ;) Da ist bei den alten Projekten auch viel zum Schreien vorhanden. Bei den neueren Projekten ist das dann besser. Muss wohl durch das TI Studium kommen :> Den größten Schreikrampf bekomm ich persönlich bei meiner GSM Lib. Auch wenn die schon vielen leuten geholfen hat, muss ich die endlich mal ordentlich schreiben ... In welchem Kurs biste denn rausgeflogen? Ansonsten gibt es nur eine Wahre Einheit zur Qodequalität (siehe Bild).
EGS_TI schrieb: > Ich hätte so Lust gute Software zu schreiben. Leider bin ich nur > Facharbeiter mit zusätzlich abgebrochenem Studium (ET/TI). > Schade. > Wie ist die Softwarequalität bei euch so? was ist denn gute Software? Wenn die Software das tut was sie soll und auch stabil läuft, also in jeder Situation das richtige macht. Dann ist doch die Umsetzung ziemlich egal. Es ist zwar lobenswert, "schönen" Quellcode nach Lehrbuch zu schreiben, aber das Ziel ist doch wohl die Aufgabe zu erfüllen. Schönens Beispiel: http://de.wikipedia.org/wiki/Duff%E2%80%99s_Device das ist bestimmt nicht nach Lehrbuch, aber es erfüllt seinen zweck.
EGS_TI schrieb: > Das Hauptprogramm läuft hier allen Ernstes in der Timer-ISR ab. Wenn die Anwendung fast ausschließlich aus periodischen Aktivitäten besteht, ist es durchaus üblich und auch in Ordnung, diese direkt im Timer-Interrupthandler auszuführen. Oder was spricht deiner Meinung nach dagegen? Falls auf dem Mikrocontroller ein Betriebssystem, Echtzeitkernel o.ä. läuft, sieht die Sache allerdings wieder etwas anders aus.
EGS_TI schrieb: > Das Hauptprogramm läuft hier allen Ernstes in der Timer-ISR ab. > Diese wird entweder periodisch, über einen Wakeup-Pinchange oder einen > Tasterdruck aufgerufen. So what? Es ist oft überaus SINNVOLL, die gesamte Funktionalität in ISRs unterzubringen. Die Hauptschleife dient eigentlich nur dazu, das Device schlafen zu schicken, wenn es nix zu tun gibt. > Wartbarkeit, Übersichtlichkeit oder Erweiterbarkeit: Furchtbar. Das kommt wohl nur C-lern so vor, die Interrupts niemals richtig verstanden haben und es deswegen gewohnt sind, ihren ganzen (oft sowieso nur zusammengeklauten und niemals verstandenen) Müll dümmlich pollend in einer busy-loop in main() durchzuackern. > Leider fehlt mir vermutlich auf Grund fehlender Ausbildung die Kompetenz > hier was zu sagen. Das ist wohl so.
> Das Hauptprogramm läuft hier allen Ernstes in der Timer-ISR ab. Das kann eine gute Lösung für eine zeitstabile Hauptschleife sind, in die Nebenjobs ohne Prioritätsprobleme eingereiht werden. > Wartbarkeit, Übersichtlichkeit oder Erweiterbarkeit: Furchtbar. Du meinst: Es übersteigt deine Fähigkeiten. Schon möglich. > Leider fehlt mir vermutlich auf Grund fehlender Ausbildung > die Kompetenz hier was zu sagen. Es besteht eine hohe Gefahr, dich vor allen Klügeren zu blamieren.
Schon interessant wenn die "main" in einer ISR steht :-P Da Du den Code sicherlich nicht posten darfst wird Dir auch niemand erklären können warum das so gemacht worden ist. Einige Möglichkeiten wurden ja schon genannt. Nicht alles was auf den ersten Blick sinnlos erscheint ist es auch ...
EGS_TI schrieb: > Das Hauptprogramm läuft hier allen Ernstes in der Timer-ISR ab. > Diese wird entweder periodisch, über einen Wakeup-Pinchange oder einen > Tasterdruck aufgerufen. Das klingt irgendwie nach einem Betriebssystem, alles tickt mit einem Scheduler, die main-loop ist die idle-task und macht nur ein sleep(). MfG Klaus
c-hater schrieb: > Das kommt wohl nur C-lern so vor Langsam wird Dein dauerndes C-Bashing langweilig.
EGS_TI schrieb: > Das Hauptprogramm läuft hier allen Ernstes in der Timer-ISR ab. Dass alleine muss noch kein schlechter Stil sein. Im Gegenteil: In vielen Anwendungen, wo der Controller hauptsächlich eine einzige, exakt getimte Aufgabe ausführt, ist das sogar das Mittel der Wahl. Und das ist bei den meisten Anwendungen der Fall, während man nur selten mehrere Interrupts wirklich benötigt. Einen Interrupt braucht man nur dann, wenn es wirklich zeitkritisch ist. Und das ist bei vielen Anwendungen eben genau die eine getimte Hauptaufgabe, während alles andere mit viel höherer Latenz behandelt werden kann.
:
Bearbeitet durch User
Allgemein solltest du nicht den Programmierstil kritisieren, nur weil er irgendwelchen Prinzipien entspricht, die du irgendwo gelernt hast. Denn erstens sind es eben nur Prinzipien, die je nach Situation gelten oder eben nicht. Und zweitens sind viele Programmierprinzipien schlicht Bullshit, ich denke z.B. an die ungarische Notation oder Kommentare zu jeder Zeile. Wenn du den Stil kritisieren willst, dann nur, wenn du ganz konkret begründen kannst, warum etwas in genau dieser Situation schlecht/gefährlich/unsinnig ist. Ansonsten verspielst du deine Glaubwürdigkeit, denn wer stellt schon die programmier-philosophische Meinung eines einzelnen über einen funktionierenden Code? Noch dazu, wenn er einen tieferen Ausbildungsstatus hat.
Nein, die main steht nicht in einer ISR. Sieht ungefähr so aus:
1 | // Übliche Defines etc..
|
2 | |
3 | void main(void) { |
4 | |
5 | // Inits etc.
|
6 | // Prüfen welche Geräteversion etc.
|
7 | |
8 | |
9 | |
10 | |
11 | Timer1IF = 1 // Auslösen des Timer1-Interrupts |
12 | |
13 | while(1) { |
14 | |
15 | KommunikationsFunktion(); |
16 | |
17 | Program(); // Funktionsaufruf Hauptprogramm |
18 | |
19 | KommunikationsFunktion(); // Funktionsaufruf für Kommunikation |
20 | |
21 | Sleep(); |
22 | |
23 | |
24 | }
|
25 | |
26 | |
27 | }
|
Nach genauerer Betrachtung habe ich jetzt herausgefunden, dass im Timer doch nur ein Flag gesetzt wird. Das Hauptprogramm wertet dies dann innerhalb der main() aus. Dennoch besteht die main-Datei aus über 1500 Zeilen.
Ich sehe das Problem nicht. Der Timer sorgt einfach dafür, dass die main loop mit Echtzeitbezug durchlaufen wird. Und dadurch, dass in der main loop einfach alles hintereinander weg programmiert ist, kann man sich vieles sparen, was bei einer interrupt-lastigen Programmierweise notwendig ist: semaphores, double buffers, etc.
EGS_TI schrieb: > Nach genauerer Betrachtung habe ich jetzt herausgefunden, dass im Timer > doch nur ein Flag gesetzt wird. > Das Hauptprogramm wertet dies dann innerhalb der main() aus. Also doch wieder nur dieses elende Polling-Gewurstel. Nunja, es KANN immerhin durchaus auch Anwendungen geben, wo diese Architektur sinnvoll ist. Dürfte aber eher die Ausnahme sein... > Dennoch besteht die main-Datei aus über 1500 Zeilen. Mein Gott, 1500 Zeilen. In einer Datei. Das ist ja wirklich schlimm... Wenn das jetzt wirklich nur eine Funktion wäre, würde ich sagen, ja, das ist dann vielleicht doch etwas unübersichtlich. Aber die Zahl der Zeilen in einer Datei ist nun wirklich ziemlich unerheblich, auch wenn ich selber ebenfalls eher dazu neige, Funktionsbereiche oder Protokollebenen in getrennte Dateien zu packen. Letztlich hilfreich ist das auch nur, wenn denn diese Dateien auch sinnvoll benannt sind. Wenn aber aus Faulheit nur kryptische Abkürzungen als Dateinamen verwendet werden, ist der Ansatz sogar eher kontraproduktiv.
Marcus schrieb: > Ich sehe das Problem nicht. Der Timer sorgt einfach dafür, dass die main > loop mit Echtzeitbezug durchlaufen wird. Und dadurch, dass in der main > loop einfach alles hintereinander weg programmiert ist, kann man sich > vieles sparen, was bei einer interrupt-lastigen Programmierweise > notwendig ist: semaphores, double buffers, etc. Das anfangs gedachte Problem hat sich ja behoben. Von interrupt-lastiger Programmierung halte ich auch nichts..
c-hater schrieb: > Wenn das jetzt wirklich nur eine Funktion wäre, würde ich sagen, ja, > das ist dann vielleicht doch etwas unübersichtlich. Aber die Zahl der > Zeilen in einer Datei ist nun wirklich ziemlich unerheblich, auch wenn > ich selber ebenfalls eher dazu neige, Funktionsbereiche oder > Protokollebenen in getrennte Dateien zu packen. Das ist ja noch nicht das komplette Programm, nur die main.c sozusagen. Hinzu kommen noch gefühlte 20 Ordner mit Funktionsbereichen, wie du schreibst.
Also im festen Zeitraster (bei jedem Timer-INT) werden Daten angenommen, verarbeitet und das Ergebnis ausgegeben. Danach, weil das vermutlich schneller als der Timer-Zyklus geht, wird auf das nächste Zeitraster gewartet (sleep() wird durch anfallende INT's beendet). Ist doch alles ok. Gut, kleine Nachteile, sleep() endet nicht nur bei Timer-INT, sondern auch bei allen anderen. Deshalb besser im Interrupt ein Flag setzen, das die Hauptschleife auswertet. Die ISR macht nur das absolut nötigste, was zeitkritisch ist, z.B. Daten aus der Uart entnehmen/reintun. So spart man sich viele "Multitasking" Probleme. Wenn man doch ein bisschen Tasken will, dann gibt's z.B. protothreads.
EGS_TI schrieb: > Leider fehlt mir vermutlich auf Grund fehlender Ausbildung die Kompetenz > hier was zu sagen. Leider ist das sehr wahr. Timer-ISR ist nicht nur generell eine geeignete Lösung für solche Aufgaben, genau genommen arbeiten Betriebssysteme immer so, besonders moderne mit präemptivem Multitasking, da passiert praktisch alles in ISRs. Was dachtest du denn wie ein Thread/Task einer Windows-Anwendung zur Ausführung kommt? Gruss Reinhard
Wenn Du von "Deiner" Firma sprichst, höre ich daraus, Du seist der Chef. Wenn Du der Chef bist, ist es an Dir die (Programier-)Aufgaben zu deligieren oder abzusegnen. Als Chef hast Du Interesse daran, dass keine Arbeitszeit Deiner Mitarbeiter vergeudet wird. Wenn Du die Aufgabe nur definierst durch: Du brauchst ein Programm, bis spätestens Vorgestern + X, dass Aufgabe YZ erledigen muss, dann hat Dein Mitarbeiter hervoragend gearbeitet, wenn das Programm genau das tut, was es soll, und er auch noch rechtzeitig fertig wurde, egal wieviel Hacks von hinten durch die Brust vorhanden sind. Zum Thema Wiederverwendbarkeit stellt sich im immer Einzelfall die Frage, ob es sich lohnt, Teile in eine Bibliothek auszulagern, oder nur Quelldateien sauber zu trennen, oder auch nicht. Wie gut ein Code wartbar/testbar/erweiterbar/wiederverwendbar/dokumentiert sein muss, ist im VORFELD zu klären und abzuschätzen. Nur anhand dieser Vorgaben kann man einen Code überhaupt bewerten. Zuletzt in gutem Fussballdeutsch: Nix ist scheißer, als der eigene Quellcode von gestern... Schiko
c-hater schrieb: > Also doch wieder nur dieses elende Polling-Gewurstel. Nunja, es KANN > immerhin durchaus auch Anwendungen geben, wo diese Architektur sinnvoll > ist. Ich finde das sogar für viele Anwendungen sinnvoll. Der Prozessor hat doch offenbar sowieso nichts besseres zu tun, da kann er auch pollen. Ausnahmen, die mir gerade einfallen, wären batteriebetriebene Systeme und Anwendungen, wo schnell (< ein paar ms) auf "plötzliche Ereignisse" reagiert werden muss.
Marcus schrieb: > Ich finde das sogar für viele Anwendungen sinnvoll. Der Prozessor hat > doch offenbar sowieso nichts besseres zu tun, da kann er auch pollen. Nö. Wenn's nix zu tun gibt, sollte er schlafen, so wie Gott es gewollt hat. > Ausnahmen, die mir gerade einfallen, wären batteriebetriebene Systeme Energiesparen ist auch dann sinnvoll, wenn der Strom aus der Steckdose kommt. Er ist nämlich auch dann nicht umsonst. Aber mal abgesehen von den direkten Energiekosten: Weniger Energieumsatz bedeutet auch weniger Abwärme und damit weniger konstruktiver Aufwand zur Abgabe dieser Wärme an die Umgebung. Das ist oft ein viel direkterer Kostenfaktor, denn der fällt schon beim Hersteller an, nicht erst beim Kunden... > und Anwendungen, wo schnell (< ein paar ms) auf "plötzliche Ereignisse" > reagiert werden muss. ms?! Das sind kleine Ewigkeiten. Im Übrigen ist gerade die Notwendigkeit für besonders schnelle Reaktionen das Einzige, was einen dazu bringen könnte, eine MCU nicht schlafen zu legen, wann immer möglich. Denn das Aufwecken dauert. Umso länger, je tiefer das Teil schläft... ... Nein, das Einzige, wofür "Polling" wirklich sinnvoll ist, ist die Situation, daß gemeinsam genutzte IO-Resourcen mit hohen Latenzen (z.B. ein SPI- oder I2C-Bus) sinnvoll gemanaged werden müssen. Denn sowas führt bei direkter Behandlung in ISRs entweder zu unlösbaren Problemen oder alternativ wieder genau zu dem dümmlichen Verhalten einer primitiven Polling-Schleife (nur mit massig Overhead). Genau dann (und nur dann) ist es in erster Näherung die beste Variante, zu pollen. Das funktioniert sehr gut, solange es nur eine solche Resource gibt. Sind es mehrere, führt auch dieser Weg in den Abgrund. Das ist dann der Moment, an dem ein RTOS zum Mittel der Wahl wird.
> Nein, das Einzige, wofür "Polling" wirklich sinnvoll ist
Nö.
Polling ist für alle Signale genau die passende Lösung,
bei der das Eingangssignal nicht zu schnell erfasst werden darf,
beispielsweise ein Taster der prellt oder ein Inkrementalgeber,
oder bei Temperatursensoren wo man auch nicht im zehntelsekundenabstand
die Heizung schalten will.
Schiko schrieb: > Wenn Du von "Deiner" Firma sprichst, höre ich daraus, Du seist der Chef. Wenn du von "deinem" Nachbarn sprichst, dann heisst das, er gehört dir? Deutsche Sprache, schwere Sprache...
Reinhard Kern schrieb: > EGS_TI schrieb: >> Leider fehlt mir vermutlich auf Grund fehlender Ausbildung die Kompetenz >> hier was zu sagen. > > Leider ist das sehr wahr. Timer-ISR ist nicht nur generell eine > geeignete Lösung für solche Aufgaben, genau genommen arbeiten > Betriebssysteme immer so, besonders moderne mit präemptivem > Multitasking, da passiert praktisch alles in ISRs. Was dachtest du denn > wie ein Thread/Task einer Windows-Anwendung zur Ausführung kommt? > > Gruss Reinhard Ja is mir schon klar. Nicht nur präemptive Scheduler sondern auch kooperative nutzen natürlich einen Timer um eine Zeitbasis zu generieren. Nur, kann man das auch viel übersichtlicher, wartbarer, vorhersagbarer und erweiterbar-barer machen, was ich von einer professionellen Firma erwarten würde.
MaWin schrieb: > Nö. > > Polling ist für alle Signale genau die passende Lösung, > > bei der das Eingangssignal nicht zu schnell erfasst werden darf, > beispielsweise ein Taster der prellt oder ein Inkrementalgeber, Da sehe ich keinerlei Notwendigkeit, das als polling in einer busy-loop abzuhandeln. Da würde ich vielmehr in der ISR für die Pegeländerung einen Timer starten und in dessen ISR das Endergebnis ermitteln. Die ganzen 50 oder 100ms dazwischen könnte die MCU entweder sinnvollen anderen Aufgaben widmen oder stromsparend schlafen. > oder bei Temperatursensoren wo man auch nicht im zehntelsekundenabstand > die Heizung schalten will. Wenn man nur alle zwei Minuten die Heizung schalten will, dann pollt man nicht dümmlich, sondern handelt das in einer Timer-ISR ab, die eben nur alle zwei Minuten auftritt. Die ganzen anderen Millionen Takte dazwischen läßt man die MCU schlafen. Du hast wahrscheinlich nicht verstanden, was ich mit "Polling" meine. Das ist natürlich Polling in Form einer busy-loop. Polling im allgemeineren Sinn wird es natürlich immer geben müssen, schon deshalb, weil selbst viele Interruptquellen nur dann funktionieren, wenn zumindest auf Hardware-Ebene gepollt wird.
Am Anfang schien es aber so, als sei alles in der ISR. Nachträglich stellte sich nach genauerer Betrachtung heraus, dass ich etwas übersehen hatte. Somit war die anfängliche Annahme falsch.
owe...wie schon mehrfach hier geschrieben..in erster Linie geht es doch wohl darum ob die Software ordentlich das tut was sie soll..ich kenne genug Schlaumeier die meinen Code Bilderbuchmäßig aufhübshcen könnten..die bekommen schon nen Lachkrampf weil alles in PAscal geschrieben ist..dumm nur das ich damit gut mein geld verdiene und die nicht :-) Wenn davon auszugehen ist, das nicht ständig an der Sotware rumgedoktort wird, ist die Wartbarkeit doch wohl ebenfalls nebensächlich..wenn dafür das Projekt schneller verkaufsfertig ist..raus damit...den code sieht niemand mehr..wichtig ist das alles gut läuft!
@ Rolf (Gast) >owe...wie schon mehrfach hier geschrieben..in erster Linie geht es doch >wohl darum ob die Software ordentlich das tut was sie soll.. Eiegentlich schon, aber . . . >ich kenne >genug Schlaumeier die meinen Code Bilderbuchmäßig aufhübshcen >könnten..die bekommen schon nen Lachkrampf weil alles in PAscal >geschrieben ist.. Sollen sie doch halt lachen. >Wenn davon auszugehen ist, das nicht ständig an der Sotware rumgedoktort >wird, Das gilt nicht für alle Softwareprojekte. Je größer, um so wahrscheinlicher ist eine längere Wartung. > ist die Wartbarkeit doch wohl ebenfalls nebensächlich..wenn dafür >das Projekt schneller verkaufsfertig ist..raus damit...den code sieht >niemand mehr..wichtig ist das alles gut läuft! Wenn es denn gut läuft, OK. Aber oft ist schlechter Code auch nicht sonderlich stabil bzw. läuft nicht wie gewünscht. Und dann muss die Wartung her. Und schon sind alle Annahmen im Eimer . . .
> Die Wahrheit ist oft grauenvoll.
Grauenvoll? Meiner Erfahrung nach ist es noch viel schlimmer!
Aber schau mal die Praxis an:
- Termindruck: Software kommt (je nach Branche) immer als letztes.
Dann sind schon alle Zeitreserven aufgebraucht und der
Liefertermin war letzte Woche.
- Budgetüberschreitung: Jedes Projekt übersteigt seinen
finanziellen Rahmen. Jede Stunde, jeder Tag den der
Software-Mensch länger braucht, läuft der Gebührenzähler.
Und der läuft schnell, sehr schnell. Geht alles vom Gewinn
weg, nicht vom Umsatz. Und diese Decke ist dünn, sehr dünn.
- Änderungen: Am Ende sieht jedes Projekt anders aus, als
es geplant wurde. Die Software muss dann die ganzen Ad-Hoc-
Änderung der Elektrik und Mechanik auffangen. Ob die Änderungen
ins Gesamtsystem passen, ist das Problem der Software...
- Überlastung: Der Software-Mensch mach ständig etwa eine Millionen
Dinge gleichzeitig. Kunden rufen an, Mitarbeiter schneien ins
Büro, Projektbesprechungen. Und überall ist der Termin schon
gefährdet.
- Fehlendes Sachverständnis: Kein Nicht-Software-Mensch versteht
auch nur irgendetwas von Software. "Ist doch gleich wie das
letzte mal, nur kleine Änderungen. Kannst Du das nicht einfach
kopieren?", oder: "Wieso dauert das so lange? Mit Excel geht
das ganz schnell und einfach".
- Katastrophale Werkzeuge: Schau sie an, die ganzen Compiler,
die Bauteil-Doku, die Parametriersoftware, die ganzen Tools
und die Betriebssysteme: Jedes funktioniert anders, hat Tonnen
von Bugs, arbeitet nicht mit den anderen Teilen zusammen,
ändert sich ständig (neue Versionen etc.).
Was vor sechs Monanten noch problemlos ging, funktioniert
plötzlich nicht mehr, weil man jetzt erst mal drei mal nach
Mekka beten muss, bevor das Tool wieder geht.
- Kunden: "Ich hab nichts gemacht..."
Und so geht es weiter. Es gibt eben einen großen Unterschied, zwischen
harter Realität, der Praxis, und den Elfenbeinturm der Lehre.
Rolf schrieb: > Wenn davon auszugehen ist, das nicht ständig an der Sotware rumgedoktort > wird, ist die Wartbarkeit doch wohl ebenfalls nebensächlich..wenn dafür > das Projekt schneller verkaufsfertig ist..raus damit...den code sieht > niemand mehr..wichtig ist das alles gut läuft! Und du verdienst dein Geld ernsthaft mit Software, die verkauft werden soll? Kaum vorstellbar. Wäre aber zumindest eine Erklärung für die Qualität manher Produkte. Was machst du, wenn plötzlich ein Bug auftritt? Alles neu schreiben, weil es schneller geht, als den alten Code nachzuvollziehen? Was, wenn der Code zertifiziert werden soll (interessant bei Sicherheitsrelevanten Branchen)? Aber klar, Hauptsache es funktioniert und nach mir die Sintflut.
Ein Code mit Doku ist schätzungsweise 1,3 mal so teuer wie ein Code ohne Doku. Und selbst mit der 1,3 Doku muss sich ein Außenstehender erst einige Zeit hineindenken. Für kleinere Problemstellungen könnte ich eine Software ohne Doku verschmerzen. Und auch für größere Software, wenn ich weiß das in ca. 5 Jahren sowieso ein Nachfolgeprojekt geplant ist. Du musst das mal aus sicht deines Chefs sehen. Das Geld was der Softwaremensch verbraucht ist SEIN entgangener Gewinn! Also jede Stunde eine Hotelübernachtung weniger, jede 3 Stunden einen Bordellbesuch weniger - je nach dem wie dein Chef drauf ist. Das da ein gewisses Pokerfeeling mitschwingt streite ich nicht ab, Folgekosten durch Bugfixing werden auch gerne ausgelbendet.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.