The following is a guest post by W. Trevor King, a a biophysics Ph.D. turned freelance software developer who moonlights as an evangelist for open source software in general, and Git and Python in particular. For more, check out his blog.

——–

At last month’s Software Carpentry lab meeting, Paul-Olivier Dehaye asked how non-coding scientists should hire software developers.  My initial reactions were:

• Hire someone you know, or someone your coding friends recommend.
• Your umbrella organization (university, professional association, …) should manage a pool of competent developers and assign one to you.

Bill Mills suggested “a combination of gambling and short contracts”.

After thinking it over a bit more, I’ve decided that all of these work well if you’ve got someone around who can assess developers or their work.  If you work in a reasonably sized institution, chances are you do know someone who can assess developers.  Seek those people out and ask them for their advice in your hiring process.

If you can’t find anyone whose assessment you trust, or don’t have the funding to hire anyone they recommend, you’re going to need another approach.  I’d suggest you learn enough to develop your target software yourself (or delegate this task to a minion).

“What?” you say, “That sounds like a huge task!  I’m too busy to learn all of that stuff!”  And you’re right.  But don’t worry, you don’t have to learn it all.  Come to a Software Carpentry workshop or read through our lessons, and then just dive in.

“But,” you say, “if I start before I have any experience, I’ll write terrible code.”  And you’re right again.  But don’t worry, everyone writes terrible code. A surprisingly large amount of the software you use every day could benefit from another thousand developer-hours of polishing and re-architecting.

The secret sauce that makes software systems work—even with half-trained developers banging away at them—is version control.  With version control systems like Git, it’s easy to track your changes, along with notes about why you made each change.  So when you find flaws in your initial implementation (and you will), you can commit a fix, along with an explanation of what the problem was, and how your fix addresses it.  When the language or libraries your software depends on change (and they will), you can commit updates to the new versions, along with an explanation of how the dependency changed, with pointers to documentation for the new versions you’re using.  This all means that when you’re just starting off, you only need to write something that mostly works.  If the initial iteration seems promising, you can work on futher polishing and improvements as you find the time.

So while the hurdle to developing professional-grade software is as high as it is for doing professional-grade anything, the hurdle for developing a quick-and-dirty script that gets the job done is much lower.  Unless you have the time and money to organize a hiring committee and manage a contract developer, it’s probably better to roll up your sleeves and start building it yourself.  There are plenty of folks around, including those of use at Software Carpentry, who are happy to coach you through any tricky parts and point you down productive avenues.

p.s.: If you can sell your your colleagues on your great idea, try and get them to help out.  It’s always easier to learn when you have other folks around to bounce ideas off.  By the end of the two-day Software Carpentry workshop, you’ll have the version-control skills you need to develop on your own, or with a group of collaborators.

p.p.s: If you decide developing is not your cup of tea, the initial investment in learning the ropes is not a complete loss; it puts you in a much stronger position to hire and manage developers for your next project.