Informatiklehrer



  • SirLant schrieb:

    Ich pers. hasse Struktogramme wir müssen sie immer in der Schule machen, die Aufgaben
    dort sind leider nur so billig, dass es in meinen Augen Zeitverschwendung ist,
    denn in Java prozedural zu coden, ist ja jetzt nicht _so_ schwer, dass ich mir
    über das Design Sorgen machen muss.

    Struktogramme sind überflüssig. Ganz einfach, weil man die meisten Fehler eh erst beim Ausführen des Programmes (im Einzelschritt-Modus eines Debuggers) erkennt und nicht beim Aufhängen des Struktogramms an der Wand. Und lesbarer als ein gut formatierter (!) und kommentierter (!) Java-Quelltext sind sie sicher auch nicht. Struktogramme stellen ja gegenüber Hochsprachen keine Vereinfachung dar, da die Hochsprachen im Prinzip die gleichen Kontrollstrukturen haben wie Struktogramme, mit dem Vorteil, gleich richtigen Code zu haben.

    SirLant schrieb:

    Komischerweise tun sich alle anderen in der Klassen mit Struktogrammen schwerer,
    als direkt das ganze einzutippen, unser Lehrer meint zwar, dass man sich nen
    Struktogramm machen soll, wenn man nicht weiß wie man etwas angeht, aber hier
    ist wohl nen Blatt Papier und ein paar Stichworte was man machen möchte genauso
    hilfreich.

    Klar, man kann so etwas tun, was für das Problem angemessen erscheint. Baumstrukturen entwirft man z.B. besser, wenn man den Baum kurz skizziert und nicht, wenn man gleich versucht, den Algorithmus als Struktogramm zu malen. In dem Moment, wo man ein Struktogramm malen kann, kann man doch gleich den Code in den Rechner eintippen.



  • SirLant schrieb:

    Komischerweise tun sich alle anderen in der Klassen mit Struktogrammen schwerer, als direkt das ganze einzutippen,

    und man fragt sich, warum sie nicht dürfen.

    unser Lehrer meint zwar, dass man sich nen Struktogramm machen soll, wenn man nicht weiß wie man etwas angeht,

    wenn man zu ahnunslos ist, muß man es ausprobieren. und das geht nirgends so gut, wie am rechner.
    wenn man in sachen klassendesign zu ahnungslos ist, muß man auch erstmal ein gefühl für das genre kriegen. durch ausprobieren am rechner.

    aber hier ist wohl nen Blatt Papier und ein paar Stichworte was man machen möchte genauso hilfreich.

    auch du bist schon verloren. es ist eben schlecht, vorher "DEN PLAN" hinzuschreiben und dann den zu coden. "DER PLAN" muss beim coden entstehen.

    Volkard, wie machst du das bei komplexeren Vererbungsbeziehungen,

    es gibt keine komplexen vererbungsbeziehungen. klar muß man dazu private erblichkeit meiden und noch zwei oder drei regeln einhalten, die aber klar in "effektiv c++ programmieren" stehen.

    hast du das dann irgendwie im Kopf, oder machst du dir vorher auf nem Blatt ne grobe Skizze, bzw. schreibst auf wie die zusammenhängen?

    normalerweise keine skizze. manchmal ein baum, in dem aber nur klassennamen vorkommen und sonst nix. und nicht als planung, sondern als test, ob sich ne idee gut anfühlt. nach angucken des baumes kann das blatt verbrannt werden.

    Denn immerhin sind die Kinder, ja abhängig von den Parents und die Basisklasse, muss ja so designed werden, dass die Kinder sie optimal einsetzen können.

    NEIN! die Basisklasse muss nicht und darf nicht so designed werden, daß die kinder sie optimal einsetzen können. der mensch denkt in begriffen. deswegen soll er auch in begriffen programmieren. das ist ne frage der wartungsfreundlichkeit. die basisklasse muss ein kapierbarer begriff sein. sie muss *einen* zweck erfüllen und einen sie exakt beschreibenden namen haben. außerdem soll sie performant sein. wen sie einen zweck hat und einen guten namen, lebt sie eigenständig und es ist irrelevant, wer sie verwendet.
    trotzdem passieren regelmäßig sachen, wie daß man gleichbedeutende members in childs findet. schwups, hoch damit in die basisklasse. uml-heinis würden sagen, das sei auf den bildern frher zu sehen gewesen. aber nein, noch häufiger als das, passiert es ja, daß man nachträglich members einfügt.
    ich lasse sogar attribute (manchmal) und methoden (immer) weg, solange keine andere klasse sie braucht und baue erst bei bedarf nach.
    es ist meinen klassen aber fast immer egal, wer von ihnen mal erben möchte, und was der tun will. außer mal, sie heißt "...Base", veröffentlich eine pur virtuelle methode und hat ein attribut.

    also nix plan vorher. es wächst schon in die richtige richtung. normalerweise ist der plan im kopf gleich da und ich könnte alle klassen und attribute und vererbungsbeziehunen sofort hinschreiben. öffentliche methoden dauern etwas länger. und wenn nicht, dann hilft auch kein überlegen. dann hilft nur ausprobieren, welche der alternativen sich "hübscher" anfühlt. dabei denkt man aber über fallen nach, die sich erst in 6 monaten auftun würden. sehr spekulatives eschäft. gegebenenfalls muss ich mehrere entwürfe ein paar tage lang vorantreiben und dann den enstandenen code bewerten.
    es bleibt mir gar keine andere wahl, wenn ich nur den besten code haben mag. manches läßt sich trocken einfach nicht abschätzen.

    edit: schaut mal, welch schweren stand ich habe, wenn ich euch hier erzählen will, daß der explorative programmierstil wirklich wirkungsvoll ist, aber auf der anderen seite das böse solches "c++" lehrt: http://forum.c-plusplus.net/viewtopic.php?t=73371&highlight=



  • volkard schrieb:

    aber hier ist wohl nen Blatt Papier und ein paar Stichworte was man machen möchte genauso hilfreich.

    auch du bist schon verloren. es ist eben schlecht, vorher "DEN PLAN" hinzuschreiben und dann den zu coden. "DER PLAN" muss beim coden entstehen.

    Hm, d.h. du machst dir nie Notizen um deine Gedanken zu ordnen? Finde sowas, manche
    machen sowas auch als Mindmap, ziemlich effektiv, da man sich sonst zu leicht in
    den Gedanken verstrickt, geht mir jedenfalls so.



  • Hallo,
    bei dem Gedanken daran einen komplizierten Automaten zu implementieren ohne mir vorher ein Zustandsübergangsdiagramm zu skizzieren wird mir schwindelig. Ich versuche das zwar immer wieder, jedesmal kommt aber totaler Müll dabei raus. Tausche ich hingegen einfach mal Tastatur gegen Stift und Papier und mal ein zwei Stunden vor mich hin, dann kommt in der Regel ein brauchbarer Grobentwurf bei raus. Während des Programmierens stolpere ich dann über bis dato nicht berücksichtigte Spezialfälle, die sich dann aber einfacher integrieren lassen, da der Grobentwurf steht.
    Ähnliche Erfahrungen habe ich auch mit Klassen, deren Aufgaben und Schnittstellen gemacht. Ohne Grobentwurf wird es ein großer Haufen ohne Struktur. Aber egal wie lange man vorher plant und malt und denkt, sobald man programmiert stolpert man über Probleme, die man vorher nicht gesehen hat.

    Wie machst du das?

    Und zum Thema Klassen:
    Du benutzt nicht mal sowas wie CRCs? Nichts? Natürlich sollen Klassen genau eine wohldefinierte Aufgabe erfüllen, aber mir kommt es so vor, als würdest du sagen, dass Klassen immer im Vakuum existieren können müssen (sprich: Jede Klasse macht sinn auch wenn sie in Isolation betrachtet wird).
    Das scheint mir aber nur in absoluten Ausnahmefällen der Fall zu sein (für so Dinge wie Containerklassen). Ansonsten hat man imo viel häufiger Verbände von Klassen, deren Objekte irgendwie kollaborieren um gemeinsam eine Aufgabe zu erfüllen (nicht umsonst hat besteht jedes DP aus mehr als einer Klasse).
    Hier helfen mir CRCs oder auch Diagramme die die Kommunikation zwischen Objekten verdeutlichen ungemein. Code ist dazu imo viel zu Detailbeladen. Da mache ich lieber einen Schritt zurück und schaue mir das ganze im Überblick an.

    Ich gehöre zwar keinesfalls zu den UML-Fans und ich bin auch keinesfalls der Meinung, dass der Richtige Weg(tm) über Use-Case, Use-Case-Digramm, Aktivitätsdiagramm, Aspekt-Modelle und zugehörige Integrations-Modelle usw. geht (so wie man es mir in Softwarekonstruktion beigebracht hat), aber so ein bischen Planen (ohne Code und Computer) scheint mir nicht verkehrt.

    Am Besten hat bei mir bisher eine Kombination aus Use-Cases bzw. Szenarios (damit ich weiß *was* ich überhaupt für ein Problem lösen will), CRCs (Grobentwurf der Klassen) und Test-Driven-Development (Schnittstellen, Kommunikation, erkennen von widerlichen Abhängigkeiten) funktioniert. Wobei ich letzteres noch nicht so perfekt hinbekomme (insbesondere nicht, wenn ich mir vorher nicht wenigstens ein paar Gedanken über die Grundstruktur mache).
    Und wenn ich für mich komplizierte Algorithmen (also komplizierter als eine Zählschleife von 1 bis 10) implementieren muss, dann brauche ich immer eine Menge Papier und einen Stift. Ohne Kreise, Kugeln, Pfeile, Wertelisten, kritzelige Berechnungen über Randfälle usw. wird das bei mir sonst nichts 🙂



  • der algo für wpc112 http://www.geocities.com/acmesofties/wpcq.htm ist sicherlich als kompliziert anzusehen. und mit genuss warf ich die ide an und tippte drauf los. erstmal den funktionsrumpf und dann

    while(
    

    dort am ende der zeile darf der cursor dann ein paar phasen lang blinken und ich überlege mir, wie es weiter geht.
    wenn ich fertig bin, werden zwei a5-zettel mit test-daten draufgegangen sein.

    klassen sind aber ganz anders kompliziert. da muß man nicht sowas verknotetes wie komplizierte schleifen machen, sondern arbeitet mit inhalten und bedeutungen. und gemeinerweise erschließt sich die genaue bedeutung manchmal erst genau, wenn die klasse schon seit drei wochen lebt. zum glück hat diese eigenschaft mir noch kein projekt gekippt. nee, kann ja nicht. ich sehe ja gleich, welche klassen projektentscheidend sind und die treibe ich voran. ok, ich würde niemals sachen machen, wie private zu erben, um ne konstruktorreihenfolge zu erzwingen. mag sein, daß ich deswegen normalerweise keine klassen malen muß.
    daß du sagst, du machst klassen, die nur im zusammenspiel mit anderen sinn ergeben (mal von iteratoren und zum model passenden views abgesehen), erstaunt mich. ich hab den eindruck, das kommt nicht vor. muss mal dahingehend die augen offen halten.



  • Sehr schön volkard. Bei der Seite springt mein Virenscanner an, dass in das temporär Verzeichnis des IE ein Virus runtergelanden wurde beim Aufruf der Seite. 🙄



  • Luckie schrieb:

    Sehr schön volkard. Bei der Seite springt mein Virenscanner an, dass in das temporär Verzeichnis des IE ein Virus runtergelanden wurde beim Aufruf der Seite. 🙄

    omisch. bei mir wird da nix gemeldet. ob das daran liegt, daß ich keinen virenscanner mitlaufen lasse?
    welcher virus isses denn? würde den gerne auf meiner platte sehen und gegebenenfall sogar entfernen.



  • omisch. bei mir wird da nix gemeldet. ob das daran liegt, daß ich keinen virenscanner mitlaufen lasse?

    Was soll dir denn in diesem Fall bitte den Virus melden? 🙄

    VBS-Scriptvirus VBS/Redlof.A.



  • SirLant schrieb:

    Hm, d.h. du machst dir nie Notizen um deine Gedanken zu ordnen? Finde sowas, manche
    machen sowas auch als Mindmap, ziemlich effektiv, da man sich sonst zu leicht in
    den Gedanken verstrickt, geht mir jedenfalls so.

    Ist wohl gewöhnungssache. Hab sowas auch nie gemacht und gehe stattdessen immer über die Prozedur:
    a) Zigarette rauchen und das Problem analysieren
    b) drauflos-hacken ohne Gnade
    c) Zigarette rauchen und den Code analysieren 😃

    Ich glaube die wenigsten (vor allem professionelle Programmierer mit dem Release-Plan im Nacken) haben die Zeit, sich vorher alles in PAP's, Struktogrammen oder Mindmaps auszudenken.


  • Mod

    Cpp_Junky schrieb:

    Ich glaube die wenigsten (vor allem professionelle Programmierer mit dem Release-Plan im Nacken) haben die Zeit, sich vorher alles in PAP's, Struktogrammen oder Mindmaps auszudenken.

    Dazu fällt mir ein, daß 98% aller Softwareprojekte unpünktlich sind. Ob da ein Zusammenhang besteht?

    Eine Person mag noch im Loshacken ein Projekt beginnen können, mir ist aber schleierhaft wie man mit 3 oder 4 Personen ein Softwareprojekt beginnen kann, ohne vorher mal über Entwürfe, Ideen und Zerlegungen diskutiert zu haben. Und diese auch festzuhalten. Nicht als Wegplanung zur konkreten Ausprogrammierung, aber einfach als ungefähre Richtlinie, als roter Faden. Es verlangt doch keiner eine 1:1 Umsetzung, natürlich wird's Abweichungen geben im Verlauf der Programmierung. Aber wer wo startet, das muß man doch festlegen.

    Ich weiß, daß viele Firmen das nicht tun, selbst bei Projekten mit 6-7 Personen gibt's keinerlei Grobpläne für die Software. Hinterher werden dann noch Schnittstellen in "fertige" Teile reingehackt, damit alles überhaupt miteinander kommunizieren kann.



  • Ja is schon klar, das man irgendwo festhält wie in etwa man die Sache angeht. Vor allem bei grossen Projekten mit mehreren Programmierern. Aber glaubst du im Ernst die pinseln sich ihre Ideen erst mit PAP's o.ä. zusammen ? Kann ich mir beim besten Willen nicht vorstellen.


  • Mod

    Ich weiß nicht, warum Ihr Euch an den PAPs aufhängt - diese Analogie PAPs/Struktogramm vs. UML hinkt gewaltig. PAPs sind was im Kleinklein, aber davon sprechen wir hier nicht. UML umfasst auch PAPs und Struktogramme, wenn man will - aber eigentlich geht's hier mehr um Use-Cases oder Klassendiagramme.

    Dieser Analogieschluß will mir nicht in den Kopf - weil ein Mittel für das Kleinklein veraltet ist und wenig bringt, ist auch ein Mittel für das Großgroß wenig sinnvoll? Das ist doch nicht linear extrapolierbar.

    Ich habe noch nie jemanden in der Praxis gesehen, der PAPs verwendet.

    Aber wenigstens eine erste Zerlegung von vorhandenen Themen, Abläufen und Objekten? Das schon. Alleine damit man sagen kann "A macht das, B macht das, usw".

    Und dafür ist UML als einheitliche Sprache doch ganz nett - solange man nicht in die Tiefen von UML 2.0 absteigt UND die Freiheit lässt, diese ersten Ideen im Laufe der Entwicklung auch zu variieren.



  • Marc++us schrieb:

    Aber wenigstens eine erste Zerlegung von vorhandenen Themen, Abläufen und Objekten? Das schon. Alleine damit man sagen kann "A macht das, B macht das, usw".
    Und dafür ist UML als einheitliche Sprache doch ganz nett

    warum nicht c++?



  • Marc++us schrieb:

    Dieser Analogieschluß will mir nicht in den Kopf - weil ein Mittel für das Kleinklein veraltet ist und wenig bringt, ist auch ein Mittel für das Großgroß wenig sinnvoll? Das ist doch nicht linear extrapolierbar.

    vorhin haste noch gesagt: ich zwinge meine leute mit uml, sich VORHER nen plan zu machen, damit sie nicht so unüberlegt rangehen. das ist genau der struktogramme-fehler!

    und von anderen höre ich, daß sie auch algos vorher planen. die wissen evtl nicht, was sie sich damit antun. ich hab bei wpc112 mal mitgeschrieben, wie es gelaufen ist und man sieht krass, daß vorherige planung unfug gewesen wäre. (kann es leider schlecht hier posten vor dem einsendeschluss.)

    und genauso ist es bei klassen auch. an der herangeensweise ist zwischen dem entwerfen von algos und dem von klassenverbänden kein riesiger unterschied. der unterschied ist nur, daß man bei algos von der test-suite bei fehlern sofort abgestraft wird, bei klassen erst nach monaten vom terminplan und den magengeschwüren.

    Aber wenigstens eine erste Zerlegung von vorhandenen Themen, Abläufen und Objekten? Das schon. Alleine damit man sagen kann "A macht das, B macht das, usw".

    das ist ne andere schiene. dafür ist c++ mit auslassungen ganz nebenbei ne hochgeeignete sprache. hab da aber auch gute erfahrungen damit, daß man einfach inhaltlich trennt und mindestnes die erste woche im selben büro arbeitet. schnittstellenverhandlungen geschehen unter profis so:
    "ich muss bei dir gucken können, welche dateien du verändert hast"
    "magste nen vector?"
    "jo"
    "kriegste"
    und sofort ne mail dahinter (ja, per mail über die usa kommuniziert man mit seinbem tischnachbarn . mit der neuen header-datei.)
    nervig wirds nur, wenn sender oder empfänger nix können, und das hab ich auch erlebt. da musste die dame bildunterschriften kriegen und man sagt ihr: such dir irgendein format aus, kriegst. sie konnte sich nix aussuchen. man sagt "kannste vector<pair<int,string> > (x-kordinate der textmitte, text) gebrauchen?". sie sagte, das könne sie nicht verarbeiten, aber machte keinen besseren vorschlag. die software hing und sate, der sender sei nicht kooperativ.



  • Ich bin ja auch nicht gerade ein Fan von UML, PAPs, Struktogrammen, Netzplänen usw. und trotzdem finde ich es wichtig, dass man zumindest eine Grobplanung auf Papier in einem größeren Projekt hat. Es geht da einfach nicht ohne, ansonsten endet alles in einem großen Chaos. Schließlich ist dieses vorherige Skizzieren eine Art Dokumentation.

    @volkard
    Ich hoffe du wirst niemals ein Haus bauen.

    @thema lehrer
    Warum hackt ihr eigentlich immer auf diese Informatiklehrer rum? Seid ihr vielleicht schon mal auf die Idee gekommen, dass die das vielleicht gar nicht studiert haben?

    So in etwa läuft es nämlich tatsächlich ab:
    Herr Müller ist ca. 40 Jahre alt und Lehrer an einer Schule. Sein Hauptfach ist Mathematik. Eines Morgens zitiert ihn sein Direktor in dessen Büro.
    Direktor: "Hallo Herr Müller. Sie sind ja unser Spezialist in mathematischen Angelegenheiten."
    Müller: "Naja ich habe hald Mathematik als Lehrfach studiert."
    Direktor: "Ich habe in Ihrer Akte gelesen, dass Sie als Wahlfach auch etwas Informatik hatten."
    Müller: "Ja, das war ein Semester lang."
    Direkter: "Sie kennen sich doch auch mit Computern aus."
    Müller: "Naja, ich mache privat ein wenig was mit dem Computer."
    Direkter: "Gut, dann sind Sie ja genau der richtige Mann für unser neues Fach Informatik. Sie haben jetzt eh die ganzen Sommerferien Zeit sich etwas einzuarbeiten. Im neuen Schuljahr haben Sie dann auch das Fach Informatik."
    ...

    Schimpft also nicht so einfach drauf rum, denn die können meistens selber nichts dafür, dass sie den Posten draufgedrückt bekommen haben.



  • AJ schrieb:

    Ich bin ja auch nicht gerade ein Fan von UML, PAPs, Struktogrammen, Netzplänen usw. und trotzdem finde ich es wichtig, dass man zumindest eine Grobplanung auf Papier in einem größeren Projekt hat. Es geht da einfach nicht ohne, ansonsten endet alles in einem großen Chaos. Schließlich ist dieses vorherige Skizzieren eine Art Dokumentation.

    und was bringt es, was vorher zu dokumentieren, was man nachher nicht haben will?
    je früher und je exakter festlegungen sind, desto schlechter wird das ergebnis.
    je bereiter man ist, festlegungen und code (auch mal dutzende von seiten) wegzuschmeißen, desto besser wird das ergebis.
    dem gegenüber steht, daß es im team auch nachteilhaft sein kann, wenn die linke hand nicht weiß, was die rechte tut.
    dem versucht man durch frühe festlegunen entgegenzuwirken.
    aber es bleibt ein zielkonflikt. man muss kompromisse eingehen und leider teilweise früh festlegen und dabei auf die top-code-quali zum teil kacken.

    ihr mußt das so sehen: jede frühe festlegung schadet. man darf sie nur in kauf nehmen, um schlimmere gefahren abzuwenden. man darf auf keinen fall einfach so aus lust und laune alles mal festlegen, wie AJ es zu mögen scheint.

    @volkard
    Ich hoffe du wirst niemals ein Haus bauen.

    Ich hoffe, du wirst niemals Software bauen.



  • Heute hatten wir wieder IT und wie haben heute mit OOP angefangen und natürlich auch UML
    bin mal gespannt was mich in Zukunft erwartet 🤡

    Volkard ich kann mir echt nicht vorstellen, wie du in nem 20 Mann Team (oder auch weniger)
    zusammen ne Software entwickelst, ohne jegliche Absprache, ihr müsst doch schon
    nen Konzept haben bevor ihr anfangt, woher weiß sonst jeder was er machen soll?


  • Mod

    volkard schrieb:

    Marc++us schrieb:

    Aber wenigstens eine erste Zerlegung von vorhandenen Themen, Abläufen und Objekten? Das schon. Alleine damit man sagen kann "A macht das, B macht das, usw".
    Und dafür ist UML als einheitliche Sprache doch ganz nett

    warum nicht c++?

    Weil die dann sofort ständig anfangen zu compilieren. Bevor man sich umsieht, stehen die ersten Variablen bereits im private-Teil. Damit kann man aber nicht anfangen, wenn man noch Zerlegungen diskutiert.

    Das UML dient nur zur Verhinderung dessen, daß mit einem Detail losgehackt wird, weil der Compiler zu früh aktiviert wird.

    Weiterhin hatte ich oft die Situation, daß 3 Leute vor einer Tafel stehen und mit einem Edding bewaffnet eine Sache diskutieren. Wenn man nun die Notation "C++" verwendet findet sich immer ein Brettlesbohrer, der plötzlich einwendet "da fehlt noch ein Strichpunkt". S***** doch auf den Strichpunkt zu diesem Zeitpunkt. Trotzdem hängen sich die Leute daran auf. Sobald man eine Sprache als Beispiel verwendet, macht es *klick* und die Masse der Entwickler denkt nur noch in Implementationsdetails. Oder wenn man eine Klasse skizziert und es kommt die Frage "der Copycon wird aber private gemacht, oder?". Ja, brav, hast Du gut Scott Meyers gelesen und auswendig gelernt. Aber das interessiert doch zu dem Zeitpunkt gar nicht.

    Daher die Wahl einer Notation, die nicht so leicht in Implementationen abrutschen kann.

    Und weiterhin hat's noch einen Effekt - Kostenplanung. Wenn ich ein Diagramm mit 40 Klassen habe und lauter Linien dazwischen, drucke ich das auf A3-Blättern aus und gehe damit zu einem Betriebswirt. Dann sage ich, daß jedes Kästchen auf dem Bild ca. 25 Stunden Arbeit sind und verlange dafür ein Budget. Man stelle sich die gleiche Situation vor, wo ich mit 40 Headern mit C++-Pseudocode zu dem Mann gegangen wäre - niemals wäre das so einfach durchgekommen. [Ich nenne das auch "fuck the fakers"-Methode]

    In meinen Augen hilft UML (wobei ich auch was anderes nehmen würde, vor 8 Jahren habe ich Booch genommen) dabei, real auftretende Probleme der Softwarewelt mit real exisitierenden Entwicklern zu lösen. Daher fällt es bei mir in die Schublade "brauchbares Hilfsmittel".



  • volkard schrieb:

    ihr mußt das so sehen: jede frühe festlegung schadet. man darf sie nur in kauf nehmen, um schlimmere gefahren abzuwenden. man darf auf keinen fall einfach so aus lust und laune alles mal festlegen, wie AJ es zu mögen scheint.

    Falsch. Ich persönlich mache es privat so wie du. Ich hab ne Idee ein paar Vorstellungen im Kopf und programmier munter drauf los. Später werf ich dann sowieso alles wieder um.
    Allerdings kann man sich sowas im Job nicht so einfach leisten, besonders nicht in größeren Projekten. Eine grobe Planung ist ohne Grobkonzept unmöglich (wie Marc++us auch schon angedeutet hat mit seinem Beispiel). Allerdings ist nicht jeder Kunde so naiv, wartet bis das Projekt endlich mal fertig programmiert ist und zahlt dann horense Summen für die Entwicklung.

    Vielleicht reden wir auch etwas aneinander vorbei. Es ist sicherlich sinnlos die Software vorher komplett (Feinkonzept) auf dem Papier zu entwickeln, aber zumindest die Richtlinien (Grobkonzept) sollten vor der Implementation vorhanden sein.

    Schreibst du eigentlich Pflichtenhefte oder Spezifikationen, wenn du einen neuen Auftrag erhältst? (Klingt nämlich bisher nicht so)

    @volkard
    Ich hoffe du wirst niemals ein Haus bauen.

    Ich hoffe, du wirst niemals Software bauen.

    Zu spät! :p



  • AJ schrieb:

    Schreibst du eigentlich Pflichtenhefte oder Spezifikationen, wenn du einen neuen Auftrag erhältst? (Klingt nämlich bisher nicht so)

    nö, ich darf machen, was ich will. ich gebe nen auftrag gut ab, um den nächsten auftrag zu kriegen. und der chef zahlt gut, um mich für den nächsten auftrag zu bekommen. manchmal ist vorher nichtmal kalr, um was es überhaupt geht.


Anmelden zum Antworten