OpenBSD 6.9 erschienen

Jaein. Zertifizierung verhindert bekannte, häufige Probleme.
Ein (immer noch) häufiges Problem sind ja zum Beispiel Sachen wie BufferOverflows usw. Solche Probleme ist seit Jahrzehnten bekannt. Auch die Mittel, was man dagegen tun kann. Das dürfte ja dann bei zertifizierter Software dann eigentlich gar nicht mehr auftreten. :-)

Gut. Man kann natürlich immer sagen, das das dann nur bedauerliche Einzelfälle sind und das es im Großen und Ganzen was bringt. Aber auch das ist erst mal nur eine Behauptung. Ich hab jetzt kein Vergleich, wo man mal großflächig guckt und schaut auf die Qualität von Software mit und ohne den ganzen Zertifizierungskram. Nur dann hätte man ja einen objektiven Anhaltspunkt an dem man das bewerten kann. Ob es wirkt oder ob es halt nur ein Placebo ist.

Mein Aha-Erlebnis war ja der VW-Skandal. So rund um Einhaltung der Abgasnorm. Eigentlich gut gedacht, weil man glaubt es bringt die Hersteller dazu, saubere Motoren zu entwickeln. Die Zielsetzung der Norm war also hier nicht wirklich das Problem. Das Problem ist, das der Hersteller halt anders drauf guckt. Der schaut nämlich nicht, wie er seine Technik möglichst sauber kriegt, sondern wie er mit möglichst wenig Aufwand den Test besteht, um das "Zertifikat" zu bekommen. Was dann letztlich darauf hinauslief, das man Schummelsoftware schrieb statt die Motoren sauberer zu machen.
Mit gut gemeinten Regeln allein ist es offenbar nicht getan.

Aber selbst wenn es funktioniert hilft das einem nur begrenzt weiter. Wie gesagt. Meine Ressourcen sind ja immer begrenzt. Das was ich in die eine Maßnahme stecke fehlt mir potentiell für andere Maßnahmen. Und das Ziel sollte ja möglichst sein meine Ressourcen in Maßnahmen zu stecken, wo unterm Strich möglichst viel raus kommt.
 
Und das Ziel sollte ja möglichst sein meine Ressourcen in Maßnahmen zu stecken, wo unterm Strich möglichst viel raus kommt.
Wenn du als Unternehmen in bestimmte Bereiche verkaufen willst, musst du halt bestimmte Zertifizierungen vorweisen. Also steckst du deine Ressourcen in die entsprechenden Maßnahmen. Und natürlich versuchst du möglichst wenig Ressourcen dafür aufzuwenden - eh klar. Trotzdem wirst du bestimmte Dinge umsetzen müssen und deine Mitarbeiter werden sich Gedanken über Themen machen müssen. Und eigentlich gehts nur darum. Leute machen sich Gedanken - das Ergebnis muss dir dann nicht gefallen oder ausreichend erscheinen aber man hat sich halt Gedanken machen müssen und eine Entscheidung treffen. Du darfst gerne mal ne ISO 27001 begleiten, dann merkst du dass das gar nicht so ohne ist. Und die ist vergleichsweise noch leicht zu haben - trotzdem scheitern regelmäßig Firmen daran, eben weil die notwendigen Unternehmensprozesse nicht vorhanden sind. Ja, deren Wirksamkeit wird eher mit verschlossenen Augen geprüft aber man könnte da wenn man wollte eh schummeln und einfach etwas vorgaukeln was nicht gelebt wird. Wie gesagt: darum gehts auch gar nicht. Es geht darum, dass sich Leute Gedanken über Abläufe machen. Oder schau dir ITIL an: das ist einfach nur eine Best Practice Sammlung. Eigentlich nicht mal das: es sagen einfach Firmen was bei Ihnen funktioniert (die sind noch nicht mal sonderlich repräsentativ) und man definiert ein paar Begriffe damit die Leute nicht permanent aneinander vorbeireden. Und dann sagt man: Überlegt euch wie ihr das Thema X in eurem Unternehmen angehen wollt. Thats all!

Wie das bei Software abläuft weis ich nicht, da kenne ich aber auch keine namhaften Zertifizierungen. Aber ich würde annehmen, dass auch da eher der Prozess der Herstellung als die eigentliche Software zertifiziert wird.

Das alles kann man jetzt für völligen Blödsinn halten - nur spielt das gar keine Rolle. Denn die Welt ist nun mal so wie sie ist ;)
 
sysupgrade läuft sehr gut, es ist wirklich ein hilfreiches tool und macht das Leben einfacher.

Man sollte mit pkg_add -u vorsichtig sein. Manchmal - aus welchen Gründen auch immer - bleiben updates auf der Strecke. sysclean -p kann einige Pakete anzeigen, für die noch updates installiert werden können. Am besten sollte man nachprüfen, ob alle wichtigen Pakete tatsächlich die aktuelle Version haben.
 
Wenn du als Unternehmen in bestimmte Bereiche verkaufen willst, musst du halt bestimmte Zertifizierungen vorweisen. Also steckst du deine Ressourcen in die entsprechenden Maßnahmen.
Ja. Das verstehe ich. Mir ist klar, das es äußere Zwänge gibt, denen man sich auch unterwerfen muss.
Das heißt aber nicht, das man das nicht kritisieren kann.
Es ging mir nur darum darzustellen, wo (aus meiner Sicht) die Probleme liegen und warum sollte Sachen die oftmals halt nicht lösen können.

Ja, deren Wirksamkeit wird eher mit verschlossenen Augen geprüft aber man könnte da wenn man wollte eh schummeln und einfach etwas vorgaukeln was nicht gelebt wird. Wie gesagt: darum gehts auch gar nicht. Es geht darum, dass sich Leute Gedanken über Abläufe machen.
Ja. Aber die Frage war ja nicht nur, ob die eine gewisse Wirksamkeit entfalten oder nicht, sondern selbst wenn man jetzt annimmt das die Maßnahmen wirksam sind, ob es nicht möglicherweise andere Wege gibt wo das Verhältnis von Aufwand und Nutzen besser sind.
Wie Du ja schon beschrieben hast nützen Dir die Standards nur begrenzt was wenn es lediglich etwas ist, was abgehakt werden muss aber nicht etwas, was auch "gelebt" wird.

Meine Erfahrung ist, das Entwickler eher weniger mit Absicht schlechte Software schreiben. Ich würde mal behaupten, die meisten Entwickler arbeiten nach besten Wissen und Gewissen, wie man so schön sagt. :-)

Eine Baustelle ist die (Aus)Bildung. Über viele Dinge fehlt nicht selten Wissen und Verständnis. Zudem ist es halt auch ne bewegte Branche. Aber mal eine Weiterbildung zu bekommen ist gar nicht so einfach. Weil für den Arbeitgeber bedeutet das ja nicht nur Kosten für die Schulungsmaßnahme, sondern auch Arbeitsausfall weil der Mitarbeiter in der Zeit ja nicht produktiv ist.
Ich will damit nicht sagen, das es unmöglich ist. Aber eine Weiterbildung zu bekommen ist halt nicht so einfach.

Das andere Problem ist der Zeitfaktor. Die Arbeit soll lieber gestern als heute fertig werden. Und häufig ist es so das wenn es läuft dann keine Zeit ist, noch mal drüber zu gucken und das in eine Form zu gießen welche akzeptabel ist. Man beruhigt sich dann immer selbst mit dem "Na das machste mal, wenn Du mal Zeit hast". Aber die hast Du nie. Weil immer irgendwas bis gestern fertig werden muss.
Denn noch das Problem, das es schwierig wird überhaupt mal konzentriert am Stück an irgendwas arbeiten zu können. Entweder klingelt das Telefon oder irgendeines der zahlreichen Meetings ist mal wieder oder oder oder.

Man sieht es ja auch gut am Quelltext im Open-Source-Umfeld. Gerade so im Traditionellen, wo das so eher als Hobby bzw. durch Freiwilligkeit getragen ist. Das sind halt häufig Leute die sich auskennen. Und wo auch kein Druck durch Deadlines herrscht, sondern eher ein "It's done, when it's done".

Ich denk' mal in solchen Bereichen gibts sehr viel Verbesserungspotential.

Das alles kann man jetzt für völligen Blödsinn halten
So würde ich es nicht unbedingt formulieren.
Es gibt kein Patentrezept, um die Probleme zu lösen. Und die Lösung ist auch nicht eine Maßnahme, sondern das Zusammenspiel von mehreren Maßnahmen.
Insofern kann man das mit so einer Zertifizierung ruhig machen (oder muss es sogar in manchen Fällen) aber funktioniert halt nur eingebettet in andere Maßnahmen. Also zumindest wenn das Ziel die Verbesserung der Softwarequalität ist und nicht etwa nur, um dem Kunden irgendeinen Wisch unter die Nase halten zu können.

Oder ums mal plakativ zu formulieren:
Es bringt wenig wenn man ISOirgendwas umsetzt aber beim Entwickler alle 5 Minuten das Telefon wegen irgendwelchen Sch**ß klingelt.
 
Meine Erfahrung ist, das Entwickler eher weniger mit Absicht schlechte Software schreiben. Ich würde mal behaupten, die meisten Entwickler arbeiten nach besten Wissen und Gewissen, wie man so schön sagt. :-)
In meinem Umfeld haben die Meisten Elektrotechnik oder Mechatronik studiert. Im besten Fall hat man da mal einen PID Regler in C gefrickelt und eine Schrittkette mit Step-7 geklickt (eine Schrittkette ist so etwas wie die dümmste anzunehmende FSM) und 100 Zeilen 8051 Assembler geschrieben.

Die Leute schreiben jetzt große C/C++ Projekte und an den Voraussetzungen gemessen ist das was herauskommt gar nicht so schlecht. Code review, Style guides und Pair programming holen da einiges raus und machen aus den Leuten tatsächlich kompetente Programmierer.

Trotzdem kämpfen wir mit Bloat und Overengineering.

Und wenn ich mich an mein Studium zurück erinnere würde ich sagen, dass höchstens 30 % der Informatiker annehmbar programmieren können. Daran kann es also auch nicht liegen.

Um ehrlich zu sein habe ich keine Ahnung warum Software so mies ist. Aber Software ist definitiv mies. Auf einem Niveau das man nirgendwo sonst akzeptieren würde.
 
Das Problem ist meiner Meinung nach u.a. die agile Softwareentwicklung. Da wird in einem Team auf die Schnelle ein Prototyp entwickelt und so lange daran rumgedoktert, bis der Kunde damit "zufrieden ist" und weiss, was er ueberhaupt will.

Dann werden irgendwelche "Komplexitaetsmonster-Frameworks" genutzt, nur weil man eine Funktion davon benoetigt. So schoen die ganzen Paketmanager auch sind, man weiss nie, welche Probleme man sich durch inkludierte Abhaengigkeiten einfaengt.

Die Zertifizierung ist definitiv auch ein Problem. Das sehe ich bei uns in der Firma auch. Nach jeder Software-/Firmwareaenderung muss ein ca. 1000-seitiges Pruefprotokoll durchlaufen werden. Durch diesen Aufwand werden Aenderungen immer lange gesammelt oder garnicht erst durchgefuehrt, da nicht so wichtig.
 
Zuletzt bearbeitet:
Ich will damit nicht sagen, das es unmöglich ist. Aber eine Weiterbildung zu bekommen ist halt nicht so einfach.

Deswegen macht man aus der Not eine Tugend und bildet sich auf eigene Faust weiter. Sich von einem Arbeitgeber abhängig zu machen ist sowieso immer eine blöde Idee.

Das Problem ist meiner Meinung nach u.a. die agile Softwareentwicklung. Da wird in einem Team auf die Schnelle ein Prototyp entwickelt und so lange daran rumgedoktert, bis der Kunde damit "zufrieden ist" und weiss, was er ueberhaupt will.

Umgekehrt ist in meiner Erfahrung das Ergebnis noch viel schlechter: jahrelang in Planung befindliche Wasserfallprojekte, die schon vor Implementierungsbeginn völlig am Bedarf vorbeigehen und aufgrund der mangelnden Flexibilität hoffnungslos hinterherhinken. Jede sinnvolle Anpassung ist ein aufwändiger Change-Prozess, so dass alle Beteiligten lieber sinnlos hinfällige Anforderungen implementieren, weil eine Anpassung des ursprünglichen Plans praktisch ein Ding der Unmöglichkeit ist.

Ich bin ein Fan von "just enough design upfront": gewisse Rahmenbedingungen vorab klären und abstecken (gerade Themen wie Security kriegt man nachträglich nur mit enormen Schmerzen in die Anwendung), aber ansonsten möglichst kurze Feedback-Schleifen.

Dann werden irgendwelche "Komplexitaetsmonster-Frameworks" genutzt, nur weil man eine Funktion davon benoetigt. So schoen die ganzen Paketmanager auch sind, man weiss nie, welche Probleme man sich durch inkludierte Abhaengigkeiten einfaengt.

Auf der anderen Seite entwickeln viele Teams ihre eigenen Logging-, ORM-, Web- und sonstige Frameworks, wodurch sie mit viel Aufwand wenig nützliche Anwendungen abliefern. :ugly:

Auch die Softwareentwicklung unterliegt hier einer Pendelbewegung zwischen großen Frameworks (mit den von dir angesprochenen Problemem) und spezialisierten Bibliotheken (bei denen man wieder viele Dinge von Hand verdrahten muss, die einem Frameworks abnehmen). Die Wahrheit liegt wie üblich irgendwo in der Mitte.
 
Und wenn ich mich an mein Studium zurück erinnere würde ich sagen, dass höchstens 30 % der Informatiker annehmbar programmieren können. Daran kann es also auch nicht liegen.
Das Verhältnis von Informatik zu Programmierung ist .... schwierig. :-)
Jeder Informatik-Prof wird Dir sagen, das Informatikstudium ist kein Programmierkurs. Was auch stimmt. Ein Informatikstudium ist eher recht mathe-lastig. Klar lernt man auch viel über Algorithmen und Datenstrukturen. Die eigentliche Programmierung nimmt aber einen vergleichsweise kleinen Raum ein (gibt sogar Studenten die sind durch das Studium gekommen ohne eine Zeile Code zu schreiben).
Und das das so ist, ist auch nicht "Bug", sondern "Feature". :-)

Das Informatikstudium ist mit Absicht so ausgelegt. Und es ist auch nicht so das man das was man da lernt als Programmierer nicht gebrauchen kann. Aber es bildet halt nur einen Teil ab. Salopp gesagt: Wie Du nen ausgeklügelten Algorithmus hinzauberst lernst Du. Wie Du vermeidest das Du bei der Implementierung einen BufferOverflow einbaust eher nicht.

Wobei Sicherheit und Qualität grundsätzlich schon ein Thema sind. Beispielsweise durch den Bereich Softwareverifikation abgedeckt. Ein Verfahren, was gut funktioniert aber gleichzeitig auch aufwendig ist, das es in der Praxis eh keiner macht (auch wenn es bei funktionaler Programmierung tatsächlich auch praktisch in Teilen gut machbar ist; das Haskell-Umfeld hat dich dem so ein bisschen angenommen).

Kurzum: Du hast bei Informatik viel Theorie und eher weniger Praxis. Während man bei der Ausbildung zum Entwickler zwar viel Praxis hat aber tendenziell zu wenig Theorie.
Und was völlig illusorisch ist und auch keine Ausbildungsstätte leisten kann ist dann noch Wissen zu vermitteln von dem, was gerade angesagt ist. Weil das halt so schnelllebig ist, das man da gar nicht hinterher kommt das jeweilige Framework-of-the-week zu behandeln.

Das wäre auch alles noch gar nicht so dramatisch. Sich in Frameworks einzuarbeiten ist ansich kein Problem. Hier kommt auch wieder der Zeitfaktor zum tragen. Die Zeit sich in ein Framework einzuarbeiten und erst mal nur damit herumzuspielen, um zu gucken, wie es tickt und wie die Sachen funktionieren gibt Dir keiner.
Besonders schön zu beobachten an irgendwelchen hippen Startups die ein hippes Framework einsetzen um damit eine hippe App zu basteln.

Überhaupt ist Programmierung und Programmieren lernen und können sehr viel von Erfahrung geprägt. Das kennt jeder Entwickler der sich alten Code von sich selbst anschaut.

Dann werden irgendwelche "Komplexitaetsmonster-Frameworks" genutzt, nur weil man eine Funktion davon benoetigt. So schoen die ganzen Paketmanager auch sind, man weiss nie, welche Probleme man sich durch inkludierte Abhaengigkeiten einfaengt.
Ja. Haben wir ja mehr oder weniger regelmäßig. Das irgendwie die node-js Anwendung nicht mehr läuft weils irgendein Package nicht mehr gibt oder Malware reingezogen wird, weil bei all den um drei Ecken eingezogenen Abhängigkeiten gar keiner mehr nen Überblick hat (und haben kann).

Komplexität ist in der Tat generell ein großes Problem.

Aber teilweise fangen die Probleme schon im Kleinen an. Kompiliert mal jetzt irgendein Projekt. Egal ob Open-Source oder bei euch in der Firma. Schaut mal wieviel Warnings dabei so der Compiler ausspuckt. Die gibt er ja nicht umsonst. Die deuten ja tatsächlich auf ein potentielles Problem hin. Klar kann es im Einzelfall immer gute Gründe geben, warum trotz Warnung der Code so ok ist. Aber 99% der Warnings lassen sich halt nicht so begründen.

Ist nicht so schlimm. Fixen wir später. Wenn wir mal Zeit haben. Indianerehrenwort! :-)

Das Problem ist meiner Meinung nach u.a. die agile Softwareentwicklung. Da wird in einem Team auf die Schnelle ein Prototyp entwickelt und so lange daran rumgedoktert, bis der Kunde damit "zufrieden ist" und weiss, was er ueberhaupt will.
Wobei agile Softwareentwicklung halt auch vielfach falsch verstanden wird. Es reicht eben nicht irgendwen im Team zum Scrum-Prister zu ernennen und irgendwelche Prototypen hinzuschludern. :-)
Auch Prototyping ansich ist nicht verkehrt. Das wird erst dann zum Problem, wenn man den Prototyp mehr oder weniger 1:1 übernimmt um daraus das Produkt zu machen.

Ich bin auch eher jemand der nicht irgendwie einen Masterplan entwirft und den dann befolgt, sondern der iterativ entwickelt. Auch zumindest zu Anfang mit starken Prototyp-Charakter. Allerdings ist der Quelltext dann auch im Verlauf ständig relativ starken Änderungen unterworfen.
Der sieht jede Woche anders aus. :-)
Im Grunde wird das Programm (oder Programmmodul) rein von der Tipparbeit oder von den Lines-of-Code her gesehen nicht irgendwie 1x geschrieben, sondern eher 10x.

Aber auch so reicht bestehender Code ja hinten und vorne nicht. Wenn es noch darum geht, um zu gucken ob man eine Sache soundso lösen kannst, brauchst Du ja viele Sachen nicht. Sowas wie Fehlerbehandlung, Eingabeüberprüfung usw. Das hast du alles nicht in einem Programm was noch Prototypen-Charakter hat.
Interessanterweise sind das aber genau die Sachen, die in der Praxis am häufigsten zu Stolpersteinen für Programme werden.

Deswegen macht man aus der Not eine Tugend und bildet sich auf eigene Faust weiter. Sich von einem Arbeitgeber abhängig zu machen ist sowieso immer eine blöde Idee.
Logisch macht "man" das. Das ist ja auch gar nicht die Frage.
Die Frage ist eher, ob das so gut ist. Weil es (wir sind wieder beim Thema) eine Zeitfrage ist. Wenn Du den ganzen Tag im Büro zu tun hast, hast Du nicht unbedingt die Lust auch noch in der Freizeit Dich weiterzubilden bzw. kannst Du das machen, aber Dir fehlt halt die Zeit wirklich mal abzuschalten.

Das endet dann also oft daran, das Du in der Firma lernst. Und zwar in dem Du die neue Technologie beim aktuellen Projekt einsetzt. Nur bist Du dann in einer Phase in der Du das halt noch nicht beherrschst (wie oben schon ausgeführt). Aber Dein Code wird dann trotzdem produktiv eingesetzt und macht da dann Probleme.

Das der Arbeitgeber Weiterbildung ermöglicht soll jetzt auch nicht verstanden werden als "Der Arbeitgeber meldet seine Leute bei nem Volkshochschulkurs an von dem er meint der wäre ganz gut und die müssen das dann irgendwie absitzen".
Da gibts ja durchaus Möglichkeiten das nützlicher zu gestalten. Der wesentliche Punkt ist halt, das die Leute einen Zeitrahmen dafür kriegen, wo einem nicht das Management im Nacken sitzt weil der Sale dem Kunden irgendwelche neuen Features für dieses Quartal versprochen hat.

Auf der anderen Seite entwickeln viele Teams ihre eigenen Logging-, ORM-, Web- und sonstige Frameworks, wodurch sie mit viel Aufwand wenig nützliche Anwendungen abliefern.
Ja. Es macht sicher nicht Sinn alles selbst zu entwickeln. Es ist immer besser etwas Bewährtes zu nehmen was schon da ist. Wo sich jemand bereits Gedanken gemacht hat. Wo keine Kinderkrankheiten mehr drin stecken mit denen Du Dich herumplagen musst usw.

Mitunter ist es aber schwierig sich in dem Dschungel an Frameworks zurecht zu finden. Du hast sozusagen die Qual der Wahl. Also nimmst Du im Zweifel eher das, was alle nehmen. Wenns aber für viele Leute passt (zumindest irgendwie), dann ist das halt üblicherweise kein kleines, elegantes, überschaubares Framework, sondern eher ein allgemeines, Bloatiges. Am besten noch mit nem dutzend Abstraktionslayer, das wenn "unten" was schief geht Du auch wirklich chancenlos bist das wieder hinzubiegen. :-)

Man muss also schon ein bissl gucken. Das sind jetzt alles keine Sachen und Stolperfallen die man nicht irgendwie umschiffen kann. Aber auf dem Weg zur Lösung gibts halt ne Menge Pfade rechts und links, wo Du schnell mal falsch abbiegen kannst.

Die Wahrheit liegt wie üblich irgendwo in der Mitte.
Kann man so sagen. Und nu bitte 3€ ins Phrasenschwein. :-)
 
Die Frage ist eher, ob das so gut ist. Weil es (wir sind wieder beim Thema) eine Zeitfrage ist. Wenn Du den ganzen Tag im Büro zu tun hast, hast Du nicht unbedingt die Lust auch noch in der Freizeit Dich weiterzubilden bzw. kannst Du das machen, aber Dir fehlt halt die Zeit wirklich mal abzuschalten.

Korrekt. Man kann diese Situation auch zum Anlass nehmen, sich nach grüneren Weiden umzuschauen. Ich finde es immer wieder erstaunlich, wie viele Entwickler bei schlechten Arbeitgebern verharren, anstatt zu wechseln oder gleich auf eigene Rechnung zu arbeiten.

Das endet dann also oft daran, das Du in der Firma lernst. Und zwar in dem Du die neue Technologie beim aktuellen Projekt einsetzt. Nur bist Du dann in einer Phase in der Du das halt noch nicht beherrschst (wie oben schon ausgeführt). Aber Dein Code wird dann trotzdem produktiv eingesetzt und macht da dann Probleme.

Korrekt. Selbst wenn man sich schon auskennt, ist man nach der Umsetzung (hoffentlich) immer schlauer - sowohl technisch als auch fachlich. Der Bedarf an Software ist einfach so groß, dass selbst drittklassige Software oftmals einen Markt hat.

Mitunter ist es aber schwierig sich in dem Dschungel an Frameworks zurecht zu finden. Du hast sozusagen die Qual der Wahl. Also nimmst Du im Zweifel eher das, was alle nehmen. Wenns aber für viele Leute passt (zumindest irgendwie), dann ist das halt üblicherweise kein kleines, elegantes, überschaubares Framework, sondern eher ein allgemeines, Bloatiges. Am besten noch mit nem dutzend Abstraktionslayer, das wenn "unten" was schief geht Du auch wirklich chancenlos bist das wieder hinzubiegen. :-)

Mit welche(s) Bilbiothek/Framework für welchen Einsatzzweck könnten wir viele Geplauder-Threads füllen, nachdem wir hier schon den OpenBSD-Release-Thread gekapert haben. :D

Man muss also schon ein bissl gucken. Das sind jetzt alles keine Sachen und Stolperfallen die man nicht irgendwie umschiffen kann. Aber auf dem Weg zur Lösung gibts halt ne Menge Pfade rechts und links, wo Du schnell mal falsch abbiegen kannst.

Die Softwareentwicklung ist noch eine junge Branche - es bleibt spannend. :)
 
Man kann diese Situation auch zum Anlass nehmen, sich nach grüneren Weiden umzuschauen.
Ab in den stressfreien öffentlichen Dienst. Faxgeräte warten.
Ein Kalauer muss zwischendurch auch mal sein. :-)

Aber im Grunde ist das natürlich richtig. Als Entwickler hat man einen relativ guten Stand, weil die eher Mangelware sind als entbehrlich. Das heißt aber auch, das man als Entwickler nicht der Getriebene sein muss und durchaus auch einiges für sich an Weiterbildung und Zeit einfordern kann.

Die Softwareentwicklung ist noch eine junge Branche
Ja. Das höre ich schon seit über 30 Jahren.
Ich glaube, diese Sicht darauf ist ist mit ursächlich für die Probleme.
Das erinnert mich so an Hundebesitzer die ihren Hund nicht erziehen und die Ausrede dafür ist: Der ist doch noch so jung. Der muss sich austoben. Das machen wir später.

Ansich ist das auch ok. Früher war die Computerbranche eben noch sehr neu. Da war das tatsächlich eher eine Spielwiese. Wenn da irgendein Programm geholfen hat ein Problem zu lösen, war das cool. Wenns mal nicht funktioniert hat, wars aber auch nicht schlimm.

In diesem Stadium sind wir aber längst nicht mehr. Computer sind ein essentieller Bestandteil des heutigen Lebens. Wenn irgendwie irgendwo was ausfällt, hat das katatrophale Folgen. Durchaus auch lebensbedrohlich. Direkt und unmittelbar nachvollziehbar, wenn man an eine Kraftwerkssteuerung oder von mir aus auch autonome Fahrzeuge denkt.
Die Verantwortung die damit einher geht wird halt dieser "ach komm. Das wird schon noch"-Blick darauf nicht gerecht.

Der Bedarf an Software ist einfach so groß, dass selbst drittklassige Software oftmals einen Markt hat.
Vermutlich.
Das ist ja genau das Problem. Schlechte Software auf den Markt zu werfen hat für den Hersteller keine Konsequenzen.

Mit welche(s) Bilbiothek/Framework für welchen Einsatzzweck könnten wir viele Geplauder-Threads füllen, nachdem wir hier schon den OpenBSD-Release-Thread gekapert haben.
Solange es OpenBSD-Frameworks sind, wird man das sicher gut begründen können. :-)
 
  • Like
Reaktionen: jmt
Ab in den stressfreien öffentlichen Dienst. Faxgeräte warten.

Selbst dieses Beschäftigungsfeld ist in Gefahr, seit der Bremer Datenschutzbeauftragte festgestellt hat, dass Faxe mangels Vertraulichkeit nicht koscher sind. :ugly:

Aber im Grunde ist das natürlich richtig. Als Entwickler hat man einen relativ guten Stand, weil die eher Mangelware sind als entbehrlich. Das heißt aber auch, das man als Entwickler nicht der Getriebene sein muss und durchaus auch einiges für sich an Weiterbildung und Zeit einfordern kann.

"Hey Chef, ich werde ab sofort mehr Zeit und Budget für Weiterbildung haben. Wenn nicht bei dieser Firma, dann halt bei einer anderen." :D

Ja. Das höre ich schon seit über 30 Jahren.
Ich glaube, diese Sicht darauf ist ist mit ursächlich für die Probleme.

Je nach Softwareumfeld, in dem man sich bewegt, sind die meisten Tools, Frameworks und Konsorten keine 10-20 Jahre alt. Selbst einige Best Practices vor 20 Jahren sind inzwischen (aus diversesten Gründen) Anti-Pattern. Die absolute Mehrheit der Softwareentwickler war vor 20 Jahren noch nicht einmal in der Branche.

Das erinnert mich so an Hundebesitzer die ihren Hund nicht erziehen und die Ausrede dafür ist: Der ist doch noch so jung. Der muss sich austoben. Das machen wir später.

Der Vor- und Nachteil von Software ist (in vielen Bereichen) auch, dass man es später machen kann. Ob das dann auch gemacht wird, steht auf einem anderen Blatt...

Ansich ist das auch ok. Früher war die Computerbranche eben noch sehr neu. Da war das tatsächlich eher eine Spielwiese. Wenn da irgendein Programm geholfen hat ein Problem zu lösen, war das cool. Wenns mal nicht funktioniert hat, wars aber auch nicht schlimm.

In Anbetracht der Ausgereiftheit der Speerspitze der formalen Softwareverifikation (z.B. Tools wie Coq) haben wir noch eine weite Reise vor uns.

Die meisten Softwareprojekte scheitern aber an viel geringeren Hürden.

In diesem Stadium sind wir aber längst nicht mehr. Computer sind ein essentieller Bestandteil des heutigen Lebens. Wenn irgendwie irgendwo was ausfällt, hat das katatrophale Folgen. Durchaus auch lebensbedrohlich. Direkt und unmittelbar nachvollziehbar, wenn man an eine Kraftwerkssteuerung oder von mir aus auch autonome Fahrzeuge denkt.
Die Verantwortung die damit einher geht wird halt dieser "ach komm. Das wird schon noch"-Blick darauf nicht gerecht.

Je nach Branche - Medizintechnik als prominentes Beispiel - sind die Standards eine andere Hausnummer als bei einer 08/15-Webanwendung.

Vermutlich.
Das ist ja genau das Problem. Schlechte Software auf den Markt zu werfen hat für den Hersteller keine Konsequenzen.

Nicht mehr oder weniger als in anderen Branchen. Es sind auch schon genug Softwarehersteller aufgrund ihrer schlechten Qualität pleite gegangen.

Solange es OpenBSD-Frameworks sind, wird man das sicher gut begründen können. :-)

Du meinst, wir sollten veb(4) noch in die Diskussion aufnehmen? ;)
 
Selbst dieses Beschäftigungsfeld ist in Gefahr, seit der Bremer Datenschutzbeauftragte festgestellt hat, dass Faxe mangels Vertraulichkeit nicht koscher sind.
Und das völlig zurecht. Man fragt sich eher, warum es überhaupt mal "unbedenklich" war.
Fax war nie besonders sicher. Im Anfänglichen Internetzeitalter war es nur deshalb noch vergleichsweise gut, weil es nicht im selben Netz hing wie der Rest auch. Seitdem alles "All-IP" ist gibts dann nicht mal mehr diese Trennung.

"Hey Chef, ich werde ab sofort mehr Zeit und Budget für Weiterbildung haben. Wenn nicht bei dieser Firma, dann halt bei einer anderen."
Na nicht nur auf Weiterbildung bezogen, sondern ganz allgemein. Unrealistische Deadlines. Oder diese "mal eben"-Geschichten, wo dann jemand Freitag auf ein zukommt, ob man nicht "mal eben" noch Feature soundso einbauen könnte, damit man das am Montag vorzeigen kann. :-)
Gerade jüngere Kollegen lassen sich dann gerne mal überreden. Weil sie nicht "Nein" sagen wollen oder aus falsch verstandenem Ergeiz.

Je nach Softwareumfeld, in dem man sich bewegt, sind die meisten Tools, Frameworks und Konsorten keine 10-20 Jahre alt.
Nichtdestotrotz sollte man trotzdem eine Ernsthaftigkeit an den Tag legen. Wie gesagt. Der Bereich ist einfach zu wichtig.

In Anbetracht der Ausgereiftheit der Speerspitze der formalen Softwareverifikation (z.B. Tools wie Coq) haben wir noch eine weite Reise vor uns.
Ja. Allerdings wird in solche Sachen auch vergleichweise wenig investiert.

Mein Eindruck ist:
Was vor allem viel Aufmerksamkeit bekommt sind Mitigations, Sandboxes, Telemetrie.
Aber weniger in Richtung: Wie mach ich den Softwareentwicklungsprozess so, das ich möglichst erst gar keine Bugs kriege die ich umständlich eindämmen und telemetrieren muss.
Ich hatte ja auch schon das Beispiel mit dem Compiler der Warnings bringt. Die heute oft gelebte Realität ist aber, das Du bei den gern eingesetzten Sprachen wie z.B. Javascript ja gar kein Compiler mehr hast. Theoretisch kannst Du auch da Analysetools drüberlaufen lassen, aber die Analyse-Möglichkeiten sind halt bei diesen dynamischen Sprachen begrenzt. Und dann fängt man an Sachen einzubauen, wie man sich schon früher kannte. Wie z.B. das man Datentyp-Informationen hinterlegen kann. :-)

Klar gibt es auch Gegenbeispiele. Wie das im Nachbarforum erwähnte Rust. Das schon viele Problemfelder in der Sprache selbst angeht und wo dann auch der Compiler dementsprechend viel melden bzw. verhindern kann.

Auch Sachen wie Unit-Test bringen einen spürbaren Gewinn. Das war vor 30 Jahren auch noch nicht da und gehört heute sozusagen zur "Standardausstattung".

Insgesamt wird aber für mein Empfinden (möglicherweise liege ich da falsch) aber in solchen Bereichen noch viel zu wenig getan.
Und dieser ganze Sandbox und Telemetriekram hat halt auch den Nachteil, das es meine Software komplexer macht und damit wieder potentiell anfälliger für Bugs.

Je nach Branche - Medizintechnik als prominentes Beispiel - sind die Standards eine andere Hausnummer als bei einer 08/15-Webanwendung
Hör bloß auf mit Medizintechnik. Das funktioniert auch nur, weils quasi Laborbedingungen sind. :-)

Nicht mehr oder weniger als in anderen Branchen.
Ja. Auch da ist teilweise ein Niedergang der Qualität zu beobachten. Meist auf Kosten der Haltbarkeit. Wobei das die meisten nicht stört. Denn geringe Qualität bedeutet auch oft ein niedriger Preis. Vor allem will auch niemand ein Gerät haben, was 20 Jahre hält weil das ist bis dahin eh hoffnungslos veraltet. Dann bezahlt man lieber weniger und "gönnt" sich öfter mal was Neues.
Ist natürlich eine gigantische Ressourcenverschwendung.

Es sind auch schon genug Softwarehersteller aufgrund ihrer schlechten Qualität pleite gegangen.
Ashton-Tate wegen dbase IV. :-)
Das wäre nach heutigen Maßstäben ne grundsolide Software. :-)

Ansonsten wäre ja ein gutes Gegenbeispiel Microsoft. :-) Die haben sich zwar deutlich gebessert aber wenn ich so an die 90er Jahre zurückdenke, so hätte man das normalerweise nicht so einfach überleben dürfen. Da haben die Leute sogar vor dem Geschäften angestanden, wenn eine neue Windows-Version rauskam. :-)
Und Probleme haben die ja teilweise bis heute. Man denke nur an die Exchange-Bugs Anfang des Jahres. Bei Exchange hast Du dann noch die Paarung von durchwachsener Softwarequalität bei gleichzeitig schlechter Patchbarkeit.
 
Aber Microsoft macht jetzt weniger Fehler, da sie weniger Code schreiben. Die werben bei uns jetzt mit LowCode / NoCode. :ugly:
 
Gerade jüngere Kollegen lassen sich dann gerne mal überreden. Weil sie nicht "Nein" sagen wollen oder aus falsch verstandenem Ergeiz.

Ein jeder muss seine Lektion lernen. :)

Nichtdestotrotz sollte man trotzdem eine Ernsthaftigkeit an den Tag legen. Wie gesagt. Der Bereich ist einfach zu wichtig.

Es gibt entsprechende Bewegungen. Das ist aber nach wie vor eine Minderheit.

Ja. Allerdings wird in solche Sachen auch vergleichweise wenig investiert.

Das Henne-Ei-Problem. Solange die Tools so weit von der Einsatzreife entfernt sind, gibt es wenig Anreiz zur Beschäftigung damit.

Was vor allem viel Aufmerksamkeit bekommt sind Mitigations, Sandboxes, Telemetrie.

Was aber auch völlig richtig ist. Solange es beim Betrieb von Software so viele Unwägbarkeiten gibt, sollte man diese nach bestem Wissen und Gewissen kompensieren. So wie man beim Flugzeubau kritische Teile vierfach verbaut, um gegenüber unvermeidbaren Ausfällen gewappnet zu sein.

Aber weniger in Richtung: Wie mach ich den Softwareentwicklungsprozess so, das ich möglichst erst gar keine Bugs kriege die ich umständlich eindämmen und telemetrieren muss.

Stand heute ist der Bau fehlerfreier Software jenseits trivialer Programme unmöglich und wird das auch auf absehbare Zeit bleiben. Dementsprechend ist resilient software design und Konsorten der vernünftige Weg, damit umzugehen.

Ich hatte ja auch schon das Beispiel mit dem Compiler der Warnings bringt. Die heute oft gelebte Realität ist aber, das Du bei den gern eingesetzten Sprachen wie z.B. Javascript ja gar kein Compiler mehr hast. Theoretisch kannst Du auch da Analysetools drüberlaufen lassen, aber die Analyse-Möglichkeiten sind halt bei diesen dynamischen Sprachen begrenzt. Und dann fängt man an Sachen einzubauen, wie man sich schon früher kannte. Wie z.B. das man Datentyp-Informationen hinterlegen kann. :-)

Ich bin auch ein Freund statisch und stark typisierter Sprachen, aber im Browser-Bereich landet man letzten Endes (noch) leider immer bei Javascript (und sei es bei eingebundenen Bibliotheken).

Klar gibt es auch Gegenbeispiele. Wie das im Nachbarforum erwähnte Rust. Das schon viele Problemfelder in der Sprache selbst angeht und wo dann auch der Compiler dementsprechend viel melden bzw. verhindern kann.

Rust ist trotz seiner Komplexität ein vielversprechender Kandidat für eine gute systemnahe Sprache.

Auch Sachen wie Unit-Test bringen einen spürbaren Gewinn. Das war vor 30 Jahren auch noch nicht da und gehört heute sozusagen zur "Standardausstattung".

Korrekt. Es gibt inzwischen viele Techniken und Tools (Unit Tests, Mutation Testing, statische Codeanalyse uvm.), die einfach einzubinden sind und die Qualität steigern.

Insgesamt wird aber für mein Empfinden (möglicherweise liege ich da falsch) aber in solchen Bereichen noch viel zu wenig getan.

Gefühlt ist die Qualität von Software in vielen Bereichen stark gestiegen. Ich hätte mir auch früher nicht träumen lassen, problemlos ein Rolling Release auf dem Desktop zu betreiben.

Wir betreiben aber natürlich auch deutlich mehr Software, dementsprechend passiert auch mehr.

Und dieser ganze Sandbox und Telemetriekram hat halt auch den Nachteil, das es meine Software komplexer macht und damit wieder potentiell anfälliger für Bugs.

Ich bin froh um beide Techniken. Mit Telemetrie kannst du überhaupt das Verhalten deiner Software beobachten, anstatt einen Blindflug hinlegen zu müssen. Gerade in verteilten Systemen ist es zwar schön, wenn die eigene Software problemlos funktioniert, aber irgendwas im Umfeld hakt.

Die diversen Sandbox-Techniken verhindern auch effektiv, dass ein problematischer Teil deines Systems das gesamte System lahmlegen kann. Selbst wenn wir perfekte und fehlerfreie Software schreiben könnten ("no silver bullet"), bräuchten wir sie.

Ja. Auch da ist teilweise ein Niedergang der Qualität zu beobachten. Meist auf Kosten der Haltbarkeit. Wobei das die meisten nicht stört. Denn geringe Qualität bedeutet auch oft ein niedriger Preis.

Angebot und Nachfrage im Zeitalter sinkender Reallöhne.

Viele Forumsteilnehmer hier konnten auch nur mit IT anfangen, weil es eine billige Alternative zu den qualitativ hochwertigen IBM-PCs in Form von Heimcomputern à la C64 gab.

Vor allem will auch niemand ein Gerät haben, was 20 Jahre hält weil das ist bis dahin eh hoffnungslos veraltet. Dann bezahlt man lieber weniger und "gönnt" sich öfter mal was Neues.

Betrifft das nicht speziell Elektronik, weil der rasante Fortschritt hochpreisige Anschaffungen eher unattraktiv macht? Für weniger vom technologischen Fortschritt betroffene Güter gibt es meines Eindrucks nach ein gesundes Angebot aller Preisklassen, inklusive langlebiger und hochwertiger Waren.

Und Probleme haben die ja teilweise bis heute. Man denke nur an die Exchange-Bugs Anfang des Jahres. Bei Exchange hast Du dann noch die Paarung von durchwachsener Softwarequalität bei gleichzeitig schlechter Patchbarkeit.

Bei den nichtfunktionalen Anforderungen schneidet Exchange in der Tat recht schlecht ab.

Bei den funktionalen Anforderungen hat noch niemand einen auch nur näherungsweise konkurrenzfähigen Ersatz mit der Mächtigkeit von Active Directory, Exchange, Outlook und Office erschaffen.

Aber Microsoft macht jetzt weniger Fehler, da sie weniger Code schreiben. Die werben bei uns jetzt mit LowCode / NoCode. :ugly:

Gefühlt alle zehn Jahre wird die Sau durchs Dorf getrieben. :rolleyes:
 
Es gibt entsprechende Bewegungen. Das ist aber nach wie vor eine Minderheit.
Ich war hier in Karlsruhe mal auf einer Software Craftmanship Veranstaltung. Die hatten komische Ideen wie Code Kommentare sind schlecht. Dafür fanden sie Cloud toll, heutzutage wäre es wohl Blockchain gewesen. Also ziemlich genau das Gegenteil von allem was ich für gutes Handwerk halte.
 
Zurück
Oben