Werde für Projekte im Bereich Anwendungs-Programmierung abgelehnt.

TomH22 schrieb:
Das ist Quatsch. Zwischen "Programmierung" und "Entwicklung" gibt es keinen Unterschied.
Das ist nicht das selbe. Entwicklung umfasst die ganzen Schritte der Planung wie Anwendungsfallbeschreibung, Anwendungsfalldiagramm, Sequenzdiagramm.. . In meinem Studium wurde auch explizit zwischen Software engineering und Programmierung unterschieden.
 
  • Gefällt mir
Reaktionen: mrhanky01
downforze schrieb:
Entwicklung umfasst die ganzen Schritte der Planung wie Anwendungsfallbeschreibung, Anwendungsfalldiagramm, Sequenzdiagramm
Ja, wenn man schön formal nach UML mit allen seinen barocken Strukturen vorgeht ist das vielleicht so. Heute arbeiten die meisten Projekte mit agilen Methoden, da gibt es keine formale Trennung zwischen Entwurfs- und Implementierungsphasen mehr.
Nicht umsonst schreibt das Agile Manifesto https://agilemanifesto.org/
"Individuals and interactions over processes and tools
Working software over comprehensive documentation"

Agile ist nun natürlich auch nicht der heilige Gral und hat zu neuen Problemen geführt, und gerade beim Thema "Processes and Tools" haben Methoden wie Scrum ihre eigenen barocken Strukturen übernommen.
Aber sie haben die Denkweise beim Entwickeln von Software schon deutlich geändert.

Eine schöne Anekdote von 2012, als ich eine leicht in der Krise steckenden Entwicklungsabteilung übernommen habe: Damals gab es ein Projekt, da hatte die Abteilung Monate an einer Spezifikation gearbeitet und hatte dabei schon weit über 50% des Gesamtbudgets für das Projekt gebraucht und noch nicht eine Zeile Code geschrieben. Als ich die Entwickler fragte, wo sie denn gefühlt im Projekt stehen, sagten sie "ja wir sind zu 50% fertig, denn wir haben 50% des Budgets verbraucht und sind planmäßig mit der Spezifikation fertig".

In Wirklichkeit war die Spezifikation unbrauchbar, da die Entwickler leider einen erheblichen Teil der fachlichen Anforderungen nicht verstanden hatten. Der reale Projektfortschritt lag so in der Nähe von 0%.

Mittlerweile ist es bei uns so, dass wir nur "Working Software" als Maß für den Projektfortschritt nehmen. Das Ziel ist in jedem Sprint eine "funktionsfähiges" Stück Software abzuliefern. Am Anfang hat die Software dann natürlich nur wenige Features, aber das Featuresset ist in sich funktionsfähig. Non-Software Artefakte (wie z.B. User Stories ) stellen für sich keinen Wert dar.

downforze schrieb:
In meinem Studium wurde auch explizit zwischen Software engineering und Programmierung unterschieden.
Das ist auch absolut ok, genauso wie alle anderen Disziplinen/Phasen innerhalb der Softwareentwicklung, wie etwas UX/UI Design, Deployment, Testing, usw. ). Nur gibt es niemanden der, genau wie Du in Deinem Studium, nicht alle diese Disziplinen lernt und in der Regel auch grundlegend beherrscht. In einem Team kann man sich spezialisieren, und je größer das Team, um so mehr Spezialisierung.
Aber ich kenne keinen Programmierer der nur Code schreiben kann und nicht auch die anderen Disziplinen beherrscht. Genauso kann ein Architekt seine Aufgabe nicht sinnvoll ausführen, wenn er nichts von Coding versteht.

Der Auslöser für mein Post war, das jemand "Entwickler" und "Programmierer" als formal unterschiedliche Begriffe sehen wollte. Und das halte ich für Quatsch. Beide Begriffe sind unscharf definierte Alltagsbegriffe. Früher (bis ca. in die 80er) war Programmierer weiter verbreitet, heute sagt man mehr Entwickler. 1986, als ich an der Uni anfing, hießen die Anfänger Vorlesungen noch "Programmierung 1" und "2". Bei meiner Tochter, die 2018 angefangen hat, hießen sie "Softwareentwicklung 1" und "2". Damals war es Pascal, heute Java, aber inhaltlich hat sich nicht so viel geändert.
 
Zuletzt bearbeitet: (typos)
TomH22 schrieb:
Heute arbeiten die meisten Projekte mit agilen Methoden, da gibt es keine formale Trennung zwischen Entwurfs- und Implementierungsphasen mehr.
Die Welt besteht nicht nur aus Scrum. Es wird auch oft Kanban eingesetzt. Auch in Scrum werden schöne UML-Diagramme gezeichnet. Deshalb gibt es de facto keine reinen Programmierer. Es ist nicht das selbe.
Im Deutschen wird viel Verwirrung gestiftet, weil Leute die Begriffe unscharf einsetzen: z.B. Modell, Prozess, Architektur.
Ich bin nicht der Meinung, dass diese "barocken" Strukturen ihren Sinn verloren haben. Wer in der Planung schlampt und in der Integration den Fehler bemerkt, verursacht hohe Kosten und Zeitverzug. Das wird an der Uni mit einem billigen aber verständlichen Zeit-Kosten-Diagramm verdeutlicht.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: mrhanky01
downforze schrieb:
Deshalb gibt es de facto keine reinen Programmierer.
An dem Punkt sind wir uns denke ich einig. Ich habe ursprünglich auf diesen Satz geantwortet:
Magic1416 schrieb:
Wie erklär ich den Sinn hinter der Wahl des Kurses am besten, wenn man zwar jahrelang programmiert (meine Aussage), aber nicht jahrelang entwickelt (deine Aussage).

Und der ist in meinen Augen Quatsch. Selbst wenn ich nur ein paar Automation Scripte für den Eigengebrauch schreibe oder sich jemand als Hobby irgendein Gadget mit einem Arduino zusammenbastelt, steckt da ein Anteil Konzeption und Planung hinter.

downforze schrieb:
Ich bin nicht der Meinung, dass diese "barocken" Strukturen ihren Sinn verloren haben
Sie haben in dem Maße Sinn, wie sie für einen Zweck eingesetzt werden und nicht zum Selbstzweck verkümmern damit der Projektleiter oder die QA Abteilung glücklich sind. Wenn dann irgendwelche UML Diagramme gemalt werden, die keiner je inhaltlich prüft oder gar gegen die reale Software abgleicht, nur damit sie "da sind", dann sind nicht nur nutzlos, sondern schädlich. Weil irgendwann nimmt ein gutgläubiger Mensch den Inhalt von so einem Diagramm ernst und wird dann in die Irre geführt.
Gerade bei UML komm hinzu, dass nur wenige Leute die UML Notation vollständig verstehen und dann fehlerhafte Diagramme zeichnen. Bei uns im Unternehmen hat nur der kleinere Teil der Entwickler Informatik studiert, wie haben viele Physiker und Mathematiker aufgrund unseres Themengebietes. Wird sind daher bei uns von UML komplett weg.

Es ist auch bemerkenswert das die geforderten Diagramme und Metastrukturen stark von der Mode der Zeit abhängen:
In den 90ern / frühen 200ern als alle Welt Client/Server mit zentralen SQL Datenbanken machte, hat man vor allem Wert auf ein großes, zentrales Datenmodell gelegt und Entity-Relationship Diagramme gemalt.

Dann gab es so Zeiten, wo man Service Architekturen gebaut hat und da hatte auch UML seine Blüte.

Momentan zäumt man das Pferd eher vom Frontend auf, und legt großen Wert auf UX-Design. Nun haben wir User Stories, Story Boards, usw.

Im Backend hat man Micro Service Architekturen und Domain Driven Design. Zentrales Datenmodell ist völlig out, die DevOps Teams entwickeln unabhängig voneinander und jeder baut das für seine Domäne optimale Datenmodell. Explizit hat man "shared nothing" Architekturen und an den Schnittstellen zwischen den Services wird fleißig konvertiert.
Kann man natürlich heute machen, da Speicherplatz und CPU Leistung im Überfluss vorhanden sind. Am Ende des Monats schmerzt dann nur die Rechnung vom Cloud Provider etwas :-)
Ergänzung ()

downforze schrieb:
Die Welt besteht nicht nur aus Scrum. Es wird auch oft Kanban eingesetzt.
Ja, wir machen beides. Für Wartungsprojekte wo, man schlecht irgendwelche Features in Timeboxes bündeln kann, setzen wir Kanban ein. Ebenso bei Projekten, die keine feste Teamgröße haben.
Aber wenn möglich, versuchen wir auch im Wartungsbereich z.b. ein Service Pack in 2-3 Sprints zu bündeln.

Auch non-Entwicklungsprojekte, wie z.B. Einführung neuer Software oder IT Infrastukturprojekte werden zunehmend in Sprints organisiert.
 
Zuletzt bearbeitet:
TomH22 schrieb:
In den 90ern / frühen 200ern als alle Welt Client/Server mit zentralen SQL Datenbanken machte, hat man vor allem Wert auf ein großes, zentrales Datenmodell gelegt und Entity-Relationship Diagramme gemalt.
Das machen wir hier im ÖD noch so, weil es strengere Anforderungen an die Datensicherheit gibt. ER-Diagramme natürlich nicht. Die fand ich schon im Studium sinnlosen Bullshit. Da bringt ein Klassendiagramm oder Domänenmodell wesentlich mehr und ich habe die Variablen + class direkt drin.
User Storys sind eigentlich nichts weiter wie Anwendungsfallbeschreibungen. Aber es musste ja etwas neues cooleres gefunden werden. Das ganze Buzzwording hat erstaunlich viel von dem, was es als altmodisch absetzen wollte. Alter Wein in neuen Schläuchen..
 
Erst einmal vielen Dank für die interessanten und sachlichen Beiträge von Euch. Das Hilft mir auf jeden Fall weiter. Ich glaube, dass ich derzeit als Freelancer keine Möglichkeit habe, in einem reinem Entwicklungsprojekt tätig werden zu können. Das gibt mein Profil nicht ausreichend her und das wird sicher auch von den Kunden so gesehen.
Deshalb werde ich mich ein wenig anders aufstellen und mich mehr in Richtung Cloud, Docker und Kubernetes orientieren. Das dürfte am besten zu meinen bisherigen Tätigkeiten passen. Auch in diesen Bereichen gibt es eine Menge zu automatisieren, wo Programmier- und Skriptingkenntnisse erforderlich sind.
Am einfachsten ist das natürlich, wenn man diese Möglichkeit von seinen Bestandskunden angeboten bekommt.
 
Habe mir zwar deinen langen Text durchgelesen, aber ich denke, man bekäme einen besseren Überblick über dich und deine Chancen als Freelancer, wenn du deinen Lebenslauf (anonymisiert) mit uns teilen würdest.
 
Zuletzt bearbeitet von einem Moderator:
Magic1416 schrieb:
Deshalb werde ich mich ein wenig anders aufstellen und mich mehr in Richtung Cloud, Docker und Kubernetes orientieren. Das dürfte am besten zu meinen bisherigen Tätigkeiten passen. Auch in diesen Bereichen gibt es eine Menge zu automatisieren, wo Programmier- und Skriptingkenntnisse erforderlich sind.
DevOps ist definitiv ein sehr spannender Entwicklungspfad und aktuell bei vielen Firmen noch ein Hype Thema. Schau mal bei Amazon vorbei, die haben ganz brauchbare Einführungskurse. Dazu noch etwas Ahnung von Pyhton/Java und Du bist gut dabei. :)
 
Ein wenig offtopic, aber ich muss es loswerden: Chapeau an die Beteiligten. Wertvolle Beiträge, keine Trolle, kein Dizzen, keine Poser.
 
  • Gefällt mir
Reaktionen: mrhanky01 und Idon
Als Freelancer setzt man auf das was gefragt ist und zukunftsfähig ist. Desktop ist immer mehr am aussterben, wie kommt man denn dann auf die Idee gerade dort einzusteigen?
 
Zurück
Oben