On the domain of all people seeking to get involved with projects and all people seeking talent for projects, there exists what I prefer to describe as the Projects Problem. This problem can be seen as a variation of the Stable Marriage Problem or Assignment Problem. The Projects Problem is specific to effectively matchmaking among idea people and feasible developers for resource-limited organizations such as small school organizations.
Preliminary Definitions
In order to understand the projects problem, we must first describe the context in which it occurs. The people involved in this problem are of two distinct sets:
- Idea People
- People that propose an idea or have an explicit problem/project that they require help with
- Developers
- People that seek involvement in a project
A match is thus a pair: an idea person that has agreed to work with a developer. The set of matches is thus all feasible combinations of idea people and developers.
The problem of simply matching people may seem trivial. Consider a naive solution: if an idea person exists and a developer is free, then match them. Although this is intuitive (Eager Matching, see Matching Strategies), this does not guarantee satisfactory results.
We say that results are satisfactory if we can optimally maximize both the idea person and developer’s satisfaction with the matching. Thus, we produce an optimization problem:
\[
\max{\sum_{i=0}^{matches} satisfaction(i)}
\]
We must then define criteria for satisfaction. In the context of ICS projects, we say that an idea person is satisfied with the matching if their developer has the skills necessary to solve their problem; additionally, we say that a developer is satisfied with the matching if they have been sufficiently compensated for their work (whether intellectually or monetary).
The Projects Problem
The problem now can be easily defined: given a set of idea people and a set of developers, match people such that both parties are satisfied with the matching. As the Projects Coordinator for the Association of Computing Machinery (ACM) at UC Irvine, it is my duty to maximize the satisfactory matchmaking among idea people and developers. However, this problem is difficult to solve. Here is why:
First, idea people are also resource-constrained and seek to maximize developer talent while minimizing the cost. Second, developers seek to maximize their compensation while minimizing work. These two sets of people are playing a zero-sum game against one another (this can be modeled through a Minimax algorithm on a game tree). Certainly, one could argue that if we reduce this problem’s constraints, it becomes a simple maximization where both parties mutually benefit; however, in reality, there is always a cost whether it is monetary, time or other commitment.
An Example with Integers
To illustrate this problem, consider the following integer example:
Consider idea person A seeking a developer talent with minimum-bound skill requirement 5 i.e. A will not accept developers below the integer requirement. A is willing to offer a compensation of up to 2.
Then consider a pool of feasible developers (X, 2, 3), (Y, 1, 1), (Z, 6, 8). The tuple is a representation of (Candidate, Skill, Compensation). Thus, X has a skill of 2 and will only work for a compensation of 3.
It is obvious that X and Y are not feasible candidates. Additionally, A may attempt to coerce Z; however, it is unlikely that Z will work for such low compensation.
Therefore, there are no feasible matches in this scenario. Because no matches are made, productivity is stagnant (and non-existent) while both sets continue to grow.
Feasible Solutions: Matching Strategies
There are a few standard strategies that are frequently employed among small organizations. Each of these strategies may have variations; however, these are the standard approaches that I have observed as feasible solutions to this problem depending on the objective of the organization.
Eager Matching (Naive)
Matches are attempted among all feasible combinations of idea people and developers once they are available. Satisfaction was never considered (or was never guaranteed).
Benefit
Rapidly reduces the pool of idea people and developers in wait.
Cost
Low satisfaction rate.
Lazy Matching
Matches are only made once satisfaction is guaranteed by both parties. Beware that this approach may sometimes appear elitist if only absolutely satisfactory matches are made.
Benefit
High satisfaction rate.
Cost
Large pool of idea people and developers in wait.
Role-Based Matching
Developers (or other types of team members) are distributed into more subcategories (much like a Pigeonhole principle). Idea people then request for an individual of a specified subcategory. Team members are assigned accordingly by a third party (former VGDC process).
Benefit
Structured matching process.
Cost
Requires that members understand the process as well as the requirements which entail a category/title. If the structure maintains no requirements for each category, then the strategy is reduced to eager matching (with unnecessary structure).
Mentorship Strategy
Idea people have a specific problem which has an inheritance property such that new developers of arbitrary skill requirements may improve and later inherit the duties of idea people.
Benefit
Long-term investment of idea people and developers
Cost
Specific to projects that can afford long-term investments; additionally, risk is involved such that new developers are lost after long-term investment.
Discussion of ACM’s Lazy Strategy
ACM’s current strategy is lazy matching. Although incompatible matches frequently disappear (due to wait), there is significant involvement as well as progress for the few projects established through ACM.
Benefit
Consider the ACM website which, under a five-day time constraint, was well-made. Additionally, consider ICPC practice sessions, which, with only a quarter of practice, enabled a first-year student to achieve first place in a local competition against undergraduates of all levels i.e. third- and fourth-years.
Cost
Now, we consider the cost of such achievements through lazy matches. First, ACM has a significantly small board as well as a small, general member base. Second, ACM must shoulder its own financial weight, for we do not appeal with a breadth of talent as other clubs may. As a consequence, we sacrifice aggressive marketing tactics and corporate event opportunities.
General Strategy Discussion
Although I may continue to discuss the strategic positions of other organizations such as VGDC and ICSSC, they are sensitive topics of debate that I will not discuss without approval.
Instead, I will generalize that with every strategy, advantages are weighed by sacrifices (once optimal utility has been achieved). Thus, ACM sacrifices a large audience in favor of a handful of capable individuals.
We intend for ACM’s culture to be established by its few members, for each member has a duty to algorithms, theory and intellectual discussion.
Further Discussion
Certainly, there was much left out such as other criteria for satisfaction, the concept of wait, skill requirements, effective Pigeonholing, strategic implications and the simple concept of time.
If you’re interested such a topic, find me in the Irvine wild and perhaps we may have a chat.
