[Biojava-dev] Biojava3-Core

LAW Andrew andy.law at roslin.ed.ac.uk
Wed May 12 13:25:17 UTC 2010


Don't think that there's anything I'd disagree with in what you've written. And he who controls the commit phase, controls the game (to paraphrase an obnoxious NZ rugby referee's tattoo).


On 12 May 2010, at 13:21, Richard Holland wrote:

> The below is a massive generalisation based on my experience of having worked as a software developer both in academia and in commercial environments (including an airline and a bank).
> 
> The standards of academic-generated software tend to be defined as whatever the author (usually a sole author) identifies as requiring least effort to achieve, so the library that gets used is the one they've just found on Google that looks like it probably works, the formatting is their editor's default, documentation is minimal (because most users will probably just email and ask questions anyway), user requirements gathering is based on asking friends at coffee, the code commenting is for their own short-term reference (because most software ceases to be developed any further after the paper about it is published or the author leaves the institute), etc. The standards tend to be selected as whatever makes the author's life easiest, as the software's purpose is to support some other research and usually is not the author's main goal - it gets published as a side-effect of their main research interests.
> 
> In commercial software standards tend to be defined by best practice, with authors (usually teams) being asked to adhere strictly to defined customs such a code formatting, and to thoroughly test any new libraries before using them. Detailed user documentation is required because helpdesks are expensive things to run, and proper detailed user requirements gathering is important to minimise subsequent helpdesk contact and improvement requests. Code commenting is also critical to aid new members of the team to take over when old members leave and there's no overlap to transfer knowledge face-to-face. These processes slow down development and increase the costs of the software produced but they do ensure that the code is of higher quality and is more maintainable, and that the users get more benefit from it.
> 
> The above comments might seem harsh over-generalisations but I can put my hand up and say I've definitely been guilty in the past of most of those academic charges myself, and I know plenty of others who have been there too. Likewise I've experienced how depressing it is to work in a commercial environment so strictly locked down that you think development is heading nowhere because it's just all too much effort.
> 
> BioJava sits between the two, along with most other Bio* open source projects. It's produced and maintained mostly by a team, as in commercial software, but that team is made up mostly of academics. If we want BioJava to be accepted as quality software we have to adopt at least some of the above commercial software development techniques, and then we need to ensure that everyone who develops for BioJava sticks to them to the letter. That could include being asked to reconfigure default settings on editors, post detailed explanations about choice of external libraries, etc.
> 
> cheers,
> Richard

Later,

Andy
--------
Yada, yada, yada...

The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336 
Disclaimer: This e-mail and any attachments are confidential and intended solely for the use of the recipient(s) to whom they are addressed. If you have received it in error, please destroy all copies and inform the sender.






-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.





More information about the biojava-dev mailing list