Ich hätte zwei technische Fragen zu dem neuen Tabprogramm:
Zu den Algorithmen für die Setzung: Ist das algorithmisch ein relativ triviales Problem, oder ein kniffliges? Falls letzteres der Fall ist: Ist damals, vor zehn Jahren, eine Literaturrecherche dazu gemacht worden und liegen die Ergebnisse heute noch vor, oder gibt es heute nur noch die bestehende Software, vielleicht sogar ohne Doku? Ist geplant bei der Neuimplementierung dieses Thema noch einmal anzuschauen?
Zum Thema Nachkommastellen im Tab:
Es gibt die Möglichkeit den Computer mit echten Brüchen rechnen zu lassen, so daß alle Ergebnisse ohne Rundungsverluste zusammengerechnet werden können. Beispiel für Rundungsfehler: 3 * 0.33 Punkte sind ca. 0.99, aber 2 * 0.5 Punkte sind 1.0 Punkte. Tatsächlich sind jedoch 3 * 1/3 = 2 * 1/2. So kommt es dann z.B. bei Platz 9/10 des Redner-Tabs der letzen DDM zu Punktzahlen von 337.01 gegen 337.00.
Ist dies für die neue Implementierung vorgesehen?
Eine Bemerkung zur Aufwandschätzung: Die Kosten einer kommerziellen Implementierung von 5-10tEuro erscheint mir recht niedrig. Wenn die Anforderungen sind: Es soll auf Windows laufen, ein Teil auf dem Phone (IOS, Android, Windows), es soll einen Server geben, es soll standalone laufen können, benutzerfreundliche Eingaben und Ausgaben haben, nie abstürzen…, dann ist das schon einiges. Neben der Implementierung müßte auch getestet und dokumentiert werden. Auch der Server müßte langfristig gepflegt werden.
Zur Setzung: Keine Ahnung, was das technische und historische angeht. Ich gehe aber davon aus, dass bei einem neuen Programm der Ersteller schon nach intelligenten Lösungen suchen würde. 😉
Zu den Kosten: Ich schätze, das ist ein weiteres Argument, sich nun für das aktuell vorliegende Angebot von 1000€ zu entscheiden, abgesehen vom eben auch sehr konkreten Bedarf.
bevor ich hier meine 2ct zum Thema neues Tabprogramm dazugebe möchte ich klarstellen, daß es mir nicht darum geht, den Antrag “abzusägen”. Auch wenn ich nicht den Anspruch eines Programmiergotts für mich erhebe, habe ich doch einige Erfahrung mit dem Programmieren von Software gesammelt und möchte auf mögliche Fallen hinweisen, in die man tappen könnte.
Meiner Erfahrung nach hat Software i.A. ein laaaanges Leben, länger als man bei Erstellung denkt. Die zehn bis fünfzehn Jahre, die das alte Tabprogramm auf dem Buckel hat sind nicht die Ausnahme, sondern die Regel. Das hat verschiedene Gründe, u.a. ein natürlicher “lock in” Effekt der daher rührt, daß ein Wechsel Einarbeitungszeit für viele Beteiligte bedeutet und fehlende Erfahrungswerte (lieber eine Software mit vielen Bugs die ich kenne, als eine mit weniger Bugs, die ich nicht kenne).
Daher ist ein komplettes Neuschreiben auf der grünen Wiese, wenn wir es tun, eine selten auftretende Chance, die wir deshalb so gut nutzen sollten, wie’s nur geht. Denn sehr wahrscheinlich werden die Pflöcke, die wir jetzt in den Boden rammen, noch in zehn bis fünfzehn Jahren stehen, wenn die meisten von uns ihre aktive Zeit längst hinter sich gelassen haben. Wenn also die zukünftigen Debattiergenerationen einen Grund weniger zum Fluchen haben, wäre das doch ein schöner Erfolg. Ganz zu schweigen von reibungslos ablaufenden Turnieren und pünktlich beginnenden Socials.
Um die Chancen zu maximieren hilft ein guter Plan vor der ersten Codezeile inklusive realistischer Aufwandschätzung. Auch wenn der Plan in der Praxis nicht komplett eingehalten wird (kein Plan wird das), lohnt es sich hier zu investieren, so daß wir eine möglichst genaue Vorstellung davon haben, was wir wollen, warum und wie teuer das wird (teuer nicht nur in Geld).
Folgende Fragen könnte man vorab klären. Geht es hier im wesentlichen “nur” um eine Neuimplementierung der bestehenden bewährten Konzepte und Algorithmen in einer moderneren Softwareumgebung? Oder müssen auch diese Konzepte eventuell noch eimal auf den Prüfstand, z.B. weil sich die Welt weitergedreht hat, es heute bessere Algorithmen für die Setzung gibt oder die alten in einer Form entstanden sind, die man heute nicht mehr nachvollziehen kann? Es könnte eine Liste von Features mit Priorisierung geben (z.B. unverzichtbar, wichtig, angenehm, Luxus). Eine Skizze der softwaretechnischen Struktur könnte auch helfen. Vielleicht läßt sich die Software in unabhängige Module zerlegen, die übersichtlicher und leichter zu warten sind, als ein monolithischer Block? Solle die durchzuführende Aufwandschätzung erschreckend hoch ausfallen, könnte man das Projekt in mehere Phasen zerlegen, dabei jedoch immer das Gesamtergebnis im Blick behalten.
Ohne eine sorgfältige Planung sehe ich die Gefahr, daß zwar etwas besseres herauskommt als der Status Quo, aber möglicherweise etwas schlechterers, als erreichbar wäre. Und damit müßten wir dann alle die nächsten zehn Jahre leben.
Zum Abschluß vielleicht noch einen Vorschlag für ein Feature, das vielleicht nicht die höchste Priorität hätte, aber vielleicht ganz nett wäre. Es betrifft die Setzung der Teams in Fällen, in denen keine Setzung alle Kriterien vollständig erfüllt. Dann muß die Chefjury wohl zwischen verschiedenen Übeln wählen. Hier wäre es vielleicht hilfreich, wenn die Chefjury die sog. Pareto-Oberfläche (https://de.wikipedia.org/wiki/Pareto-Optimum) interaktiv z.B. mit Schiebereglern “ablaufen” könnte. Z.B. mit den farblich hervorgehobenen kritischen Stellen in der Setzung.
Eine sehr gute Idee! Vielen, vielen Dank!
Das ist ernsthaft genial. Bitte etabliert das als Rubrik für die kommenden Jahre vor der MV!
Ich hätte zwei technische Fragen zu dem neuen Tabprogramm:
Zu den Algorithmen für die Setzung: Ist das algorithmisch ein relativ triviales Problem, oder ein kniffliges? Falls letzteres der Fall ist: Ist damals, vor zehn Jahren, eine Literaturrecherche dazu gemacht worden und liegen die Ergebnisse heute noch vor, oder gibt es heute nur noch die bestehende Software, vielleicht sogar ohne Doku? Ist geplant bei der Neuimplementierung dieses Thema noch einmal anzuschauen?
Zum Thema Nachkommastellen im Tab:
Es gibt die Möglichkeit den Computer mit echten Brüchen rechnen zu lassen, so daß alle Ergebnisse ohne Rundungsverluste zusammengerechnet werden können. Beispiel für Rundungsfehler: 3 * 0.33 Punkte sind ca. 0.99, aber 2 * 0.5 Punkte sind 1.0 Punkte. Tatsächlich sind jedoch 3 * 1/3 = 2 * 1/2. So kommt es dann z.B. bei Platz 9/10 des Redner-Tabs der letzen DDM zu Punktzahlen von 337.01 gegen 337.00.
Ist dies für die neue Implementierung vorgesehen?
Eine Bemerkung zur Aufwandschätzung: Die Kosten einer kommerziellen Implementierung von 5-10tEuro erscheint mir recht niedrig. Wenn die Anforderungen sind: Es soll auf Windows laufen, ein Teil auf dem Phone (IOS, Android, Windows), es soll einen Server geben, es soll standalone laufen können, benutzerfreundliche Eingaben und Ausgaben haben, nie abstürzen…, dann ist das schon einiges. Neben der Implementierung müßte auch getestet und dokumentiert werden. Auch der Server müßte langfristig gepflegt werden.
Hallo Martin.
Zur Setzung: Keine Ahnung, was das technische und historische angeht. Ich gehe aber davon aus, dass bei einem neuen Programm der Ersteller schon nach intelligenten Lösungen suchen würde. 😉
Zu den Kosten: Ich schätze, das ist ein weiteres Argument, sich nun für das aktuell vorliegende Angebot von 1000€ zu entscheiden, abgesehen vom eben auch sehr konkreten Bedarf.
Hallo,
bevor ich hier meine 2ct zum Thema neues Tabprogramm dazugebe möchte ich klarstellen, daß es mir nicht darum geht, den Antrag “abzusägen”. Auch wenn ich nicht den Anspruch eines Programmiergotts für mich erhebe, habe ich doch einige Erfahrung mit dem Programmieren von Software gesammelt und möchte auf mögliche Fallen hinweisen, in die man tappen könnte.
Meiner Erfahrung nach hat Software i.A. ein laaaanges Leben, länger als man bei Erstellung denkt. Die zehn bis fünfzehn Jahre, die das alte Tabprogramm auf dem Buckel hat sind nicht die Ausnahme, sondern die Regel. Das hat verschiedene Gründe, u.a. ein natürlicher “lock in” Effekt der daher rührt, daß ein Wechsel Einarbeitungszeit für viele Beteiligte bedeutet und fehlende Erfahrungswerte (lieber eine Software mit vielen Bugs die ich kenne, als eine mit weniger Bugs, die ich nicht kenne).
Daher ist ein komplettes Neuschreiben auf der grünen Wiese, wenn wir es tun, eine selten auftretende Chance, die wir deshalb so gut nutzen sollten, wie’s nur geht. Denn sehr wahrscheinlich werden die Pflöcke, die wir jetzt in den Boden rammen, noch in zehn bis fünfzehn Jahren stehen, wenn die meisten von uns ihre aktive Zeit längst hinter sich gelassen haben. Wenn also die zukünftigen Debattiergenerationen einen Grund weniger zum Fluchen haben, wäre das doch ein schöner Erfolg. Ganz zu schweigen von reibungslos ablaufenden Turnieren und pünktlich beginnenden Socials.
Um die Chancen zu maximieren hilft ein guter Plan vor der ersten Codezeile inklusive realistischer Aufwandschätzung. Auch wenn der Plan in der Praxis nicht komplett eingehalten wird (kein Plan wird das), lohnt es sich hier zu investieren, so daß wir eine möglichst genaue Vorstellung davon haben, was wir wollen, warum und wie teuer das wird (teuer nicht nur in Geld).
Folgende Fragen könnte man vorab klären. Geht es hier im wesentlichen “nur” um eine Neuimplementierung der bestehenden bewährten Konzepte und Algorithmen in einer moderneren Softwareumgebung? Oder müssen auch diese Konzepte eventuell noch eimal auf den Prüfstand, z.B. weil sich die Welt weitergedreht hat, es heute bessere Algorithmen für die Setzung gibt oder die alten in einer Form entstanden sind, die man heute nicht mehr nachvollziehen kann? Es könnte eine Liste von Features mit Priorisierung geben (z.B. unverzichtbar, wichtig, angenehm, Luxus). Eine Skizze der softwaretechnischen Struktur könnte auch helfen. Vielleicht läßt sich die Software in unabhängige Module zerlegen, die übersichtlicher und leichter zu warten sind, als ein monolithischer Block? Solle die durchzuführende Aufwandschätzung erschreckend hoch ausfallen, könnte man das Projekt in mehere Phasen zerlegen, dabei jedoch immer das Gesamtergebnis im Blick behalten.
Ohne eine sorgfältige Planung sehe ich die Gefahr, daß zwar etwas besseres herauskommt als der Status Quo, aber möglicherweise etwas schlechterers, als erreichbar wäre. Und damit müßten wir dann alle die nächsten zehn Jahre leben.
Zum Abschluß vielleicht noch einen Vorschlag für ein Feature, das vielleicht nicht die höchste Priorität hätte, aber vielleicht ganz nett wäre. Es betrifft die Setzung der Teams in Fällen, in denen keine Setzung alle Kriterien vollständig erfüllt. Dann muß die Chefjury wohl zwischen verschiedenen Übeln wählen. Hier wäre es vielleicht hilfreich, wenn die Chefjury die sog. Pareto-Oberfläche (https://de.wikipedia.org/wiki/Pareto-Optimum) interaktiv z.B. mit Schiebereglern “ablaufen” könnte. Z.B. mit den farblich hervorgehobenen kritischen Stellen in der Setzung.
Für die sorgfältige Planung!