I am planning to prepare a talk for my workmates, to introduce them the basics of some agile programming methodology, which I think could give us good ideas to improve our working as a team.
It is difficult for me to explain these rules as I don't have much direct experience with, apart for few exceptions, and it is even more difficult because I will have to explain them to people who are not comfortable with programming and with software engineering in general.
However, I also think that I have to prepare this talk early and it will be much more difficult if I wait too much.
Do you have any experience with what I am talking about? Do you have any advice to give me, or can you recommend me a book or a practice that I could explain along with extreme programming?
I think the approach is unsuited for individuals who are not comfortable with programming in general. There is a long way to go until someone becomes confident in their abilities. Before that this approach is not only ineffective, it might be even be detrimental.
Instead what helps most is transparency. Everyone needs to write code in a source code repository that can be viewed, commented and verified. People should become familiar with testing, code coverage, and continuous integration.
thanks for the answer; however, in the first part of your reply you criticized agile programming, but in the second, you recommended to do exactly the things that agile programming is about.
I would suggest to have a look at Scrum, too. Certain parts would help not only bioinformations. For example estimating the time expenditure of tasks and the resulting burn down charts can be really helpful to see if something is stuck especially when working together on bigger projects.The daily scrum reports helps to meditate why who is doing what and offers a platform to discuss problems.
I am a huge fan of Scrum and see it in action every day and get to see the results too. Not optimal for every project, but for many, it's a great idea. I would argue that your colleagues should dive headlong into this. It will not be easy at first, but as a team you will benefit in the long run.
scrum is interesting. I will probably collaborate to a colleague of mine who is using it to prepare a part of the talk on it. Thank you very much for answering.
I think these coding practices are very useful in bioinformatics. Below are two use cases I have been involved in. Both SCRUM and XP are very suitable for development in scattered, online projects. I typically explain pair programming in terms of APIs and understanding what they mean. Misunderstood APIs is one big source of bugs in the CDK mentioned below, and I often give an example from the past to illustrate the impact of misunderstood APIs.
Oscar4 development I was involved in last year used a SCRUM approach, and has been used to discover entities of biological interest for the ChEBI database (we were interested in solvents). Aspects of extreme programming were used too, with one developer writing unit tests, and another the implementation.
The Chemistry Development Kit (CDK) also uses independent unit tests extensively, though not in a pure XP style; peer review of code and unit tests is used, though very often unit tests are written to confirm bug reports by others than the person fixing the actual bug.
An very recent example in the CDK project of a misunderstood API was the useAromaticityFlag of the SMILES generator: one developer thought of the flag part as referring to flags in our code data model, where I understood it as a flag on the generator to indicate that aromaticity should be used by this generator. So, the API was unclear about what this flag was about. Unit tests do not necessarily eliminate such misunderstanding, but it most certainly does help figure things out.
See also the book "The Art of Agile Development"
@Christopher Bottoms: Thanks!! I will look at it.