Zufällig gefunden. Ein wahrer Ausspruch eines unbekannten Softwareentwicklers:
Code ist like Humor.
When you have to explain it, it’s bad.
Wohl wahr!
Werbeanzeigen
Softwareentwicklung
Zitat der Woche – überschätzte Programmierkunst
StandardEs ist bemerkenswert, dass nur vielleicht 10% aller Programmierer Programme ohne Verwendung von Flussdiagrammen erfolgreich schreiben können. Unglücklicherweise glauben aber 90%, dass sie der Gruppe dieser 10% angehören.
Rodnay Zaks
Ein bisschen Fitness muss sein
Ich hab mir jetzt vorgenommen einmal in der Woche abends vom Büro nach Hause zu laufen und dann am nächsten Morgen auch wieder ins Büro zu laufen. Eigentlich wäre das jeden Tag das Optimale, macht den Kopf frei. Allerdings sträubt sich da der innere Schweinehund gegen die knappe Stunde, die ich da unterwegs bin. Natürlich muss dann auch schönes Wetter sein.
Was motiviert und dafür spricht, ist, dass der größte Teil des Weges wirklich schön durch Grünanlagen und über Felder führt.
Man kann natürlich auch den hässlichen Weg an der Straße lang nehmen.
Bahnhof
Südtangente
Dammerstock
Rüppurr / Battstraße
Mal schauen wie sich das entwickelt.
Zitat zum Wochenanfang – Problemstellung und Coding
StandardFirst, solve the problem. Then, write the Code.
John Johnson
Zitat der Woche zur Aufwandsabschätzung – Gilt besonders für Softwareentwicklung
StandardDieselbe Arbeit unter denselben Bedingungen wird von 10 Schätzern unterschiedlich geschätzt werden oder von einem Schätzer unterschiedlich zu 10 verschiedenen Zeitpunkten.
(unbekannter Autor)
Nichts ist schwieriger wie den Aufwand einer Softwareentwicklung abzuschätzen. Man stützt sich auf die beschriebenen Anforderungen und versucht dann ein Konzept und dafür eine sinnvolle Zeitabschätzung zu finden.
Als erstes werden dann die Erfahrungswerte für ähnliches, schon entwickeltes, zu Rate gezogen.
Dann, wer schätzt ab? Wenn man einen Softwareentwickler diese Aufgabe überträgt, wird man zu keiner Aussage gelangen, oder zu so einer „sicheren“ Aussage, so, dass man das nicht mehr verkaufen kann.
Schätzt der Projektleiter mit Entwicklungserfahrung ab, wird er zu bewerten versuchen, welcher Entwickler für was zur Verfügung steht und wie lange der erfahrungsgemäß für seine Arbeit benötigt und wieviel Unterstützung er von anderer Seite braucht. Er liegt meistens schon in der richtigen Richtung, aber sein Schätzwert ist immer noch zu gering.
Schätzt der Vertriebler ab, wird die Schätzung zu 98% zu niedrig sein. Das ist sicher. Das gleiche gilt für den Chef, der ja seine Visionen verkaufen will und selten weiß was realistisch erreichbar ist.
Dann ist natürlich noch die Gemütslage am Tag der Abschätzung nicht zu vernachlässigen. Bei einem Hoch wird zu wenig Aufwand geschätzt, bei einem Tief wird der Aufwand höher, da die Herausforderungen plötzlich viel größer erscheinen, manchmal gar unerreichbar.
Aber dann kommt die Realität: Allen Abschätzungen und nach bestem Wissen und Gewissen durchgeführten Analysen und den von den zukünftigen Projektbeteiligten eingeholten Meinungen zum Trotz, wieder mal daneben gelegen und zu wenig geschätzt!
Die 12 Prinzipien des Agilen Manifests
StandardDie „Agile Alliance“, unabhängige Software Methodologen, trafen sich im Februar 2001 um miteinander zu reden und eine gemeinsame Basis zu finden.
https://www.agilealliance.org/
Sie einigten sich auf ein Manifest für die Agile Softwareentwicklung. Grundlage sind die hier wiedergegebenen 12 Grundprinzipien:
Den Kunden durch die rechtzeitige und kontinuierliche Lieferung wertvoller Software zufrieden zu stellen ist unsere höchste Zielsetzung.
Wir begrüßen Änderungen der Anforderungen, auch wenn diese spät in der Entwicklung kommen. Agile Prozesse nutzen den Wandel für den Wettbewerbsvorteil des Kunden.
Wir liefern funktionierende Software in kurzen Abständen, alle paar Wochen oder Monate, wobei wir die kürzeren Zeiträume bevorzugen.
Anwender und Entwickler müssen täglich im Projekt zusammen arbeiten.
Setze motivierte Individuen in den Projekten ein. Gib ihnen die Umgebung und Unterstützung, die sie brauchen, und vertraue ihnen, dass sie den Job bestens erledigen.
Die Konversation von Angesicht zu Angesicht ist die am meisten effiziente und effektivste Art der Informationsweitergabe an und in einem Entwicklungsteam.
Das primäre Maß für Fortschritt ist die funktionierende Software!
Agile Prozesse fördern nachhaltige Entwicklung. Die Sponsoren, Entwickler und Benutzer sollten ein gleichbleibendes Tempo ohne Unterbrechung einhalten.
Technische Exzellenz, gutes Design und deren fortwährende Beachtung verbessern die Agilität.
Einfachheit ist essentiell.
Die besten Architekturen, Anforderungen und Designs entstehen in Teams, die sich selbst organisieren.
Das Team reflektiert in regelmäßigen Intervallen darüber, wie es effektiver werden kann und passt sein Verhalten entsprechend an.
Schlaues zur Softwarequalität
StandardTesting by itself does not improve software quality. Test results are an indicator of quality, but in and of themselves, they don’t improve it. Trying to improve software quality by increasing the amount of testing is like trying to lose weight by weighing yourself more often. What you eat before you step onto the scale determines how much you will weigh, and the software development techniques you use determine how many errors testing will find. If you want to lose weight, don’t buy a new scale; change your diet. If you want to improve your software, don’t test more; develop better.
auch wieder von Steve McConell aus Code Complete
