The goal of the game is to deliver software according to client needs and timelines, advance in the ranks and land the ultimate position as Chief Architect at Giggle Industries. Your day-to-day job involves interpreting requirements from the product managers and executing items from the backlog. You solve small puzzles over a time-frame, perhaps attend a few meetings to gain greater insight into the work, write documentation and generally manage your time. Care must be taken to not spend too much time doing one thing while neglecting others, as a well balanced work-load leads to greater productivity and success!
Behind the scenes there is a company state. This represents the course of events over time. Examples of state variables:
There is an ideal pattern of state variable changes that will maximise profit, but this is not known to the player. By implementing features these variables can be changed. The goal is to implement the right features at the right time so that these variables are changed to track the ideal pattern as best as possible. However the player does not know directly what the ideal feature pattern is, and they also do not know the exact effect each feature has on the variables. Futhermore the pattern changing over time may make some features obsolete - the effect the feature has on the variables is no longer desirable to track the ideal pattern.
The primary way a developer can manipulate the variables is by implementing features that have a positive or negative effect. It is not known in advance the effect of a given feature, but more information can be gained by communication and meetings.
Each programming task has requirements. These are represented as the output of a multi-variable truth table. In addition to this there is a hidden "ideal" truth table that has the real effect on game variables. With infinite time a developer can discover the real truth table (via communication and meetings with good company synergy) however there is a time pressure on all tasks preventing a perfect implementation. If company synergy is not good then communication takes longer to discover the true requirements. If the task is executed in it's imperfect form the amount of code required will be higher (due to a more complex truth table) and the effect on the business will not be as positive, or perhaps negative.
One the real requirements are known the code can be refactored, however this must be either planned via the backlog or done as a "black-ops" project outside the backlog (ie: time is consumed but backlog items are not completed).
There are several interfaces that the player can use to get information about the game and influence the course of events:
Enables implmentation or modification of features.
Work appears on the backlog from product managers. Items can be "pushed" to other teams for execution if there is enough "synergy".
Here an (imperfect) view of the company metrics can be seen over time. Good developers use this to track their features.
Communication can be done via email. This is one way to discover the true nature of requirements. However beware of over communication resulting in requirements becoming more complex. Some employees hold a strong opinion that might be wrong! If you ask their opinion and you don't implement their version of the truth synergy can decrease (sometimes it's better not to ask).
When there is a virtual user interaction with the product that interaction comes with a set of properties. For example user_language. The model maps each possible value for that property to a bit-pattern. If the running code correctly maps the user input to the bit-pattern that input is said to be correctly handled. A partial score is awarded if the bit-pattern matches partially. Each property is given a weight in how much it contributes to the final score of that user interaction. So if the code handles high scoring properties correctly it will contribute more to the interaction score than low scoring properties. The interaction score across all properties is then used to calculate if the interaction results in a conversion (revenue).
Thus the goal of the developer is to obtain the highest possible score for each user interaction in order to earn more revenue and retain the user. The developer does this by deploying as many high quality handling routines as possible. This could be by deploying highly quality code to handle the most important properties, by deploying sub-standard handlers for a broader range of properties, or by looking at the distribution of users and optimising for the most frequent user interaction types. Ideally all three, but there are resource constraints that prevent that from being possible.
The product managers provide an incomplete or inaccurate specification of the bit-patterns for each property. The quality of the product managers specification can improve if there is more SYNERGY in the company, although there is always a discrepancy between the perfect bit-pattern handler and the specification.
Furthermore, while the relative weights of the property score doesn't change, the ratio of users that have a specific value for a property can change over time. This is a way to simulate for example a new market opening up. If that new market was previously low volume then probably there is no quality handling code for the specific values coming from users in that market and thus the score has not been optimised. When that market opens up there are now a lot more user interactions with those specific values for properties and it changes where the developer should focus quality handling code. Provided the developer knows that this has happened or course!
The game maintains an ordered list for all properties with the ideal bit-pattern handlers for each. The order is determined by the impact implementing a perfect handler for that property will have on revenue with the current distribution or users. As market conditions (user distributions) change this list is updated and the order changes. This represents the "perfect" backlog from which a perfect product manager would pick backlog items. Implementing all the items in this list perfectly represents the ideal product - in this case regardless of market forces every property is handled perfectly and maximises revenue regardless.
The in-game product managers pick items from this list, but do so imperfectly. This means not picking items from the top of the list and randomly changing the bit-patterns for items that are picked. This simulates the mis-identification of which properties are the most important, and the imperfect understanding of the requirements. Poor product managers also do not update the backlog when market conditions change and the order of the ideal backlog changes.
In this model user properties map to features. Implementing a bit-pattern to handle a property is adding a feature to the product. Consider user_language as a property of the user interaction. The feature is analogous to handling languages, and the perfect implementation of the bit-pattern would mean that the product is fully multi-language. The bits would represent the language code and if a handler correctly matched the bit-pattern for all language codes the product would have the feature of being multi-lingual. However it would be simpler to match just a few language codes initially, and if most of your users are from one language code then perhaps a handler that correctly matches just that one language code is enough for a while.
The developer needs to know what bit-patterns to implement for particular properties.
The backlog serves as a communication medium. However only the product manager has input into the backlog and thus only the quality of the product manager determines if the specification bit-patterns are accurate.
Scattered throughout the company are individuals that have perfect understanding of the bit-patterns for a particular property. These are the "domain experts" and through communication their secret knowledge can be extracted. The smaller the company the less domain experts there are so the less likely that a given property has a domain expert. However domain experts also can give you incorrect information about other properties and the larger the company the more likely you will get incorrect information from them. In small companies their job titles are more specific giving the developer more information on what their domain expertise is. As the company grows their job titles become more obscure making it harder to determine if you are getting information on their domain. When the developer communicates with another employee via email they will receive randomly information about a particular property. If the property seems related to their job title it is likely they are a domain expert in that property. This means as the company grows it becomes more likely the developer will not be able to tell the difference between incorrect and correct knowledge about a particular property.
Developers can choose to meet employees in person. When this happens and the employee is a domain expert, the correct bit-pattern is only conditional on the SYNERGY in the company. If the SYNERGY in the company is high and the employee is not the domain expert for the property it is likely the developer will get a "I don't know" answer. However if SYNERGY is low there is a higher change of either a domain expert or a non-domain expert delivering the bit-pattern for another property.
A meeting is when many employees gather together and are asked for bit-patterns for a specific property. Meetings work like face-to-face meetings, except the quality score of the meeting introduces more opportunity for getting the wrong answer. If the meeting is high-quality there is a higher chance that there will be only one answer given from the domain expert (if present). If the meeting is low-quality there is a higher chance that each person in the meeting will give a bit-pattern and it will be impossible to know which one is the correct one. If the meeting is high-quality and the domain expert is not present there could be no answer given. The more people in a meeting the lower the quality. The more SYNERGY in the company the higher the quality. To maximise the change of receiving a single and correct bit-pattern from a meeting the developer has to try to invite the domain expert, keep the number of people in the meeting low and be in a company with high SYNERGY.
This is a company score variable that changes over time and is dependent on many factors. It influences almost all things within the company. Things that effect SYNERGY are:
It is very hard for the developer to directly affect SYNERGY.