[Conf] Software best practices: the Magic Gig?

Talk given by Kevin Kreitman on Friday, February 19. [My comments in brackets]

Only companies get CMMI, not people. [Interestingly, products don't get CMMI either. People get the "senior" or "lead" mention to distinguish them from the "junior" newbie, but that does not mean they are more skilled.]

Kreitman's conjecture: you can not control process and outcome at the same time. That is to say, the more you control the process, the more open you have to be about the outcome. [Open source projects are interesting examples to check this conjecture. Open source projects seem to be, a priori, controlled by no one in particular: the community decides which features should be implemented. But looking closer, it becomes obvious that committing into /trunk should only be allowed to experimented and familiar developers: novice or random developers unfamiliar with the project must not commit whatever lines they found interesting to add. So the control here actually prevents the project to collapse, narrowing the outcome. Does the conjecture apply to open source projects?]

A process solves a particular problem in a particular context thanks to particular resources. Hence a process that works somewhere may not work for your company. Imposing a process does not work. While in the middle of a project, do not change radically the process that has been followed for months. Instead, it can sometimes be useful to try, during 1h per week for instance, a new particular "process concept". For instance, a project was stuck because no one knew who to talk to or where to go. This visibility problem was solved when it was decided to try a "total transparency" hour every Friday morning. All possible information was available, and everyone could know which bugs had been detected when, which had been solved when, what were the next project deadlines, what were the current budget and resources, etc. [Game companies usually follow agile development processes with very short iteration cycles, so that the game can be tested, debugged and its mechanics adjusted as soon as possible. I wonder how efficient short breaks could be when applied to the kind of agile process followed in traditional game companies. Moreover, I feel like publishers, willing to control costs, may require more expensive projects to follow a kind of spiral life-cycle. Could a "spiral-break" be interesting/useful in game development agile processes?]

The iPhone IDE is an easy-to-use tool which lets the developer see what his/her app looks like quickly. The IDE contains many API and bundles, and it is really hard not to use it to develop an iPhone app. The reason is the Apple designers do not want their nicely designed product to be spoiled by poorly designed third-party apps, and Apple also wants to make money through the appstore. So they force the app developer to use their API to ensure third-party apps stay relatively user-friendly. At the same time, this API forcing also means the iPhone may contain functionalities that are not visible to third-party app developers. [Someone added "yeah it's kinda the same with Xbox Live Arcade"] [Giving a limited API to third-party developers sounds like developing add-ons for MMOG. Giving enough while not giving too much can get really tricky. The less you provide, the duller the UGC, but the more you provide, the easier for hacking or exploiting.]