IStealYourGun schreef op maandag 20 december 2010 @ 23:32:
[...]
Uit de
about kan je afleiden dat ze gebruik maken van de Agile structuur. K'heb het zelf moeten opzoeken, wat ik er uit versta is dat het neerkomt dat de software word aangepast aan de node van de klant doorheen het ontwikkel proces. De bedoeling er achter is een zeer gebruiksvriendelijk programma met weinig documentatie omdat alles zichzelf uitwijst. Klinkt in elk geval prachtig in theorie, maar in de praktijk lijkt het me een nachtmerrie.
Mja, agile op zich is niet verkeerd, maar ook bij agile heb je vaak een overkoepelend plan. Wat agile anders maakt van andere ontwikkelprocessen is dat je regelmatig releases doet en je dus beter aan kunt passen aan de wensen van de klant en de veranderende situaties.
Echter, wat ook een belangrijk onderdeel van agile is, is dat je programma bij elke release werkt. Dus bij elke release zit er ook een dikke bakkes tests achter, waardoor dingen als blaadjes die ineens niet meer decayen niet voor horen te komen.
Een ander programma, een stuk groter / complexer dan Minecraft, doet dit wel goed - Google Chrome. Die hebben een bakkes code, maar ook een bakkes aan testcode die elk stuk van het programma test, een bakkes websites die gerenderd worden, een lading performancetests, enzovoorts. Daardoor kom je nagenoeg geen bugs tegen tijdens normaal gebruik, en gaat bestaande functionaliteit niet stuk na een update, omdat voor elke functionaliteit een test bestaat. Mislukt de test, dan geen release.
En weinig documentatie / dat alles zichzelf uitwijst... als dat in de code zit: dat is fout. Self-documenting code is zowel zeer moeilijk te schrijven als onmogelijk zodra je programma meer dan twee bestanden heeft, omdat je dan het overzicht verliest - ja, ook als je alles zelf geschreven heeft.
Hij lijkt iig een fatsoenlijke bugtracker te missen.
idd, maar hij heeft wel een online todo lijstje waar mensen op kunnen stemmen

.
quote: camacha
Meh. Ik heb laatst een prachtig onderzoek gelezen waaruit bleek dat klanten juist minder tevreden zijn bij grote betrokkenheid in het ontwerpproces, gek genoeg.
Nu je het zegt, dat viel me ook op bij Minecraft, en daardoor zijn de commentaren op zijn blog waarschijnlijk uitgezet. Bij een post over een nieuwe update kreeg hij gewoon bakken vol opmerkingen over dat het langzaam ging, dat er bugs in zaten, en nog meer van dat soort kritiek. Toen zei ik ook al, hij moet niet zo dicht bij het publiek zitten, dan gaan ze hem persoonlijk aanvallen op van alles.
quote: RedHornet
Het ruikt ieg naar een hele bekende werkwijze: "We hebben geen werkwijze en daar hebben we ook geen zin in, dus we noemen ons gerotzooi maar Agile/SCRUM want daar lijkt het op als je met één oog er naar kijkt en aan dansende roze eenhoorns denkt."
Dat heet ook wel
Cowboy Coding,

.
quote: mux
OK, laat ik het anders zeggen: ik heb nog geen enkel ander 'groot' programmeerproject gezien waar zó veel features met relatief zó weinig bugs worden gereleased.
Dat komt waarschijnlijk omdat er maar weinig projecten zijn met regelmatige releases en wijzigingen die direct van invloed zijn op de gebruiker (dwz dingen die je direct merkt). Veel updates van programmatuur bevatten features waar je als gebruiker maar weinig van merkt, of bugs die je in de praktijk niet of nauwelijks tegenkomt. Bij Minecraft kom je zowel features als bugs redelijk vlot tegen.
quote: mux
als je met elke update weer nieuwe bugs introduceert is dat lastig, maar in tegenstelling tot elk ander programmeerproject weet je dat je even naar getsatisfaction, twitter of de forums kunt gaan en kunt posten dat die bug er is. Letterlijk een kwartier later komt dan een bugfix uit.
Nouja... De tree leaf decay bug heeft er anders wel... twee maand? in gezeten voordat het eindelijk gefixed werd. Dus dat gaat niet altijd op. Teveel bugs blijven te lang zitten, vind ik. Maar ja, daar heb je het 'alpha / beta' excuus voor.
quote: Rainlife
De meeste bedrijven waar ik mee gewerkt heb en die "Agile" gingen zijn daar weer vanaf gestopt omdat de developpers op het einde van het traject zelf zeiden: "wat een bagger hebben wij hier nu gemaakt ?"
Mja, bagger maken is onafhankelijk van werkwijze,

. Als je per iteratie genoeg tijd neemt om alles op te poetsen - dus een deel van je tijd besteden aan refactoring, documentatie en testen - lijkt me dat je toch wel een heel mooi product neer kunt zetten. Discipline is het kernwoord hierin.
quote: dutch_warrior
Kijk alleen al naar veel moderne games, zelfs voor consoles hoeft het blijkbaar niet meer in 1 keer goed.
hoeft wel, maar helaas gebeurt het niet,

. De codebases van die spellen zijn ook een *tig factor groter dan die van Minecraft, evenals de developmentteams. En daar hebben ze 'dedicated' testers bij, zelfs. Maar ook die vinden lang niet alles. Nee, een bugvrije AAA-titel is tegenwoordig niet of nauwelijks meer mogelijk, tenzij je, zoals bij Minecraft en spellen van Blizzard, eerst maandenlang een (semi)-publieke beta laat doen. Alleen bij officiële titels is beta ook echt beta, en niet slechts een excuuslabel voor bugs.
Dat het vroeger beter leek te zijn komt misschien door de mogelijkheid tot updaten, maar dat was er ook lange tijd al voor de PC (waar ook gebruik van gemaakt werd), en dat waren spellen die qua code en content nagenoeg in het niet vallen bij de titels van tegenwoordig.