Concepts The main goal of Problems and Programmers is to teach. In developing the game, we identified the important lessons of software engineering, using sources including 201 Concepts of Software Development by Alan M. Davis and an excellent list compiled by Emily Navarro for SimSE. The game was then designed with these concepts in mind, such that each was represented by a card or mechanic in the game. Some examples of software engineering concepts and how the game represents them include: Failing to dedicate an appropriate amount of time to documentation early in the project will lead to problems later on. - Early in the game, players choose how many turns they wish to dedicate to creating requirements and design documents. The more time that is spent, the less vulnerable they will be to problem cards played by their opponents during their implementation of the project. If coding is rushed, the project will often take longer. - Players can allow their programmers to play code cards as "rush" code at reduced time cost. However rush code has a nearly doubled chance of having bugs, and the bugs tend to be more difficult to fix. And of course, fixing bugs takes time. The sooner bugs are found, the less negative impact they will have on the project. - There are three bug types in the game. Simple bugs can be removed fairly easily and represent minor coding errors or typos. Fixing normal bugs requires time relative to the number of code cards completed after the affected code card. Finally, fixing nasty bugs requires changes so drastic that the code completed after the affected card must be discarded and recoded altogether. Code inspections will reduce cycle time by allowing for the early detection of bugs. - Code cards are played face-down. In order for players to determine if a given section of code has a bug, they must take time to "inspect" it and flip it over. Frequent inspections will allow bugs to be found and fixed early, and will lessen the impact of normal and nasty bugs. Skilled programmers may still cause problems if they are irresponsible or do not follow proper software engineering practices. - Programmers have a personality attribute that makes their controller vulnerable to problems. Programmers with low personalities will sometimes quit, write confusing code or forget to update documentation. Adding more programmers to a late project often makes it later. - Each programmer creates his own area of code cards that he or she has created. The more programmers that a player employs, the more areas he will have, and the longer the project will take to integrate at the end of the implementation. And many more... Further information about the concepts the game teaches can be found in the papers we wrote for ICSE 2003 and CSEET 2003, which can be found here.