Koch Lab:Publications/Drafts/Versatile Feedback/Software/Version 2 Roadmap and Manual

Some initial thoughts:

Eric S. Raymond: The Cathedral and the Bazaar

By: Richard C. Yeh (rcy3cornelleduProject Admin) - 2008-03-04 02:41

While considering the feasibility of turning our Optical Tweezers Control software into an open-source project, I read through Eric S. Raymond's essay titled "The Cathedral and the Bazaar" (1997-2000), comparing proprietary and open-source development models, and describing good practices for the latter, using his own experience for illustration. < http://catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/index.html >

Many of his points have direct application to the instant project.

"1. Every good work of software starts by scratching a developer's personal itch."

That's exactly the genesis of the Versatile Feedback DAQ program.

"5. When you lose interest in a program, your last duty to it is to hand it off to a competent successor."

That's the most-important reason why we're here.

"9. Smart data structures and dumb code works a lot better than the other way around."

I hope to clean up the tangle of wires, and generalize the program, by making liberal use of LabVIEW's Strict TypeDefs for data flow, and Global Variables for hardware resource data. An expert LabVIEW coder once recommended (Rules to Code By, or maybe LabVIEW Technical Resource) using Global Variables in the early stage of a program. That's fine. If researchers will dedicate whole computers to an optical tweezers setup, then we do not need thread safety.

"10. If you treat your beta-testers as if they're your most valuable resource, they will respond by becoming your most valuable resource."

I will keep this in mind.

"11. The next best thing to having good ideas is recognizing good ideas from your users. Sometimes the latter is better."

This open forum is meant to encourage the free flow of ideas and suggestions. No personal sniping! The better the software is, the more traceable and reliable the data acquired will be.

"13. ``Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away."

I hope to refactor the user-interface code.

"14. Any tool should be useful in the expected way, but a truly great tool lends itself to uses you never expected."

This already happened at Cornell in 2001. I just wanted something that would be less frustrating to use to take data for my master's thesis, but this became flexible enough to use for nearly-automated instrument calibration.

"16. When your language is nowhere near Turing-complete, syntactic sugar can be your friend."

I'm not sure what this means, but certainly, our "feedback steps" are very primitive.

"19: Provided the development coordinator ... knows how to lead without coercion, many heads are inevitably better than one."

I hope so! When we first wrote this software, our research advisor perceived it to be a competitive advantage. Now, our goals are to produce a useful framework for the larger scientific community.