Die Rahmenbedingungen in der Softwareentwicklung ändern sich ständig. Leicht wird dabei übersehen, worauf es bei Entwicklungs- und Produktionsprozessen wirklich ankommt:

über Problem & Lösung

"Albert Einstein once said, 'If I were given one hour to save the planet, I would spend 59 minutes defining the problem and one minute resolving it.' The problem with most businesses is that they spend 1 minute defining the problem and 59 minutes finding solutions. When I work through the creative process with organizations, I get them to spend more time finding the right opportunities rather than chasing problems they think need to be solved." (Stephen M. Shapiro, author of 'goal-free Living' and '24/7 Innovation')


über das niedrigste Angebot

"Es gibt kaum etwas auf dieser Welt, das nicht irgend jemand ein wenig schlechter machen und etwas billiger verkaufen könnte, und die Menschen, die sich nur am Preis orientieren, werden die gerechte Beute solcher Machenschaften. Es ist unklug, zuviel zu bezahlen, aber es ist noch schlechter, zu wenig zu bezahlen. Wenn Sie zu viel bezahlen, verlieren Sie etwas Geld. Das ist alles. Wenn Sie dagegen zu wenig bezahlen, verlieren Sie manchmal alles, da der gekaufte Gegenstand die ihm zugedachte Aufgabe nicht erfüllen kann. Das Gesetz der Wirtschaft verbietet es, für wenig Geld viel Wert zu erhalten. Nehmen Sie das niedrigste Angebot an, müssen Sie für das Risiko, das Sie eingehen, etwas hinzurechnen. Und wenn Sie das tun, dann haben Sie auch genug Geld, um für etwas Besseres zu bezahlen." (John Ruskin 08.02.1819 - 20.01.1900 zugeschrieben)


über Qualität & Sicherheit

Qualität und Sicherheit können einer Software nur sehr schwer nachträglich hinzugefügt werden. Bruce Schneier, Experte für Kryptographie und Computersicherheit, meint: "Writing a reliable computer program is much harder, because the program needs to work even in the face of random errors and mistakes: Murphy's computer, if you will."

Aber: "Writing a secure computer program is another matter entirely. Security involves making sure things work, not in the presence of random faults, but in the face of an intelligent and malicious adversary trying to ensure that things fail in the worst possible way at the worst possible time ... again and again. It truly is programming Satan's computer."


über Investition

"Die Praxis zeigt immer wieder, dass die eigentliche Kostenfalle für Unternehmen nicht im Tätigen von IT-Investitionen, sondern in deren Unterlassung besteht." (Klima, Die IT-Revolution - 1o Thesen für Ihren Unternehmenserfolg, 2008, Molden Wien, S.38)

"Eine Investition in Wissen bringt noch immer die besten Zinsen." (Benjamin Franklin, 17.01.1706 - 17.04.1790, US-Staatsmann, Ökonom und Naturforscher)


über die Kunst der Konzeption

"Bei jedem Kunstwerk, groß oder klein, bis ins kleinste, kommt alles auf die Konzeption an." - Goethe

"Imagination is more important than knowledge. For knowledge is limited [...]." - Albert Einstein

Es ist besser, mit einem einfallsreichen Versuch zu scheitern, als erprobtes nachzuahmen und damit Erfolg zu haben. Wer nie irgendwo versagt hat, ist kein bedeutender Mensch. Man sagt, fortgesetzter Erfolg beweise, dass jemand seine Fähigkeiten klug einschätzt; es sollte jedoch hinzugefügt werden, dass der Betreffende in diesem Fall auch weiß, wie gering sie sind.


über Arbeit & Leistung

Arbeit ist Leistung mal Zeit, nicht Leistung durch Zeit! Wer seine Leistung nicht in Arbeit umsetzen kann, hat seinen Job missverstanden.


über die Komplexität

"Everything should be made as simple as possible, but not simpler." Albert Einstein wird mit seiner Aussage oft zitiert. Sehr oft sogar. Auch richtig verstanden? Wir haben Zweifel!

Vertiefen Sie sich einen Augenblick in seine Aussage. Lesen Sie nicht weiter. Es ist wichtig. Denken Sie nach. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Könnten Sie irgendjemand den Satz jetzt erklären? - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Nein? Ja? Schreiben Sie uns, wenn Ihnen eine bessere Interpretation gelungen ist: "Man muss so lange streichen, bis man nichts mehr weglassen kann, ohne das Wesen zu verändern." (Brandes, Einfach managen, S.41, 2002 Redline Wirtschaft bei Ueberreuter)


Richtig ist:

"Komplexität vermeiden
Maßgeblich hierfür ist die Klarheit über Strategien, Ziele und Absichten auch über den Sinn von Projekten. Einfach wird es, wenn man dann auf alles verzichtet, was dem Ziel nicht dient." (Brandes, INSight 4/06 S.11)

"Komplexität reduzieren
Wenn Komplexität nicht zu vermeiden ist, dann sollte sie auf ein Minimum reduziert werden. Da braucht man unter Beachtung der Ziele Mut zum Verzicht." (Brandes, INSight 4/06 S.11)

"Komplexität beherrschen
Der notwendige Rest an Komplexität muss beherrscht werden. Das System muss entsprechend dem Ziel gut funktionieren. Die Lösung dafür liegt in der Organisation. Die Lösungsmittel heißen klare Verantwortung, Vertrauen und Kontrolle. Als Hilfsmittel dient die Maxime: Richtig ist das zu machen, was notwendig und sinnvoll ist. Falsch ist, alles das zu machen, was möglich ist ("nice to have")." (Brandes, INSight 4/06 S.11)


über Aufwand

Aufwand ist stets unscharf. Niemand kann Aufwand wirklich genau bestimmen. Damit Software-Projekte (annähernd) gelingen, ist eine gute Schätzung des Aufwandes unerlässlich. Hierfür sind aus der Literatur verschiedene etablierte Verfahren bekannt, z.B. COnstructive COst MOdel (CoCoMo) oder Function Point. Diese führen laut einer übergreifenden Studie1 nicht zu besseren Ergebnissen als Expertenschätzungen. In der Praxis werden überwiegend Expertenschätzungen gemacht.

1 Kjetil Moløkken and Magne Jørgensen: "A Review of Surveys on Software Effort Estimation", IEEE International Symposium on Empirical Software Engineering (ISESE) 2003. September 30 - October 1, Rome, Italy.


über Softwareentwickler & Dilettanten

"Nur wer Anforderungen wirklich versteht, kann sie einfacher und klarer lösen. Ein guter Entwickler löst die Anforderungen kompakter und in kürzerer Zeit als ein mittelmäßiger." (Stefan Bachert, aboutIT)

"Ein guter Softwareentwickler wird nicht nur darauf schauen, dass er so viel Software wie möglich wieder verwendet, sondern auch darauf, dass neu entwickelte Software einfach wieder verwendbar wird. Die Erfahrung zeigt, dass durch objektorientierte Programmierung tatsächlich Codewiederverwendung erzielbar ist. Kosteneinsparungen ergeben sich dadurch aber normalerweise nur, wenn die Softwareentwickler ausreichend erfahren sind, um die Möglichkeiten optimal zu nutzen und Zeit in die Wiederverwendbarkeit investiert wird. Weniger erfahrene Entwickler investieren oft zu wenig oder zu viel oder an falscher Stelle in die Wiederverwendbarkeit von Klassen und Komponenten. Solche Fehlentscheidungen können sich später rächen und, durch lange Entwicklungszeiten, sogar zum Scheitern eines Projekts führen." (Ao.Univ.Prof. Dipl.-Ing. Dr. Franz Puntigam, Technische Universität Wien, Institut für Computersprachen (E185))

denk & dachte plant bereits im Design die Wiederverwendung von Entwurfsmustern. Wenn auch Sie sich für dieses Thema interessieren: Head First Design Patterns, O'Reilly Media Inc., 2004. - Übersetzung: Entwurfsmuster von Kopf bis Fuß, O'Reilly Verlag, 2006 - 2008.

"Die Dilettanten, wenn sie das Möglichste getan haben, pflegen zu ihrer Entschuldigung zu sagen, die Arbeit sei noch nicht fertig. Freilich kann sie nie fertig werden, weil sie nie recht angefangen ward. Der Meister stellt sein Werk mit wenigen Strichen als fertig dar; ausgeführt oder nicht, schon ist es vollendet. Der geschickteste Dilettant tastet im Ungewissen, und wie die Ausführung wächst, kommt die Unsicherheit der ersten Anlage immer mehr zum Vorschein." (Goethe). "Ganz zuletzt entdeckt sich erst das Verfehlte, das nicht auszugleichen ist, und so kann das Werk freilich nicht fertig werden. Das ist eben das Wesen der Dilettanten, dass sie die Schwierigkeiten nicht kennen, die in einer Sache liegen, und dass sie immer etwas unternehmen wollen, wozu sie keine Kräfte haben." (Johann Peter Eckermann, Gespräche mit Goethe)


über Handbücher

"Der Unterschied zwischen dem richtigen Wort und dem beinah richtigen ist derselbe Unterschied wie zwischen dem Blitz und einem Glühwürmchen" (Mark Twain)

"Schreiben ist wie das Leben ein ständiger Lernprozess. Niemand wird als reifer Künstler geboren, also erst mal schreiben, später dann kann man Ideen bewerten und Texte redigieren, doch erst mal soll man sich gestatten, die Wörter fließen zu lassen, Texte zu Papier zu bringen." (Edith Sowa, Wien)

1842
verfasste Ada Lovelace, Tochter von Lord Byron, das erste Software-Handbuch für Programmierer. Zuvor hatte Charles Babbage Differenz- und Analysemaschinen konstruiert, die als Vorläufer der Computer gelten (aus Wikipedia).
161 Jahre später
"In der Praxis haben aktuelle und vollständige Projekthandbücher, die den Projektleiter und seine Teammitarbeiter bei ihrer Arbeit unterstützen noch Seltenheitswert."
(Grupp, Der professionelle IT-Projektleiter, 2003 mitp S.41)

Aber wie schreibt man ein Handbuch? Es gibt nur zwei Möglichkeiten:

entweder bildhaft, einprägsam, verständlich1

"Die Mutter kocht in der Küche."

oder abstrakt

"Der weibliche Elternteil ist im Begriff, die für Nahrungszubereitungs-Maßnahmen reservierte Raumeinheit im Sinne der entsprechend dafür vorgesehenen Arbeitsabläufe der Nutzung zuzuführen."

Zitate aus 'Denken, Lernen, Vergessen', Frederic Vester, 2006 dtv S.156

1Wer das nicht kann, dem sei 'Die Sendung mit der Maus' (ARD) empfohlen.


über den Erhalt der Leistungsfähigkeit

In China sagt man: "Die Zeit, die Du Dir nicht für Deine Gesundheit nimmst, nimmt sich die Krankheit."

1

Unseren Kunden exzellente Leistungen bieten, Arbeiten in Topqualität, das ist Sinn und Ziel unseres Unternehmens. "Wer anderen nützt, nützt sich selber", sagt Seneca.

2

Unterschätzen Sie nie die Wichtigkeit einer guten Software-Konstruktion. Alles hängt von ihr ab. Der Aufwand für den Bau und Betrieb des Systems von der Vision bis zur Stilllegung. Auch das Verhältnis der Kosten zum Nutzen oder der Zeitpunkt, ab wann dieser Nutzen verfügbar ist.

3

Keine Programmiersprache kann ...

... für sich den Anspruch erheben, als Einzige richtig oder sinnvoll zu sein. Im Prinzip lässt sich jedes Problem in jeder Sprache lösen. Nur

unterschiedlich zeitaufwendig,
unterschiedlich leistungsfähig,
unterschiedlich pflegeaufwendig,
unterschiedlich portierbar,
unterschiedlich skalierbar,
unterschiedlich plattformabhängig,
unterschiedlich dokumentierbar und
unterschiedlich erlernbar.

Denkfehler in Konzeptphasen verursachen hohe Kosten und erfordern fast regelmäßig Terminverschiebungen, weil sie meist viel zu spät entdeckt werden. Wir versuchen gezielt, den größten Fehler zu finden und zu verhindern. Und den gibt es in fast jedem Projekt.

K

Konfuzius

Ist man in kleinen Dingen nicht geduldig, bringt man die großen Vorhaben zum Scheitern. Konfuzius