Introduction
I have a set of CRAZY ideas that I’ve been mulling for a while now. These crazy ideas are based on the observation that there are elements of the “professional programmer” experience that are not represented in the CodinGame of today. I will attempt to briefly explain the missing element, why I think it’s important, and my recommendation for how to incorporate it.
Disclaimer: These ideas really are out there, so I’m not necessarily expecting any action based on this. Just trying to stir the creative juices a bit.
Concept
The first lacking element that I want to address is collaboration, and I want to specifically hone in on collaboration around creation and integration of software components. This includes architecture, role / responsibility discussions, API definitions, etc.
In any moderately sized software undertaking, you need to decide what components will be present in the architecture, what those components will do, how components will be integrated, and who will implement what. In CG, all contests and puzzles are monolithic / black box. The inputs and outputs are pre-defined.
Proposal
I propose a contest that is of sufficient complexity that it would strongly encourage collaboration. I know, this would be difficult to design, but I think the payoff would be worth it.
Here is how I envision this. The contest would still have a fixed set of inputs and outputs. However, each user would register to code one of N (3-4 ??) tiers of the solution. At first, the inputs and outputs of each tier of the solution would be pre-defined, and there would be a default implementation of each tier so that a user could test out their code in a complete solution.
At this point, the user can submit their code to what I am calling a “staging ground” where it will do battle against others’ submissions for the same tier. All rankings in the staging ground are based on being paired with default components for the other tiers.
I next imagine that combatants can recruit from the staging grounds to form ad-hoc teams. Once teams are formed, they would have the flexibility to rework the inter-tier APIs to their hearts’ content. Do they want to use JSON or XML instead of the plain text approach? That’s fine. They could even come up with some kind of API negotiation scheme so that their components could talk well to each other, but could fall back to the default API if they want to switch up the teams.
Once a team is formed, they can agree to collectively submit their N-tier code into the arena where the various team-based solutions do battle.
I know that there are many logistical questions around implementation of such a beast. It’s half-baked at best. Thoughts?
- danBhentschel