Devcathlon brainstorming

There are a number of different approaches that can be taken in the initial designing of Devcathlon that could lock it into specific uses and environments. Finding a balance between usability, flexibility, and consistency is quite the trick.

One big issue I think is the question of Devcathlon's breadth of users. Do we want Devcathlon to be a public website linking developers around the world? This brings of issues of scale, fair comparison of projects, and privacy issues. Or is it a self-contained system that can be set up on a private local network for a school or a company? I think at this point the later makes more sense as the target, but the former would and should be completely possible at release. This makes features such as Hall of Fame a lot easier to manage since such scores will make more sense in a smaller, consistent environment. Even on a larger scale though, scores could be sorted by fields such as number of project/team members, lines of code, and duration of the project. Or perhaps some sort of normalization of points/events per line of code per day.

Another concern is how closely Devcathlon should tie into the Hackystat software metrics tool that is currently planned as the point of entry for much of the data that goes into determining scores. I do not know what other software metrics tools there are out there, but my feeling is that to make Devcathlon friendly to a wide audience of developers we want to make it flexible as possible by keeping it untied for Hackystat. Instead there would need to be methods to hook Devcathlon into diverse systems and use the reporting system of the systems to gather data. Project managers could define the format of data along with the point system for a project.

I'm also concerned about information overload that ends up feeling like spam. Personally I generally really don't want a text message and email from Devcathlon, plus one from Hudson, whenever someone breaks the build. One message is probably sufficient for me. But others will want more. I think users should be able to choose. A project manager can set up Devcathlon with a default way to report events, including options for special text formatting and composition to impart a storyline feel to a message. Ultimately though, users should have their own settings for event reporting tools and frequency.

Basic events should be pretty easy to set up in a project. Minimal non-empirical events such as commits or a broken build can be simply set with a point value and optional reporting mechanisms. Other empirical data such as dev time are only slightly more complicated. But I'd also want it to be possible to make custom events of much higher complexity. Allow multiple data variables and formulas to be combined to reward points. Allow time and date ranges, repeatability limits, number of occurrences, thresholds, milestones, etc. Perhaps you want to set up increasing returns on coverage. Going from 40% to 50% coverage could give the same number of points as going from 85% to 90% as developers eek out those tricker tests on multiple boolean paths and exception handling. These tools would allow advanced project administrators to tailor Devcathlon to their environment and goals.

I like to think that even in a private installation of Devcathlon, all users would be able to create projects. A user's profile management page could have a list of links to projects they are associated with. It could be sorted by activity, creation date, or some other criteria. Each project could also have certain buttons or links associated with them such as "Accept Invite" or if you are a project owner "Manage Project" which is of course where point settings are at (changeable during the project?), team and member management, and other options. You wouldn't even have to be a developer in the project, a likely scenario as a project manager. Both these type of pages are private "management" pages accessible only by certain people. There would be similar "viewing" pages that reflect much of this information but are read only. You might even want to have a private public page such as making the information on a project visible only to people actually involved in the project, but they still wouldn't be able to edit it without owner access. There would also be static public pages with information about the principles of Devcathlon and instructions on use. These could of course be customized for a local installation of the game.

These are just some issues and ideas for Devcathlon, and I'm sure more will come up as we dive into it. I hope to help create a system that is very flexible and accommodating to diverse users, but keeping it simple enough to quickly setup as a novice user. In the mean time, the Devcathlon development team has to keep the code itself from becoming too complicated and inflexible and dooming it to be a violation of our third goal of open source software of allowing an outside developer to modify and extend the source to fit their needs.