Werden Programme noch optimiert?

[undefiniert]

Wenn man sich neuere Programme so anschaut, dann könnte man eher meinen, sie werden so geschrieben, dass sie möglichst viel Performance fressen. Sind die Programmierer nicht mehr in der lage zu optimieren oder haben sie keine Zeit dazu oder werden sie sogar von den Hardware herstellern bezahlt?

[Fatality]

ein bischen hiervon und ein bischen davon.

[Trap]

Optimierung kommt dran wenn man zwischen dem Einbau des letzten Feature und dem Releasetermin noch Zeit hat ;)

[EcHo]

Eines meiner "Haß"- Thema.

Klar werden Programme noch optimiert, siehe aktuell Java 1.6! 20-60% schneller.

Aber was heißt den optimiert? Auf Geschwindigkeit? Auf Speicherverbrauch? Auf Startzeit? Auf Reaktivität? Auf Last auf der DB?

Was ist mit Wartbarkeit? Klar, braucht kein User. Aber mal kurz die Funktion einbauen, muss doch drin sein, oder? Sicher soll's auch sein, günstig sowieso.
Klar, es gibt Standard-Optimierungen, die werden aber zum sehr großen Teil auch gemacht. (Natürlich gibt es auch Ausnahmen; Programme die wirklich schrottig programmiert sind.)

Gerne wird ja auch das Beispiel einer Textverarbeitung herran gezogen, die ja früher viel weniger Leistung gebraucht hat. Da war dann aber auch keine Rechtschreibprüfung dabei oder Autoformatierung usw.

Und das die Programmierer von Hardwarefirmen bezahlt werden, halte ich für sehr unwahrscheinlich.

[ooAlbert]

ich vermute mal es geht darum das aus oft unerklärlichen gründen anwendungen unmengen an kapazitäten verlangen für eine augenscheinlich simplen vorgang :)

[RMC]

Aber was heißt den optimiert? Auf Geschwindigkeit? Auf Speicherverbrauch? Auf Startzeit? Auf Reaktivität? Auf Last auf der DB? Was ist mit Wartbarkeit?

Jo, richtig. Auf was eigentlich?

Die User wollen immer unheimlich schnelle Programme, die kaum Platz verbrauchen und somit auch schnell im Speicher sind, Abfragen in Millisekunden erledigen und natürlich alle Stückerln einer eierlegenden Wollmilchsau spielen. Achja...relativ erschwinglich solls ja auch noch sein sonst kaufts ja keiner.

Dass das unrealistisch ist, wissen wir alle. Abstriche müssen immer gemacht werden. Man muss halt aufgrund der Kunden/Umfeld etc. entscheiden, was am Wenigsten weh tut.

Irgenwie müssen die Programme ja auch so übersichtlich und wartbar sein, dass man sie noch anschaun kann (imho einer der wichtigsten Punkte), auch wenn dadurch etwas Performance verloren geht. Programme, die wartungsunfreundlich und schwer erweitbar sind, Kosten dann auf lange Sicht ein Vielfaches.

[aths]

Wenn man sich neuere Programme so anschaut, dann könnte man eher meinen, sie werden so geschrieben, dass sie möglichst viel Performance fressen. Sind die Programmierer nicht mehr in der lage zu optimieren oder haben sie keine Zeit dazu oder werden sie sogar von den Hardware herstellern bezahlt?Natürlich werden Programme noch optimiert. Aber Optimierung auf das letzte Prozent Performance ist wirtschaftlich unsinnig. Einfache Optimierungstricks hat jeder Compiler drauf. Dann nutzen Programmierer in der Regel Algorithmen, die für das gegebene Problem möglichst effizient sind. Irgendwo mal von Hand einen Registerzugriff wegzuoptimieren, kostet aber mehr Aufwand als es Nutzen bringt.


Irgenwie müssen die Programme ja auch so übersichtlich und wartbar sein, dass man sie noch anschaun kann (imho einer der wichtigsten Punkte), auch wenn dadurch etwas Performance verloren geht. Programme, die wartungsunfreundlich und schwer erweitbar sind, Kosten dann auf lange Sicht ein Vielfaches.Lesbarer, wartbarer, erweiterbarer Code ist in der Tat viel wichtiger, als die Performance-Optimierung auf das letzte Prozent. Dass vermehrt dazu übergegangen wird, Code nicht mehr direkt auf dem Prozessor auszuführen, anstelle dessen auf einer virtuellen Maschine gearbeitet wird, kostet auch Performance. Hat aber auf der anderen Seite auch seine Vorteile.

Was nicht heißt dass ich nicht dafür wäre, dass Programme schneller laden und dass Windows beim Task-Umschalten weniger träge reagiert.

[wrdaniel]

Find' schon das Programme noch optimiert werde, leider oft im Bereich der Optik und werbewirksamer Spielereien.

[Coda]

Nein natürlich nicht! Alle Entwickler sind heutzutage völlig verblödet, unfähig und dazu noch faul!

[Juerg]

Nein natürlich nicht! Alle Entwickler sind heutzutage völlig verblödet, unfähig und dazu noch faul!;D Arrogant, geldgierieg und bleich sind diese A....löcher aus noch... :crazy: :lol: :ucrazy3: :ulol4:

Also von all den Eigenschaften würde ich Faulheit am ehesten als Vorurteil durchgehen lassen. Dies ist manchmal sogar der Motor von erstaunlicher Kreativität :weg:

[tokugawa]

Wenn man sich neuere Programme so anschaut, dann könnte man eher meinen, sie werden so geschrieben, dass sie möglichst viel Performance fressen. Sind die Programmierer nicht mehr in der lage zu optimieren oder haben sie keine Zeit dazu oder werden sie sogar von den Hardware herstellern bezahlt?

Deine Einschätzung ist falsch :)

Mehr will ich dazu nicht mehr sagen...

[ollix]

Nein natürlich nicht! Alle Entwickler sind heutzutage völlig verblödet, unfähig und dazu noch faul! Genau, weil die keine Spiele komplett in Assembler schreiben! (das Wort fehlte noch im Thread) ;D

[cope]

JA :smile:

[Monger]

Kaum einer wird wohl einen Code nach Fertigstellung noch groß optimieren. Viel zu aufwändig, viel zu teuer.
Entweder man macht es gleich beim ersten Anlauf richtig, oder gar nicht. Den Kaufleuten klarzumachen warum man jetzt noch 3 Monate Arbeit dranhängen soll, obwohl man das Produkt auch schon verkaufen könnte, ist gar nicht so einfach! ;)

[Djon]

Hallo!

Also ich bin an einem Projekt beteiligt, wo insgesamt 3 Studenten und ein festeingestellter Mitarbeiter beteiligt sind. Es geht um eine Personalplanungssoftware für den örtlich ansässigen ÖPNV und es ist so, dass die Optimierungen in der jetztigen Phase garnicht gewünscht sind (seitens der Auftragnehmer). Das Programm soll funktionieren, soll einigermaßen performt sein, aber die ganzen Optimierungen / Performancesteigerungen werden später als eine neue Version verkauft. Ist eine gute Idee, so kann man sich weitere Aufträge sichern und den Auftraggeben an sich binden :biggrin:

Zum Topic: Optimierung ja, aber erst dann, wenn es ausdrücklich gefordert wird.

Mfg Djon

[Gast]

hmm... Lass mal überlegen, ich optimiere ein Programm wochenlang und verkaufe es oder ich optimiere es nicht und verkaufe es exakt gleich, weil der Kunde eh nicht sieht, ob es optimiert ist oder nicht.. hmmm...
Und was bau ich in Version n+1 ein, damit der Kunde das Programm nochmal kauft? Soll meine Textverarbeitung schneller laden, weniger Speicher verbrauchen, weniger CPU resourcen, da es ja nur eine Textverarbeitung ist oder bau ich ein dass er sich die Farbe der Buttons selbst aussuchen kann, auch wenn der Kunde dafür dann mehr als 1GB-Ram braucht um seinen Text zu tippen? Ich glaube eine Software die "individualisierbar" ist, verkauft sich besser, macht weniger Arbeit.... schwere Entscheidung.

[cope]

Der Meinung von Djon kann ich mich nicht anschließen, wenn ich die Kunden meiner Firma so behandeln würde, freut sich früher oder später die Konkurenz. Nach dem Motto, eine Berechnung dauert 4h im nächsten Release nur 10 min. Gerade bei der Performance sollte man sich schon vorher Gedanken machen und die Struktur danach aufbauen / entwerfen. Auf der anderen Seite bringen solche Arbeitsweisen meiner Firma mehr Kunden :cool: Ich denke ein neues Release sollte mit neuen Funktionen punkten, ist marketingtechnisch auch besser zu verkaufen. Der Gast vor mir sprach es ja schon an.

@Monger Sollte nicht vorkommen, aber man muss je nach Anwendnunggebiet schon noch nach dem ersten Release optimieren. Dafür hat man ja Wartungsverträge um Patches (bezahlt) nachzuliefern zu können.

Wie aths schon richtig ausführte, bis aufs letzte wird nicht optimiert - außer zeitkritische Anwendungen.

[Baalzamon]

Ich habe schon sehr früh die beiden Regeln der Optimierung gelernt:

Rules of Optimization:
Rule 1: Don't do it.
Rule 2 (for experts only): Don't do it yet.
- M.A. Jackson

Um den genauen Ausspruch zu finden bin ich auch noch auf diese wunderbaren Zitate gestoßen:

"More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason - including blind stupidity."
- W.A. Wulf

"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil."
- Donald Knuth

"The best is the enemy of the good."
- Voltaire

[Gast]

Sinnvolle Vorgehensweise:
Programmieren ohne großartig zu optimieren.
Wenn fertig, VTune anschmeissen und nur die wichtigen Stellen optimieren.
95% Arbeit und Geld gespart.
Wobei Performance bei vielen Sachen einfach keine Rolle mehr spielt.

[Monger]

Da müsste man sich mal darauf einigen, was man unter "Optimierung" versteht.

Unter "Optimierung" würde ich z.B. auch verstehen, nicht völlig inperformante Datenkonstrukte zu verwenden. Z.B. nicht einfach mal achtlos irgendwo nen Bubble Sort reinschmeißen.

Aber Premature Optimization ist natürlich quatsch. Solange ein Projekt sauber strukturiert ist, kommt da normalerweise auch was performantes raus. Um Gottes Willen keine komischen Hacks reinbauen, wenn das auf Kosten von Übersicht und Wartbarkeit geht.

[mapel110]

Sicher soll's auch sein.
Das ist wohl in der Zeit als das Internet aufkam (bis heute), sehr stark berücksichtigt worden. Das dürfte imo den größten Zeitaufwand, den der User letztenendes nicht merkt, beim Programmieren ausmachen. Und das treibt die Kosten hoch, ohne dass der User eben einen Gegenwert zu spüren bekommt.

[Gast]

Jo, und weil Sicherheit so wichtig ist, nimmt man halt gerne Systeme die sich selbst überwachen (Java, .NET etc.), was sich dann wieder auf die Geschwindigkeit auswirkt.

[Gast]

Optimierung kommt dran wenn man zwischen dem Einbau des letzten Feature und dem Releasetermin noch Zeit hat ;)

Huch! Die (letzten) Features werden noch vor dem Releasetermin eingebaut?
Verdammt, dachte wir würden das mit irgend nem Patch nachliefern. ;-)

[Gast]

...

#include <iostream>
#include <sting>

using namespace std;

string undefiniert="Wenn man sich neuere Programme so anschaut, dann könnte man eher meinen, sie werden so geschrieben, dass sie möglichst viel Performance fressen. Sind die Programmierer nicht mehr in der lage zu optimieren oder haben sie keine Zeit dazu oder werden sie sogar von den Hardware herstellern bezahlt?";

#define gast undefiniert


int main()
{
cout << gast;
return 0;
}




# SO, jetzt ist es RICHTIG!
# Denn undefiniertes ist nicht optimiert.

[Elemental]

Bei uns verhindert eigentlich immer der Termindruck das optimiert werden kann. ProjectManagement will eh immer so viele Features in einer neuen Version haben, die unmöglich zu schaffen sind!
Dann muss man schonmal etliche Features über Board werfen, um überhaupt den Termin halten zu können und für Optimierungen is dann halt auch keine Zeit...

[Gast]

also ist einfach das management schuld und damit unsere wirtschaftsauslegung(geiz lässt grüßen).... das übliche also

[ShadowXX]

Bei uns verhindert eigentlich immer der Termindruck das optimiert werden kann. ProjectManagement will eh immer so viele Features in einer neuen Version haben, die unmöglich zu schaffen sind!
Dann muss man schonmal etliche Features über Board werfen, um überhaupt den Termin halten zu können und für Optimierungen is dann halt auch keine Zeit...
Dem schließe ich mich mal an.....Optimierungen kommen nach dem Release und auch nur dann, wenn es unbedingt sein muss (denn die nächste Version mit 250 neuen Funktionen muss ja auch fertig werden).

[Gast]

Deine Einschätzung ist falsch :)

Mehr will ich dazu nicht mehr sagen...
Beweist erstmal das Gegenteil, bevor ihrs Maul aufreißt.

[RMC]

Dem schließe ich mich mal an.....Optimierungen kommen nach dem Release und auch nur dann, wenn es unbedingt sein muss (denn die nächste Version mit 250 neuen Funktionen muss ja auch fertig werden).

Vielleicht wären weniger, dafür ausgereifte und gut designte, überlegte Funktionen besser. Das Problem bei neuer Software (vorallem bei OpenSource) ist die Vielzahl an unübersichtlich platzierten Funktionen, die kein Mensch braucht. Kann zwar viel, aber wen scherts? Und gerade die _wichtigsten_ Funktionen (sind meist die einfachsten, die aber sehr essentiell sind und die man oft braucht) geraten dadurch in den Hintergrund.

Schließlich hat man dann nach einigen Release-Versionen ein überladenes Programm mit jede Menge (laut den Herstellern) guten Funktionen, die 90% der Anwender nie brauchen.

Und das is schlechtes Design. Sieht man heute gar nicht so selten. ("Simplicity, was soll das sein?")

[Monger]

Vielleicht wären weniger, dafür ausgereifte und gut designte, überlegte Funktionen besser.
Bestimmt. Aber dazu bräuchte es gute Projektmanager, und gute Softwareingenieure (!= Coder).

Ich merks halt bei uns: die meisten Entwickler haben irgendwann mal vor 25 Jahren Elektrotechnik studiert, und sind die Informatik über die Hintertüre reingekommen.
Ich komme gerade von einem Seminar, da halten die meisten Teilnehmer prozedurale Programmierung für State-Of-The-Art. Ich hab vor ein paar Monate erlebt, wie eine Entwicklungsabteilung ganz stolz verkündet hat, dass sie jetzt ihre Projektplanung modernisiert haben. Sie verwenden jetzt das V-Modell...

Sich ein paar kleine Bibliotheken zusammenzufrickeln schafft man mit Hilfe der Programmierer doch immer noch ganz gut. Aber wirklich große Projekte zu organisiern, ohne dass Budget und Zeitplan dramatisch überzogen werden, das schaffen nicht viele. Wenn es um strukturelles Know-How geht, trennt sich ganz schnell die Spreu vom Weizen, und da gibt es halt nur einige ganz wenige Firmen weltweit, die ihre Prozesse wirklich im Griff haben.
Zumindest mein Bereich gehört da definitiv nicht dazu. :(
Ein Glück kann man auch als einäugiger noch König werden...

[Demirug]

Ich könnte jetzt mal Böse sein und behaupten keiner hat den Prozess wirklich im Griff. Statistisch gesehen könnte man die wenigen Projekte die im Zeitplan und Budget geblieben sind und trotzdem am Ende auch wirklich alle ursprünglichen Forderungen erfüllen auch als Zufälle sehen.

Deswegen sind doch die Agilen Prozesse so populär geworden. Meist hat man nach der Hälfte der Sprints immerhin etwas was man verkaufen könnte. Das Optimieren fällt natürlich meist in die letzten Sprints für die dann am Ende keine Zeit mehr ist.

[Monger]

Vielleicht bin ich ja einfach zu jung und zu idealistisch, aber dass sich so katastrophale Fehlplanungen nicht vermeiden lassen, will ich einfach nicht akzeptieren! :mad:

Agile Prozesse sind klasse. Aber auch die haben ja zum Ziel, vielleicht nicht feature-complete, aber wenigstens einigermaßen bugfrei auf den Markt zu kommen. Wenn ich sowas hier sehen würde, wäre ich ja schonmal glücklich. (Und ich meine nicht diese typischen Microsoft-Bugs, die doch meistens eher unschön, und nicht etwa lebensbedrohlich sind. Ich meine RICHTIGE Bugs!) Bugs kosten ja im Endeffekt auch die Firma Geld, so wie Bauingenieure die Firma effektiv Geld kosten, wenn sie damit beschäftigt sind ihre uralten Projekte zu sanieren, statt Geld mit dem nächsten, neuen Wolkenkratzer zu verdienen.

[Trap]

Vielleicht bin ich ja einfach zu jung und zu idealistisch, aber dass sich so katastrophale Fehlplanungen nicht vermeiden lassen, will ich einfach nicht akzeptieren! :mad:
Da gibt es kein Problembewusstsein, damit sucht man auch nicht nach den Ursachen und kann auch keine evtl. besser funktionierenden Alternativen finden.

Schon bei der Aufwandsschätzung fängt es an. Wer hier kennt eine Methode um genau genug zu schätzen, dass man mit der Schätzung irgendwas anfangen kann? Wer hat in einer Vorlesung dazu was gehört?

[tokugawa]

Beweist erstmal das Gegenteil, bevor ihrs Maul aufreißt.

Der Beweisnotstand liegt bei euch, denn ihr habt die Behauptung aufgestellt! (und das "Maul aufgerissen")


PS: die Suchfunktion hilft auch, denn das Thema wurde tausendmal durchgekaut.

[Ganon]

Ich finde es eigentlich auch immer blöd, wenn man sich entscheiden muss, wie lange man braucht. Diese "Schätzungen" sind meist eh für'n Ar...Hintern.

Man weiß nie was noch irgendwo dazwischen kommt, oder wo es Probleme geben kann, oder sonst was. Seien es Probleme auf tieferer Systemebene, oder einfach Sachen wie Krankheit oder Computerausfälle.

Ich meine selbst in Bereichen wo die Arbeitsschritte und Laufzeiten festgelegt sind, geht eine feste Planung meist nie auf. Stichwort Plantafeln in Fertigungs-Betrieben. Ohne dauerndes schieben, wird das nix. Irgendwas kommt immer.

[Monger]

Schon bei der Aufwandsschätzung fängt es an. Wer hier kennt eine Methode um genau genug zu schätzen, dass man mit der Schätzung irgendwas anfangen kann? Wer hat in einer Vorlesung dazu was gehört?

Ich hab da noch ein paar Sachen dunkel in Erinnerung. Ehrlich gesagt, damals habe ich das nicht ernst genommen, denn entweder habe ich diese Verfahren für selbstverständlich gehalten, oder sie schienen mir nur Zahlendreherei zu sein. Aber wenn man erstmal gesehen hat, wie meilenweit da daneben geplant wird, weil halt die Entscheider überhaupt keine Maßstäbe mehr haben um sowas einzuschätzen (auch persönliche Erfahrung fällt da ja oftmals weg), sieht man plötzlich vieles in einem anderen Licht...


Man weiß nie was noch irgendwo dazwischen kommt, oder wo es Probleme geben kann, oder sonst was. Seien es Probleme auf tieferer Systemebene, oder einfach Sachen wie Krankheit oder Computerausfälle.


Für sowas gibt es recht zuverlässige Schätzwerte. Da darf man halt nicht 100% oder gar 110% Leistung für jeden Mannmonat einrechnen, sondern allenfalls 70%. Aber sowas lässt sich halt dem Vorstand schlecht verkaufen...

[ollix]

Ich finde es eigentlich auch immer blöd, wenn man sich entscheiden muss, wie lange man braucht. Diese "Schätzungen" sind meist eh für'n Ar...Hintern. Dazu werden realistische/pessimistische Schätzungen sowieso nicht mal gerne gehört, sondern lieber "Hurra, wir schaffen das" (....NOT!)

[Trap]

Ich finde es eigentlich auch immer blöd, wenn man sich entscheiden muss, wie lange man braucht. Diese "Schätzungen" sind meist eh für'n Ar...Hintern.
Es ist aber auch eines der wichtigsten Dinge die man zu einem Projekt wissen möchte: Wie teuer wird das? Was würdest du ohne einen verlässlichen Kostenvoranschlag in Auftrag geben?

Ja, die Schätzungen sind meist völliger Unsinn, das liegt aber meiner Meinung nach daran, dass man keine geeignete Methode dafür benutzt und die Eigenschaften der ungeeigneten Methode, die man benutzt, auch nicht kennt.

[Demirug]

Ja, die Schätzungen sind meist völliger Unsinn, das liegt aber meiner Meinung nach daran, dass man keine geeignete Methode dafür benutzt und die Eigenschaften der ungeeigneten Methode, die man benutzt, auch nicht kennt.

Und welche Methode funktioniert?

Softwareentwicklung ist IMHO aufgrund des immer noch sehr hohen Anteils an Forschung bei jedem etwas anspruchsvollerem Projekt nicht mit anderen Ingenieursleistungen vergleichbar.

[ooAlbert]

Also die ausreden die zeit war knapp und deshalb gibts nur halbgare produkte find ich sehr fadenscheinig. Zumal es eigentlich nur die eigene selbstüberschätzung wiederspiegelt.

Ich bin der meinung diese planungsdefizite kommen oft auch durch den wirtschaftlichen druck zustande ("hauptsache verkaufen"). Das problem hierbei der Kunde merkt sehr wohl ob er verschaukelt wird oder nicht und selbst monopolisten wie Microsoft kommt jetzt ins straucheln, siehe vista.

Desweiteren lassen sich aufgeblähte Programme schon mit gescheiter vorüberlegung gut eindämmen. In dem eben nicht nur zusammengeglebt wird ;) Ich erleb es immer wieder das Programmierer wie auch informatiker diese unproduktive AdHoc methodik anwenden und sichd ann wundern das es nichts wird.

Desweiteren sollte in jeder projektplanung auch der fackt des "stecken bleibens" einkalkuliert sein. Problemlösungen fallen nämlich nicht vom himmel.

außerdem ist es doch nicht verwunderlich wenn sich der endkunde langsam fragt warum er schon wieder neue hardwae brauchen soll für ein programm, warum die neue software sich im verbrauch von Speicher und CPU leistung so ausdehnt ohne einen anlaß der notwendigkeit zu bieten.

Hierbei ist es übrigens egal ob es unterhaltungs- oder anwendungssoftware ist :)

[ShadowXX]

Vielleicht wären weniger, dafür ausgereifte und gut designte, überlegte Funktionen besser. Das Problem bei neuer Software (vorallem bei OpenSource) ist die Vielzahl an unübersichtlich platzierten Funktionen, die kein Mensch braucht. Kann zwar viel, aber wen scherts? Und gerade die _wichtigsten_ Funktionen (sind meist die einfachsten, die aber sehr essentiell sind und die man oft braucht) geraten dadurch in den Hintergrund.

Schließlich hat man dann nach einigen Release-Versionen ein überladenes Programm mit jede Menge (laut den Herstellern) guten Funktionen, die 90% der Anwender nie brauchen.

Und das is schlechtes Design. Sieht man heute gar nicht so selten. ("Simplicity, was soll das sein?")
Ich gebe dir ja vollkommen Recht....nur leider entscheiden nicht wir Coder darüber, sondern die Geschäftsführer, das Marketing und teilweise der Vertrieb.

Da können wir 10x sagen: Wir brauchen mehr Zeit, das wird völlig ignoriert.
Im besten Falle bekommt man dann 1ne Woche mehr, aber gleichzeitig den Auftrag dann auch noch 3 andere Funktionen einzubauen.

Die Zeiten werden auch nicht von uns vorgegeben, sondern von oben (OK, wir dürfen unsere Meinung dazu sagen und vielleicht wird dadurch aus 2 Wochen dann mal 3 Wochen....obwohl wir gerne 2 Monate hätten).

Dazu kommt das die Forderungen der Anwender immer extremer werden....wir sollen denen inzwischen das Denken und Arbeiten abnehmen (also das, wofür diese eigentlich bezahlt werden).
Gerade heute hatte wir wieder ein "Meeting" wo ich dann Einwarf: "Wenn wir das so Programmieren sollen, dann kann deren Job (also der Job von den Leuten die unsere Software einsetzen) auch ein dressierte Affe übernehmen".
Mir wurde zwar zugestimmt, aber das Problem bleibt nunmal, das diese Leute darüber entscheiden ob die Software gekauft wird oder nicht und wir uns deshalb nach deren Wünschen ausrichten müssen.

Alleine dadurch wird die Software immer komplexer und fehleranfälliger....der Core-Code (also derjenige Teil des Codes der eigentlich die "produktive" Arbeit macht) nimmt inzwischen nur noch 20% ein, die restlichen 80% sind GUI, Wizzards, Hilfstexte, Abfangen von schwachsinnigen Usereingaben & Co.
Und das nur, weil sich die Benutzer der Software weigern das zu tun wo für Sie eigentlich eingestellt wurden: Auskennen in der Materie und die Fähigkeit aus den gesammelten Daten selbst Rückschlüsse bilden zu können.

Gerade letzte Woche hat sich ein Kunde (ein sehr großer) bei uns Beschwert, das es doch unsere Aufgabe sei dafür zu sorgen, das unsere Software bei Ihnen auf entsprechenden Rechnern läuft....wir sollen also bei denen vorbeigehen und deren Admins/Technikern auf die Finger schauen ob diese Ihren Job ordentlich machen, also die Rechner für die User so konfigurieren das unsere Mindestangaben (die in der Anleitung, auf der Rückseite der DVD-Hülle und zusätzlich nochmal in Form eines beigelegten Flyers vorliegen) erfüllt sind.
Unser Management konnte Sie dann (in einem 10-Stündigen Verhandlungs-Marathon, 4 Stunden davon durfte ich ebenfalls über mich ergehen lassen) davon überzeugen, das diese nun wirklich nicht zu unserem Aufgabenbereich gehört.
Und was passiert: Nun wurde ein zusätzlicher Vertrag abgeschlossen, das wir dieses tatsächlich tun sollen (für Geld versteht sich)...scheinbar ist deren Vertrauen in deren IT nicht besonders hoch.

Du kannst dir vorstellen wie "hoch erfreut" deren IT über unseren Besuch am nächsten Tag war...und noch erfreuter waren Sie, als Sie hörten das wir von nun an für große Teile Ihres Rechnerparks verantwortlich sind.

Ach ja....nebenbei sollen wir dann auch noch programmieren.......

(Der letzte Absatz sollte etwas dazu dienen um zu verdeutlichen, das es durchaus auch noch andere Gründe gibt, das nicht mehr so viel optimiert wird....man verplempert unglaublich viel Zeit mit anderen Sachen.)


(wie auch schon mehrmals erwähnt)

[RMC]

Und welche Methode funktioniert?

Das frag ich mich auch. Wär sie bereits gefunden, gäbs keine Probleme mehr.


Also die ausreden die zeit war knapp und deshalb gibts nur halbgare produkte find ich sehr fadenscheinig. Zumal es eigentlich nur die eigene selbstüberschätzung wiederspiegelt.

Ich bin der meinung diese planungsdefizite kommen oft auch durch den wirtschaftlichen druck zustande ("hauptsache verkaufen"). Das problem hierbei der Kunde merkt sehr wohl ob er verschaukelt wird oder nicht und selbst monopolisten wie Microsoft kommt jetzt ins straucheln, siehe vista.

Desweiteren sollte in jeder projektplanung auch der fackt des "stecken bleibens" einkalkuliert sein. Problemlösungen fallen nämlich nicht vom himmel.

Ausreden hat man immer. Die Sache ist nur, dass überall mittlerweile eingespart werden "muss", und das trifft eben auch die Softwarebranche. Wie sich das auswirkt, sieht man eh. Software reift beim Kunden. Keine Zeit mehr für ausreichende Tests, lieber ein paar Funktionen mehr, weil das sieht am Papier besser aus. Für die Geldgeber oder die Publisher zählt halt nur das nächste Quartal. Das Beispiel JoWood dürfte eigentlich schon bekannt sein.

EDIT: Und ja...die Meinung der Programmierer ist in dem Fall dem Management scheiß egal. leider. Klar, Qualitätsoffensive bei Software - wär ich auch dafür. Und welchem Manager machst du das mit welchem Buzzword klar?

Eigentlich wird das "Steckenbleiben" so gering wie möglich kalkuliert, irgendwie muss es ja am Papier gut aussehen, aber man kann große Probleme kaum verhindern. Der Kunde wird nicht verstehen warum er dir 3 Monate mehr geben soll für ein Produkt dass auch noch teurer ist. Fakt ist, man kann _kein_ Programm erstellen das umfangreich, preislich attraktiv, schnell gemacht und auch noch qualitativ hochwertig ist. Irgendwo wird immer gespart - beim letzten Punkt am meisten, weil es jener Punkt ist, der nicht eindeutig am Papier aufscheint.

Und man hofft dass es der Kunde nicht merkt bzw. durch einen "Patch" einfach kompensieren kann.

[Ganon]

Es ist aber auch eines der wichtigsten Dinge die man zu einem Projekt wissen möchte: Wie teuer wird das? Was würdest du ohne einen verlässlichen Kostenvoranschlag in Auftrag geben?

Sicherlich. Aber an was will man die Kosten fest machen? Reine PC-Software-Entwicklung hat ja nunmal nicht viele Material-Kosten, da das meiste ja eh gebraucht wird und anfällt. (Computer, Strom, etc.)

Wenn du die reinen Mitarbeiter-Kosten rechnest, dann kannst du gewiss sein, das du (je länger das Projekt läuft) diese nicht einfach auf den Kunden umleiten kannst. Das wird der nicht bezahlen. ;)

Wege entsprechend um das finanzieren zu können, wären Wartungsverträge, oder andere Support-Tätigkeiten und Erweiterung.

Auch die Rechnerei ob man denn nun an dem Projekt Gewinn oder Verlust gemacht hat, ist auch kaum realistisch. Je nachdem um was es sich handelt, wurden sicherlich Erfahrungen gewonnen und allgemeine Komponenten erstellt, die man dann in späteren Projekten einfach weiterbenutzt/einsetzt und somit die Entwicklungszeit senkt.

Auch spielt das Recht, ob man das Produkt dann weiterverkaufen darf, auch eine Rolle.

Alles das, was mit der >reinen< Entwicklungszeit nicht viel zu tun hat.

Alle genauen Datums-Angaben wann es fertig ist, sind höchstens Ziele. Das diese Ziele meist nicht eingehalten werden können, sieht man ja an den ständigen Verschiebungen von bekannter Software großer Hersteller. Und auch wenn es schon verschoben wurde und dann auf den Markt kommt, heißt das nicht, das es fertig ist. ;)

[Trap]

Und welche Methode funktioniert?
Kann ich nicht sagen, hab zu wenig Erfahrung.

Den Ansatz von COCOMO halte ich prinzipiell für geeignet, es erfasst viele Einflussgrößen die im voraus einigermaßen brauchbar ermittelt werden können und benutzt Daten von vielen vergangenen Projekten. Außerdem ist es mit der eigenen Projektgeschichte kalibrierbar. Ich hab es bis jetzt nur an einem Praktikumsprojekt probiert, da war die Vorhersage ganz brauchbar (im Gegensatz zu meiner eigenen Schätzung, die viel zu niedrig war).

[Trap]

Wenn du die reinen Mitarbeiter-Kosten rechnest, dann kannst du gewiss sein, das du (je länger das Projekt läuft) diese nicht einfach auf den Kunden umleiten kannst. Das wird der nicht bezahlen. ;)
Umso wichtiger im voraus zu wissen wie lang das Projekt dauert. Wenn man nur mit völlig unrealistischen "Plänen" einen Auftrag bekommen kann, weiß man wenigstens was einen erwartet. Der Auftraggeber wird bei allem anderen genauso unsinnige Forderungen stellen, nicht wissen was er eigentlich haben möchte und am Ende eine schlechte Meinung von einem haben.

Es gibt Kunden, die einfach die Mitarbeiterzeit zahlen, guck mal in den extreme programming foren/mailinglisten. Sind aber eher die Ausnahme.

Alle genauen Datums-Angaben wann es fertig ist, sind höchstens Ziele. Das diese Ziele meist nicht eingehalten werden können, sieht man ja an den ständigen Verschiebungen von bekannter Software großer Hersteller.
Diese Termine sind fast immer Wünsche, keine Ergebnisse einer möglichst realistischen Vorhersage. Wenn das realistische Vorhersagen wären, gäbe es auch Projekte die früher fertig sind.

[Demirug]

Kann ich nicht sagen, hab zu wenig Erfahrung.

Den Ansatz von COCOMO halte ich prinzipiell für geeignet, es erfasst viele Einflussgrößen die im voraus einigermaßen brauchbar ermittelt werden können und benutzt Daten von vielen vergangenen Projekten. Außerdem ist es mit der eigenen Projektgeschichte kalibrierbar. Ich hab es bis jetzt nur an einem Praktikumsprojekt probiert, da war die Vorhersage ganz brauchbar (im Gegensatz zu meiner eigenen Schätzung, die viel zu niedrig war).

COCOMO (3GPL) bzw COCOMO II (4GPL) lösen aber im besten Fall nur den zweiten Schritt der Problematik. Die Modele transformieren eine Projektgröße in entsprechende Zeitangabe. Das Problem aus einer Projektbeschreibung/Lastenheft die Projektgröße zu bestimmen kann COCOMO nicht lösen. COCOMO ist daher eher als eine Art Expertensystem zu sehen in das Erfahrungswerte der Projekt Realisierung eingeflossen sind. Dazu gehören auch so einfache Wahrheiten wie das die Entwicklungszeit nicht linear mit der Größe skaliert oder das man den Termin nicht beliebig durch den Einsatz von mehr Entwicklern vorziehen kann. Projektmanager mit wenig Erfahrung kann das aber durchaus helfen. Allerdings weiß er damit immer noch nicht wie groß sein Projekt eigentlich ist.

[Elemental]

Mein Chef hat mal gemeint:
"Multipliziere die Schätzungen der Entwickler mit Pii, dann kommst du evtl. auf halbwegs realistische Werte!" :D

[maximAL]

Mein Chef hat mal gemeint:
"Multipliziere die Schätzungen der Entwickler mit Pii, dann kommst du evtl. auf halbwegs realistische Werte!" :D
meiner bescheidenen erfahrung nach tatsächlich ein guter richtwert...

[RMC]

meiner bescheidenen erfahrung nach tatsächlich ein guter richtwert...

Vielleicht sollten wir das erweitern: Multipliziere die Schätzung der Entwickler unter den unrealistischen Vorgaben des Managements mit Pi...

[tokugawa]

Mein Chef hat mal gemeint:
"Multipliziere die Schätzungen der Entwickler mit Pii, dann kommst du evtl. auf halbwegs realistische Werte!" :D

Seltsam, ich hab meine Schätzung eher dividiert durch PI übertroffen, sprich, ich war in etwa 1/3 der geschätzten Zeit fertig.



Ich glaub erfahrene Softwareingenieure heutzutage wissen dass man lieber hoch ansetzt.

[Demirug]

Ich glaub erfahrene Softwareingenieure heutzutage wissen dass man lieber hoch ansetzt.

…um dann als Held dazustehen weil man schneller fertig war.
Wieder mal eine Lektion aus der Reihe: „Alles was ich im Leben brauche habe ich bei Star Trek gelernt.“
SCNR.

Kritisch wird es nur wenn jeder in der Kette die Zeitangabe hochmultipliziert und am Ende dann so astronomische Zahlen heraus kommen das der Kunde woanders bestehlt oder das Projekt eben gestoppt wird.