Here is a clip:
The idea is simple: submitted talks and papers must be related to projects which failed in an interesting way. The larger the better, of course — the bigger they are, the harder they fail — but anything that failed in an interesting way would be a valid subject for discussion.FAILcon is a fantastic idea to prevent developers and researchers from hitting walls harder than kids jumping on exercise balls. However, since I do like the concept, it deserves a second, more critical look.
I think that FAILcon falls a bit short in its objective. Here's why:
- The software industry is too large. There are too many projects in too many fields, and even then, it is rapidly expanding. People working on sensor networks may not visit a conference full of game development failures. Sure, failure is universal, but that doesn't mean that it is universally applicable.
- Aside from the enormous resources that would have to be corralled, a conference emphasis isn't the right approach. Failure conferences already exist, and I assume that you envision more than a "lets feel better about ourselves" pow-wow. I'm not sure that a single failure conference (even if it is annually) will a) create enough papers to be a lasting resource, or b) cover diverse enough subject matter for the concept to really be useful.
- Forget the conference-centric approach. Instead, focus on an online journal. This a) builds a foundation from which a future conference can be created, and b) doesn't have some of the limiting factors of a conference (listed above). Make the failure resources the primary goal and keep the conference as a secondary goal.
- About the online journal: It would need to be peer-reviewed, as someone mentioned in the original blog-entry. Make it an "open application" process. Don't limit papers to a certain time of year, or month. Especially when laying the groundwork for a new resource, we need to encourage participation as much as possible. An annual conference isn't the best way to do that. Finally, tag each article so it can easily be referenced by people in the applicable field - game developers can find articles on game development or network administrators can find networking articles.
Base a conference off a journal, not a journal off a conference.
Posts
1 comment:
(Failcamp co-creator here...)
If you assume that the purpose of Failcamp is to prevent people from making identical technical mistakes, well then, you're mistaken.
It's also not a "feel-good about ourselves pow-wow."
Failure is omnipresent. It's the default state of everything. There are no techniques you can use to avoid failure in general and technical failure stories are not going to necessarily be applicable even in the same situation.
What can be learned is how to deal with the aftermath, and learning to take value directly out of the failure. And that's universally applicable.
And there's absolutely no difference between specific technical failure and general life failure in this view.
If you want to create a peer-reviewed journal, by all means do so. But I think if you'll look at the history of peer-reviewed journals you'll see the flaw in your idea. The idea that you'll get industry people to bother to write long essays about problems only to wait for them to be *reviewed* by their "peers"... well, I have to say, I think it will fail.
To get people to own up to their own problems you need a convivial atmosphere. A non-permanent, non-serious one.
Post a Comment