Executive Summary (for those tired of reading my ramblings)
This post is simply to gauge interest in an api developing "contest." The contest goal is to design an api that is easy to use and able to meet future requirements changes without breaking backwards compatibility. The contest meta-goal is to discover information that can be used to create a document containing guidelines for building and using shared components. The contest borrows very heavily from a similar activity done in the Java community--APIFest. The main difference is whereas APIFest is an exercise designed to improve developer skills, this contest is designed to discover information.
Motivation
In the discussion about dependency hell (here) I have attempted to highlight important dependecy conflict issues anyone developing or using shared components needs to consider. As far as I know there are no quick, comprehensive solutions to the general problem. Dependency management and conflict resolution appears to be one of the few areas of computer science that hasn't come under extensive academic scrutiny.
Although NI may implement features in future Labview versions that help developers resolve dependency conflicts, given the complexity of the problem I believe it is reasonable to expect any such features are several years away. Neither the current practice of only allowing a single component version to be installed nor the opposite practice of allowing all component versions to be loaded simultaneously is wholly acceptable. They both have scenarios that leave the end user with conflicts that are difficult or impossible to resolve.
I believe the best we can do right now is develop a set of guidelines. The guidelines would identify the design and deployment options available to the component developer, various scenarios a component user might find themself in, and types of changes made to the component. It would go on to describe the compatibility level of each developer option, user scenario, and component change combination. (i.e. Does the code defined in the scenario still work after the component has been updated with an arbitrary change?) It would also explain what the component user would have to do to fix the broken code or identify it as an unresolvable situation. I believe a document like this would be invaluable to the Labview community. It would help component builders understand how their decisions will impact component users, and it will help component users select components that are built and deployed in a way that accomodates their needs.
Unfortunately, the knowledge contained in the proposed guidelines document does not exist. Furthermore, the matrix of developer options, user scenarios, and potential changes is much too big for me and my little brain to compile on my own. That's where the contest comes in. It works like this...
Contest Concept
The participants would consist of a number of component developers and a few judges. I envision it extending through a series of ~4-6 rounds. At the start of each round the judges will provide a set of requirements for the api. The first round will start with initial requirements. In subsequent rounds the new requirements will be in addition to existing requirements. Component developers (that's you) will define an api and implement the requirements using technologies of your choice. You can use LVOOP, action engines, globals, or whatever else you can dream up. The component will be required to maintain some state information; it's not just a function library.
When the developers are finished implementing the requirements for a round, the judges and other developers will have a period of time to "attack" an api and create test cases with valid user scenarios illustrating flaws in the component that either, a) show the component does not behave consistently with the stated requirements, or b) show the component has broken backwards compatibility. When the attack period concludes the round is over. Scoring is based on the total number of flaws discovered over the life of the component.
To summarize, component developers have 3 goals:
- Do not break backwards compatibility.
- Make the component api as simple as possible.
- Make the component api as extendable as possible.
Component attackers have 1 goal:
- Create test cases showing how a component failed a valid user scenario, by returning output inconsistent with previous versions, by causing a compile error (broken run arrow,) or by failing to satisfy the stated requirements.
Judges have several goals, including but not limited to:
- Create valid api extension requirements that stretch the api. (Make no mistake... we're trying to mess up your design.)
- Be impartial and objective in rulings regarding flaws.
- ...
Purpose
The goals of the contest participants are listed above, but the purpose of the contest is entirely different. The purpose is to discover what works well and what doesn't work well with the intent to share that information with the community. <*Cue inspirational music*> To do that we have to push boundaries and use components in ways the original developer did not expect. We need to explore the limits of current practices and push, ever forward, into the darkness. We need to seek out new implementations and boldly go where no Labview developer has gone before. </cheezy speech>
I'm willing to run point on this, but in order for it to be worthwhile there'd need to be at least 8 component developers, 2-3 judges, and perhaps an extended pool of attackers. I expect each round would be 1-2 weeks long. If this sounds like something you'd be willing and able to participate in any of the above capacities, please let me know by posting below. If there is enough interest I'll kick off the contest in another discussion thread.
-Dave
