Ja, die armen Entwickler, die immer nur die Peitsche spüren...
Ich habe in meiner Arbeit viel mit Entwicklern zu tun, teilweise sind das aber auch selbstgeschaffene Leiden. Fehler, die korrigiert werden und dann im nächsten Release plötzlich wieder auftauchen oder es wird links gedreht und rechts geht plötzlich was nicht mehr, usw. kenne ich zu genüge. Und dass hat nicht immer was mit mangelnder Zeit zu tun, sondern mit mangelnder Code-Qualität. Nicht jeder Entwickler ist gut oder hält sich an Standards. Und divenhaftes Verhalten kenne ich ebenfalls bei dem einen oder anderen Entwickler.
naja, kann halt nur aus eigener erfahrung berichten... habe für etliche firmen im bereich entwicklung gearbeitet: geschraubt, gefeilt, skizziert, am rechner gesessen, konstruiert, getestet, gecodet, flussdiagramme auf bierdeckel gekritzelt, versucht einen vernünftigen workflow und sinnvolle interaktion der verschiedenen abteilungen zu managen, die kummerkastentante für die verkaufsabteilungen gemacht, getroubleshootet bis zum finalen erbrechen, memos verfaßt, abteilungsleiter und chefs getröstet (und nicht etwa vertröstet)... z.z. unterwegs bei einem zulieferer für die automobilindustrie: mit den entwicklern kann man noch halbwegs reden, aber wehe du hast einen vom ein- oder verkauf (sowohl extern als auch intern) am telefon. aua. die bringen dir das gesamte konzept (also die grundidee für das projekt!) durcheinander. du nennst notgedrungen eine neue deadline, und dann wirste aber rund gemacht. klar, schwarze schafe gibt's überall, auch bei den vertretern meiner sorte... aber die entwicklung der letzten jahre ist gaga: die abteilungen driften auseinander und prioritäten wie qualität, funktionalität, nutzerfreundlichkeit und nachhaltigkeit werden mit füßen getreten (hausintern). nur worthülsen. und die pr-abteilung redet nach außen hin alles schön (und die steckt die kohle ein). ist halt verdammt schade, daß man nicht mehr zusammen arbeitet, sondern gegeneinander. und das hat in den letzten jahren extrem zugenommen: wenn's gilt einen artikel zu einer bestimmten deadline auf den auf den markt zu schmeißen gibt es genau zwei optionen: versprechen wir zig funktionalitäten welche wir nicht gewährleisten können oder verzichten wir auf großspurige ankündigungen und liefern mit ta-dah!-effekt sinnvolle funktionalitäten nach? letzteres ist ohne großen aufwand möglich, falls das konzept in sich stimmig ist. ersteres allerdings ist heutzutage standard: machen wir erst mal die leute heiß, verkaufen nichtexistente produkte (pre-order-geschäftsmodell) - ja genau, nichtexistent! sonst hätten wir das produkt als "wird gerade in china zusammengekloppt, keine ahnung ob's funktioniert so wie in der werbung versprochen" ... und sahnen die kohle erst mal ab (weil wir haben uns eh' übernommen und hantieren die gaaanze zeit mit roten zahlen)... und häppchenweise liefern wir dann grundfunktionalitäten nach. das sind im prinzip spekulationsgeschäfte.
ich hoffe es es ist nachvollziehbar daß diese ausführung mehr als erklärungsansatz für die leute zu verstehen ist, die sich wundern warum dies und das an diesem oder jenem funkelnagelneuen gerät nicht funktioniert: die teile sind einfach noch nicht fertig. ist halt so: falls genug einheiten vorverkauft werden haben wir endlich die kohle für's beta-testen. und falls die entwickler es nicht binnen eines überstunden-wochenendes nicht hinbiegen... ja dann holen wir uns einfach nen praktikanten. so läuft das.
klar hol ich mir irgendwann die rd8/-9 ins haus. ich hab zwar ne nava hier rumstehen, aber habe die hoffnung,daß der B-sequencer an 'nen punkt gelangen wird, an dem die bedienung spaß macht und alles fluffig ist und funktioniert. dann hätte ich nämlich zwei drummies, bei denen ich nicht großartig umdenken muß. das wäre ein kaufargument gewesen. aber ich mach doch für keinen hersteller den beta-tester: der job sollte nämlich hausintern und verdammt gut bezahlt sein. amen.