Vraag & Antwoord

Trashcan

[september 2005] Voorwoord

Anoniem
None
14 antwoorden
  • [b:b1f0082f54]Wanted: geld voor bugs![/b:b1f0082f54]
  • Ik zie dat velen er niet zo mee eens zijn.Ik eigenlijk ook niet maar zou het wel ook zo willen zien, maar ben wel bewust van dat het niet kan of zeer moeilijk te verwezenlijken is.

    Bug loos software is heel moeilijk te realiseren.Ik denk dat het meer 'n middeweg van Bug arm vs ontwikkeltijd is. Ten eerste vereist intensief bug testen 'n Q&A team zo groot als de gebruikers groep zelf. En veel tijd, tijd die De deadline wel 30 100% kan verschuiven. Dit valt ook in te plannen met een strakke deadline maar komt dan neer op veel inhakken op de feature list Je past het design aan de deadline aan.

    Zo ook veel games hebben last van bug's. Maar Ik vind dat Q&A op zijn minst de Critical bug's voor 100% eruit halen en daarvoor zijn nu eenmaal veel of voldoende tijd en resources voor nodig en de daarop volgende grotere bugs voor 99% eruit halen. Blijven er nog altijd minor bugs over die later gepatch kunnen gaan worden wil je dit ook 99% hebben dan zit je met Development project cycle verdubbeling. Hoe complexer het project en Design hoe langer.

    Als je kijkt naar de top game titels die met 'n redelijk onbepaalde devtime van "it's done when its done" dus grof 4 á 5 jaar. Die hebben er nogal wat tijd in gestoken om het bugvrij en qualty te maken en ook het budged ervoor.
    Andere houses met rond de 2 jaar met strakke deadline en beperkte budged, moeten ergens op in korten. Vaak is het niet de feature list maar wel de standaard Q&A wordt verminderd. Resultaat erg buggy game. En de can op major bug's.

    Je can als consument dat wel eisen en de software huizen kunnen daarin tegemoet komen maar dat houd in 2 á 3 jaar latere oplevering en dubbele prijs. Afhankelijk van design complexiteit. En Q&A resources.

    Daarnaast is het probleem ook van de zeer grote verscheidenheid aan configuraties van mogelijke Hardware, OS, driver en aplicatie samenstellingen die in het wild voorkomen dit is nagenoeg niet te testen.

    Bug loos kan met zeer kleine projecten voor beperkte combinaties van hardware. Consoles hebben dus al 1 van de 2 voorwaarden voor bugloos streven. Mac zit er tussen in.
  • Het is niet 'moeilijk' om te verwezenlijken.
    Het is een kwestie van de juiste mentaliteit hebben vanaf het begin van het ontwerp.
    90% van fouten ontstaan door gebrekkige definitie van problemen.

    Dacht je dat je in de echte industrie je het kunt veroorloven om een fout te laten zitten ?
    Als de productie van een Nedcar of Shell werd stil gelegd door fouten dan hebben de makers van de onderdelen een rechtzaak of boete binnen zelfs al weten ze het goed op te lossen.

    Complex ? Hoe complex is de besturingssoftware van een F-16 of Spaceshuttle ? Daar is het gemiddelde spel niks tegen.

    Te veel varianten ?
    Dat valt in de praktijk echt mee. Er zijn maar 2 producenten van grafische kaarten die eningszins meetellen. Voor geluid is het nog makkelijker : Creative is de enige. AMD of Intel heeft al eeuwen geen verschil gemaakt.

    Bedenk ook dat er meer en meer gebruik wordt gemaakt van 'middleware' (zoals de Unreal-engine). Een hele hoop compatibiliteits-problemen is dan al bij voorbaat opgelost en de ontwikkelaars kunnen zich met het spel zelf bemoeien.

    Helaas zijn consumenten zo braaf dat ze de vele patches en bugs zonder mekkeren accepteren (och ff de nieuwste drivers installeren en hoppa).
    Grootste probleem is echter dat het je onmogelijk wordt gemaakt om te protesteren en je geld terug te eisen.
    Al eens geprobeerd een niet-werkend spel te ruilen ?
    Je mag blij zijn als je binnen 24 uur mag ruilen, maar dan alleen met een ongeopende verpakking …

    En tegenwoordig hebben de producenten nog een extra bron van problemen toegevoegd : kopieer-'beveiliging'.
    Dat is de eerste horde waar (te veel) spellen op hun bek gaan.
    Ook hier weer maken winkeliers het onmogelijk om te protesteren.
    Geen wonder dat velen dan maar op zoek gaan naar de zogenaamde 'no-cd'-cracks om de software toch maar aan de gang te krijgen. Dat ze daarbij dan vaak ook op de 'gratis' versies stuiten schijnt de industrie niet te kunnen schelen.

    Geen wonder dus dat de industrie niks blijft doen.
    Zelfs bij de grootste blunders hebben zij hun geld al binnen, terwijl de consument met de ellende blijft zitten. Eventueel verlies wordt dan op de illegale versies van hun software afgeschoven.

    Het wordt dus idd eens tijd dat we de producenten op het matje kunnen roepen als ze weer eens bugs in het spel laten zitten.
    Het wordt tijd dat de producenten een spel schrappen ipv het alsnog met bugs op de markt te gooien.
    Helaas zal dat pas gebeuren als we ze kunnen raken waar het ze pijn doet …
    Was er maar een recht op garantie zoals dat bij echte producten het geval is.
    Nu durven de meeste producenten zich te beperken tot 30-90 dagen.
    En dat terwijl zelfs het meest simpele koffiezetapparaat een garantie van 1 jaar heeft (en wettelijk zelfs nog meer).

    Misschien eens tijd om de overheden te vragen wat de garantie-periode (en dus het recht op gratis reparatie) voor software mag zijn ?
    Voeg daarbij een boete-clausule voor software waarbij binnen X dagen meer dan 1 patch noodzakelijk is … en we hebben een kans.
  • [quote:6f5e0f5463="JaFO"]Complex ? Hoe complex is de besturingssoftware van een F-16 of Spaceshuttle ? Daar is het gemiddelde spel niks tegen.[/quote:6f5e0f5463]Kwestie van geld, de ontwikkeling van dit soort "producten" kost miljarden (en bij de spaceshuttle praten we eerder over biljarden) en is er dus gewoon meer mankracht. Gewone software heeft dat budget helemaal niet natuurlijk…

    Wat me verder een beetje tegenstaat aan het artikel is dat het overkomt alsof de programmamakers blij zijn als er een bug in hun software zit, dat is natuurlijk onzin. Zij balen er nog veel harder van dan wij, zij moeten ook de bug repareren en dat kost ze echt klauwen met geld…

    Als we toegaan naar een markt waarin je geld terug gaat krijgen bij bugs zal dat leiden tot één resultaat: er wordt niks vernieuwds meer ontwikkeld.
  • Alsof het achteraf maken van een patch om problemen op te lossen geen geld kost …
    Ik durf te wedden dat een groot deel van de bugs voorkomen had kunnen worden als men iets minder op de specifieke releasedatum en iets meer op de kwaliteit had gelet. Zeker bij software die op de releasedatum een patch heeft zou het duidelijk mogen zijn dat men te vroeg is gestopt met het testen.

    [quote:49c68bddff]
    Als we toegaan naar een markt waarin je geld terug gaat krijgen bij bugs zal dat leiden tot één resultaat: er wordt niks vernieuwds meer ontwikkeld.
    [/quote:49c68bddff]
    Men durft *nu* al niks vernieuwends te ontwikkelen.
    Niet vanwege eventuele boetes, maar omdat een standaard-vervolg op een nog-niet uitgemolken serie nog altijd minder werk & risico is dan iets origineels.
    Het zou dus nauwelijks een verandering zijn tov de huidige manier van werken.
  • [quote:c1f43c0a12="JaFO"]Alsof het achteraf maken van een patch om problemen op te lossen geen geld kost …[/quote:c1f43c0a12]Zoals ik zei: dat kost juist handen vol geld, daar worden ze echt niet vrolijk van. Een bug ontdekken in de ontwerpfase en in de "productie" fase schelt qua geld een factor 10000. Lijkt me niet dat er ook maar één zinnig bedrijf is die dit bewust doet…
    [quote:c1f43c0a12="JaFO"]Ik durf te wedden dat een groot deel van de bugs voorkomen had kunnen worden als men iets minder op de specifieke releasedatum en iets meer op de kwaliteit had gelet.[/quote:c1f43c0a12]Tja, dan kom je in het bekende Halflife2 senario en we weten allemaal wat dat heeft opgeleverd ;)
    [quote:c1f43c0a12="JaFO"]Zeker bij software die op de releasedatum een patch heeft zou het duidelijk mogen zijn dat men te vroeg is gestopt met het testen.[/quote:c1f43c0a12]Zou kunnen, maar vergeet niet dat tussen de release voor het publiek en de release richting de fabriek (om de cd's te maken) minstens een maand zit. In die tijd kan er natuurlijk mooi getest worden.

    Wat ik me overigens vandaag nog over zat te verbazen: hoe durft de Computer!Totaal dit soort taal over software developers uit te slaan terwijl ze zelf niet eens 50 pagina's zonder typefouten kunnen produceren? Of zijn dat bugs in de spellingscontrole? ;)
  • [quote:7912f9ee51="Bill Gates"]Wat ik me overigens vandaag nog over zat te verbazen: hoe durft de Computer!Totaal dit soort taal over software developers uit te slaan terwijl ze zelf niet eens 50 pagina's zonder typefouten kunnen produceren? Of zijn dat bugs in de spellingscontrole? ;)[/quote:7912f9ee51]

    Terechte opmerking. Toch vind ik dat er een fundamenteel verschil is tussen een magazine, waarvan iedereen weet dat het onder een maandelijks terugkerende deadline en vaak nog in de laatste minuten nieuw nieuws moet produceren, en een softwarepakket dat je eenmalig in een keurige doos in de winkel koopt. Ik persoonlijk vind een spelfout, hoe slordig ook, van een heel andere orde dan een fout die bijvoorbeeld mijn veiligheid en privacy bedreigt - zeker als ik voor dat laatste honderd of zelfs honderden euro's heb betaald.
    Bovendien is mijn punt niet dat er geen fouten gemaakt mogen worden (software-ontwikkelaars zijn ook mensen ;) ), maar wel dat het voorkomen en oplossen van fouten minder prioriteit lijkt te hebben dan het ontwikkelen van fancy nieuwe features en het halen van zakelijke deadlines. Die laatste prioriteiten worden niet ingegeven worden door het verlangen de klant zo goed mogelijk te bedienen, maar om hem zo veel mogelijk te verkopen.

    Natuurlijk is geen bedrijf bewust bezig bugs in de software achter te laten. Waar ze wel bewust mee bezig zijn is producten op een bepaalde datum lanceren, omdat de aandeelhouders dat willen - of het nu af is of niet. Er zijn wel ontwikkelaars geweest die, als we vroegen naar een lanceringsdatum, simpelweg zeiden: "It's done when it's done". Dat waren vaak opvallend goede producten, die de studio's pas verlieten als de ontwikkelaars er helemaal tevreden over waren. Maar meestal is het heel simpel: de aandeelhouder wil het product op die-en-die datum kunnen presenteren, en heeft dat ook al overal rond getrompetterd, en uitstel is dus geen optie. En dat terwijl de deadline voor gebruikers meestal volstrekt irrelevant is - er is geen enkele reden om pakket X per se in januari te willen hebben, dus als het dan maart wordt is dat ook geen probleem - als dat dan maar betekent dat het ook echt af is! Dat heb ik liever dan het in januari kopen, en vervolgens tot in september patches moeten downloaden omdat er in de haast aan alle kanten fouten in zijn geslopen.

    Ik begrijp heel goed dat geen project kan werken zonder deadlines en dat het voortdurend verzetten van deadlines niet automatisch resulteert in een beter product. Maar ik vind wel dat de eerste prioriteit van een producent moet zijn dat zijn product zo af en bugloos mogelijk op de markt verschijnt. Bij HalfLife2 zijn ze eindeloos blijven doorontwikkelen - dat leidt eerder tot meer dan tot minder fouten. Op een gegeven moment moet de ontwikkeling stoppen en alle aandacht uitgaan naar het opsporen en oplossen van bugs. En als je er dan achter komt dat er op de deadline nog steeds fouten in zitten: stel maar uit.
    Het is af als het af is.
  • Ik heb een opmerking over het artikel: de opmerking over firefox is totaal ongegrond. Firefox valt niet onder de categorie producten die een deadline moeten halen, juist niet. Je wordt uitgenodigd om als betatester mee te doen, en dan zal je er maar akkoord mee moeten gaan dat er nog bugs inzitten. Zeggen dat het fout is om geld te geven voor bugs ("die had je zelf moeten vinden!") is hier dan ook onzin; je krijgt een 'sneak preview' van een product dat nog niet af is.

    @volkert deen: Waarom mag een blad met een deadline wel veel fouten bevatten, en software niet? Voor beiden geldt 'dat het vroeger beter was' - een C!T van 10 jaar geleden staat echt niet onder de spelfouten, ookal was er toen ook al een deadline.
    Kijk voor de grap eens op pagina 14, stuk over het OLED-tobo. "Prototypesworden" (mist een spatie)
    "rond 300dollar" ("rond DE 300 dollar" of "ongeveer 300 dollar")

    dit zijn IMO redelijk storende taal- en typefouten, in een stukje van nog geen kwart A4-tje…

    En hoezo deadline bij windows? Hoe vaak is longhorn ondertussen wel niet uitgesteld? Of is het gewoon allebei een kwestie van personeel dat niet goed genoeg is? (beheersing van de Nederlandse taal/inzicht in beveiligingsrisico's)

    nog even over autoveiligheid: deze veiligheid is er gekomen omdat de consument het eist, niet omdat er wetten voor zijn.
  • [quote:f22543bfdc="Volkert Deen"]Terechte opmerking. Toch vind ik dat er een fundamenteel verschil is tussen een magazine, waarvan iedereen weet dat het onder een maandelijks terugkerende deadline en vaak nog in de laatste minuten nieuw nieuws moet produceren, en een softwarepakket dat je eenmalig in een keurige doos in de winkel koopt. Ik persoonlijk vind een spelfout, hoe slordig ook, van een heel andere orde dan een fout die bijvoorbeeld mijn veiligheid en privacy bedreigt - zeker als ik voor dat laatste honderd of zelfs honderden euro's heb betaald.[/quote:f22543bfdc]Ik zie geen verschil: beiden een deadline, beiden kosten de koper geld.

    [quote:f22543bfdc="Volkert Deen"]Die laatste prioriteiten worden niet ingegeven worden door het verlangen de klant zo goed mogelijk te bedienen, maar om hem zo veel mogelijk te verkopen.[/quote:f22543bfdc]Dat is toch logisch? De Computer!Totaal staat toch ook niet vol oud nieuws omdat de kwaliteidscontrole niet gemaakt kon worden binnen de deadline? Nee: gewoon plaatsen dat nieuws (en dat is prima natuurlijk) en er genoegen mee nemen dat er dan wel eens fouten in kunnen staan. Software is percies hetzelfde, je probeert allerlei nieuwe features te maken, anders verkoop je natuurlijk geen nieuwe versie (jullie zouden toch ook niet iedere maand hetzelfde blad uitbrengen tot er geen fouten meer instaan?)…

    [quote:f22543bfdc="Volkert Deen"]Natuurlijk is geen bedrijf bewust bezig bugs in de software achter te laten. Waar ze wel bewust mee bezig zijn is producten op een bepaalde datum lanceren, omdat de aandeelhouders dat willen - of het nu af is of niet. Er zijn wel ontwikkelaars geweest die, als we vroegen naar een lanceringsdatum, simpelweg zeiden: "It's done when it's done". Dat waren vaak opvallend goede producten, die de studio's pas verlieten als de ontwikkelaars er helemaal tevreden over waren.[/quote:f22543bfdc]Dat is natuurlijk de ideale situatie, maar er zijn maar zeer, zeer weinig bedrijven overgebleven die zich zo'n houding hebben permiteren. Je kan zeuren op bijvoorbeeld Microsoft wat je wilt, maar ze bestaan nog steeds.

    [quote:f22543bfdc="Volkert Deen"]En dat terwijl de deadline voor gebruikers meestal volstrekt irrelevant is - er is geen enkele reden om pakket X per se in januari te willen hebben, dus als het dan maart wordt is dat ook geen probleem - als dat dan maar betekent dat het ook echt af is![/quote:f22543bfdc]Ik heb ook liever de Computer!Totaal twee weken later zonder fouten…

    [quote:f22543bfdc="Volkert Deen"]Ik begrijp heel goed dat geen project kan werken zonder deadlines en dat het voortdurend verzetten van deadlines niet automatisch resulteert in een beter product. Maar ik vind wel dat de eerste prioriteit van een producent moet zijn dat zijn product zo af en bugloos mogelijk op de markt verschijnt. Bij HalfLife2 zijn ze eindeloos blijven doorontwikkelen - dat leidt eerder tot meer dan tot minder fouten. Op een gegeven moment moet de ontwikkeling stoppen en alle aandacht uitgaan naar het opsporen en oplossen van bugs. En als je er dan achter komt dat er op de deadline nog steeds fouten in zitten: stel maar uit.
    Het is af als het af is.[/quote:f22543bfdc]Toevalligerwijs (of niet natuurlijk ;)) ben ik software-ontwikkelaar en die houding van "het-is-af-wanneer-het-af-is" had ik "vroeger" ook. En het werkt gewoon niet. Het kan namelijk _altijd_ beter, maar wat win je mee? Klanten in ieder geval niet, die weten niet waar ze aan toe zijn. Geld dus ook niet. En tenslotte kost die houding je gewoon je baan. Gelukkig heb ik op tijd het licht gezien ;)
  • Toch: Zijn er maar weinig auto's die ontworpen zijn op een frontale aanrijding met een voetganger, hebben auto's in lagere klasse pas sinds kort stalen balken in de portieren, leven mensen die langs een snelweg leven 1,8 jaar korter door ontbrekende roetfilters op al die coole 8) diesels, jagen rechtsaffende vrachtwagens met enige regelmaat rechtdoorgaande koters de dood in, zijn regelmatig terugroepacties, kan de auto er tegenwoordig ook al mee kappen omdat er een [i:c0b8ce940c]computer[/i:c0b8ce940c] :cool: in zit, wordt de produktie verplaatst naar twijfelachtige landen met idem beloningsstructuur teneinde het gegeven winst te continueren, stijgt de brandstofprijs dagelijks en betaal ik me scheel bij de dealer. etc.. Maar dat terzijde…

    PS Naar aanleiding van Voorwoord nr. 6/2005(niet opgenomen in dit gebeuren): wellicht is het u ontgaan maar een begrippenlijst had C!T voorheen zelf online staan.
  • [quote:6f77a3e9af="webspider"]Ik heb een opmerking over het artikel: de opmerking over firefox is totaal ongegrond. Firefox valt niet onder de categorie producten die een deadline moeten halen, juist niet. Je wordt uitgenodigd om als betatester mee te doen, en dan zal je er maar akkoord mee moeten gaan dat er nog bugs inzitten. ….[/quote:6f77a3e9af]
    Dan heb jij een andere firefox dan ik.
    De mijne werd niet gepresenteerd als een 'product dat nog getest moet worden', maar als iets dat 'af' was.
    Het idee achter die 'beloning' voor bugs bij Firefox is dat men zo overtuigd is/was van hun kwaliteit dat ze (voornamelijk als publiciteitsstunt tov IE) durfden te wedden dat er niet of nauwelijks bugs zouden worden gevonden door de eindgebruikers.

    [quote:6f77a3e9af]
    nog even over autoveiligheid: deze veiligheid is er gekomen omdat de consument het eist, niet omdat er wetten voor zijn.
    [/quote:6f77a3e9af]
    en daarom zal software met gemak vol met bugs blijven zitten :
    de consument heeft het (helaas) geaccepteerd dat ze megabytes aan patches moeten downloaden om hun spullen werkend te krijgen.

    En deels 'moet' je het accepteren omdat ruilen & garantie in de software-branch niet bestaan. Alleen bij maatwerksoftware zijn sommige klanten zo 'slim' om boete-clausules in de overeenkomst op te nemen …

    Zoals al werd opgemerkt bevatten moderne auto's ook software en vele complexe systemen. Desondanks komt het vrij weinig voor dat de consument zelf de eventuele problemen oplost. Of heb je al eens de laatste firmware voor je boordcomputer geinstalleerd ?
    Bij pc's gebeurt dit wel … ik blijf het een vreemde/kwalijke zaak vinden.
  • Even voor de duidelijkheid ik heb liever ook dat software robust en stabiel out off the box het doet. Geen BugFix patches nodig.
    Dat sommigen er een zooitje van maken vind ik ook erg maar bugloos is wishfull thinking. Ze kunnen hun beleid aan passen om bug fiasco's te mijden. Dat is zekers mogelijk maar bugloos nee. Theoretish mogelijk maar praktisch niet.
    D'r zijn 4 factoren die maar zelden goed samen gaan en nogal zwaar afhankelijk van mekaar.
    1 Tijd
    2 Geld
    3 expertise
    4 omvang complexiteit.

    Als die al zo belangrijk zijn en de bugvrij wish flink tegenwerken hoef je al niet meer dieper op de details in te gaan.

    4 is bepalend 'n klein projectje kost weinig is beter te overzien makkelijker te plannen en in ene kleiner tijd spanne realiszeerbaar.

    En als er toch iets mis gaat. planning in de soep. Dan moeten er keuzes worden gemaakt hoe verder?
    Zoals Q&A beleid, het project scrappen of meer $ ertegen aan en het uitstellen maar wel op niveau uitbrengen, wel later maar met veel minder bug's en af. Of de fiasco way. Dus het toch maar strak aan de deadline en ook budged houden en een bijna af produckt loslaten.

    Maar Bugs komen er in de duizenden van zwaar critical tot heel veel minor bugs als alpha stage bereikt wordt.
    Het is dus van het
    Critical bug vrij maken dit is enigzins binnen huidig industie structuur te doen. Bij medium projecten. Er is nogal stabiel gereleased software te verkrijgen met minor bugjes in laag aantal.
    Bug's aanzienlijk verminderen kan ook door meer ov voldoende budged en tijd naar Q&A overhevelen en als er een strakke deadline is meer secundaire features schrappen. Ja het is het een of het andere. Het komt eigenlijk neer op Hoe goed de Software designer kan plannen en de feel wat haalbaar is binnen 'n strakke project cycle en dit goed naar de $ source communiceerd. Aangezien er gewoon voldoende tijd gereserveerd moet zijn voor Q&A en dit dus ook ingeplanned moet worden.
    [quote:1c7b4ece8e="JaFO"]
    en daarom zal software met gemak vol met bugs blijven zitten :
    de consument heeft het (helaas) geaccepteerd dat ze megabytes aan patches moeten downloaden om hun spullen werkend te krijgen.
    [/quote:1c7b4ece8e]
    Sommige projecten zijn complex en moeten in het open met heel veel anders software interacten API drivers firmware of afhankelijke software en dat is moeilijk allemaal grondig te testen in projecttijd en dus nagenoeg praktisch onmogelijk. Ook zijn ze te afhankelijk van derden. En er komt elke maand van bepaalde merken ook weer nieuwe mogelijk heden uit zoals nieuwere hardware en apps. die ook weer bug's kunnen genereren in jouw app.
    [quote:1c7b4ece8e]

    En deels 'moet' je het accepteren omdat ruilen & garantie in de software-branch niet bestaan. Alleen bij maatwerksoftware zijn sommige klanten zo 'slim' om boete-clausules in de overeenkomst op te nemen …

    Zoals al werd opgemerkt bevatten moderne auto's ook software en vele complexe systemen.
    [/quote:1c7b4ece8e]
    Weer van die manke vergelijkingen. Ten eerste slaat auto en software ontwikkeling op totaal onzin.
    Auto is overwegend mechaniek en ja daar is ook Q&A maar dan op een heel andere niveau dat nog redelijk is te overzien. Vooral als dat je vak gebied is. dan is zo'n Otto motor princiepe niet complex ziet er wel zo uit voor 'n leek.

    Software voor motor managment is ook niet echt vergelijk baar. Je hebt 'n embedded systeempje dat net zo ristricted is in hardware keuze maar ook lite OS dat het niet te vergelijken is met software dat op verschillende systemen moet draaien met heel veel verschillende software hardware.
    [quote:1c7b4ece8e]

    Desondanks komt het vrij weinig voor dat de consument zelf de eventuele problemen oplost. Of heb je al eens de laatste firmware voor je boordcomputer geinstalleerd ?
    Bij pc's gebeurt dit wel … ik blijf het een vreemde/kwalijke zaak vinden.[/quote:1c7b4ece8e]


    Nou ten eerste is voor zo'n board komputer een erg kale OS'je nodig en maar één app en is het vere van complex eerder 'n eenvoudig embedded system. Heeft meer weg van een erg kaal compact consoletje maar met één simple game module op vast gesoldeerd. De meet en regel game of motormanagement software. 'N embedded systeempje, embedded OS en embedded app. Kan dus goed puur op elkaar afgestemd worden en als het even kan ook nog puur in asembler gezien de beperkte omvang van zo'n software project.

    Als je dat nou eens vergelijk met de MS longhorn project.

    1 tijd: 5 jaar op wachten of 10 of 15 á 20 ja dan zul je minder bug's hebben hooguit wat minor bugjes.
    2 geld: voor die 5 tot 20 jaar en zware Q&A is onevenredig méér geld voor nodig. Bug vrij vergeet het maar. Dit geld voor elke zwaar overal van afhankelijk groot project.
    3 expertise: nou dat hebben ze wel maar toveren kunnen ze niet :)

    4 omvang: embeded AutoSoftware vs een largescale software enginering.

    compact hardware software fix embeded project vs een zeer complex project wat moet inter acten met heel veel ander software drivers en firm ware en ook aankomende.

    'n Game is nog steeds 'n heel stuk complexer dan dat softwaretje van 'n autotje maar minder dan 'n MS OS. 'n game is ook zwaar afhankelijk van de software van derden zoals verschillende drivers maar vooral weer die complexe OS met zijn feature rich API en dan drivers van vooral nieuwe hardware.

    Dat van dat autotje valt gewoon onder meet en regel techniek.

    Daarnaast Patches hoeven niet alleen voor bugfixen te zijn. Patches kunnen ook Features toevoegen maar ook nieuwe bug's.

    En bugvrij in een groot software project ben je dus vaker afhankelijk van software van anderen binnen het project maar ook extern maar ook van hardware vendors. Door code reuse.

    Zoals die DLL hel.
  • Die boordcomputer mag dan 'simpel' zijn, maar een enkel foutje kost zo gigantisch veel prestige & centen dat men gedwongen is om alles zelf uit te sluiten en te testen.

    Om de beruchte quote van General motors maar weer eens aan te halen : als auto's ontwikkeld waren zoals software dan waren ze goedkoper maar gingen ze om de haverklap stuk …

    Zo verschrikkelijk complex is een gemiddeld spel/software nu ook weer niet.
    Je ziet dat er meer en meer gebruik wordt gemaakt van bestaande oplossingen en steeds kleinere modificaties.

    De hardware ligt tegenwoordig (dankzij sponsoring & monopolies) zo goed als vast (en DirectX schakelt de rest gelijk).
    Voeg daarbij de 'certified' drivers en je zou je niet eens zorgen hoeven te maken over bugs op het gebied van drivers.

    De auto-industrie heeft iig bewezen dat zolang de industrie op een gevoelige plaats geraakt kan worden (ie : in de winst/inkomsten) er een manier wordt gevonden om het op te lossen.

    Ik blijf er bij dat het gemak waarmee de consument de fouten accepteert er de oorzaak van is dat de industrie meer fouten laat zitten.
    Het is net alsof sinds het internet verspreiding van patches makkelijker heeft gemaakt dat het aantal fouten en patches is toegenomen.

    Het enige dat ik zie gebeuren is dat de industrie het zich steeds makkelijker maakt om achteraf problemen op te lossen (door al die geautomatiseerde patch-toestanden zoals Steam etc.) ipv het echte probleem bij het begin op te pakken.

    100% bugvrij is misschien onmogelijk, maar het is niet onmogelijk om hogere eisen te hanteren en die ook te leveren. Er zijn genoeg industrie-takken over waarin dat dagelijks bewezen wordt.
  • [quote:270245b8c3="JaFO"]Ik blijf er bij dat het gemak waarmee de consument de fouten accepteert er de oorzaak van is dat de industrie meer fouten laat zitten.[/quote:270245b8c3]
    De vraag is dan simpel: is het eigenlijk wel een probleem?

Beantwoord deze vraag

Dit is een gearchiveerde pagina. Antwoorden is niet meer mogelijk.