I'm involved in a local Open Source Rails project.
It's building a web site for people to donate money for development/aid projects in developing countries. The purpose is very motivating.
Since it's local, I have been attending their meetings every week.
There are some disappointments.
I just list them as they come up to my mind.
- A person is against writing functional tests and doesn't know what Continuous Integration is for. And he is warning that there will be a merging problem with confidence. -> Well, if there is a merging problem and a problem of dealing with it, that's because he doesn't write tests and that's because he doesn't know anything about Continuous Integration. Continuous Integration and running test automatically are for preventing such a merging problem.
- A person insists that if you design up front correctly, you don't have to change anything later. He says Refactoring is necessary only because architecture is not defined correctly at the beginning. But he is ignorant with Ruby on Rails built-in architecture. -> First of all, software development is a product development activity not manufacturing. And it is closer to scientific research in the sense that discovery is constantly made(See Mary Poppendieck's Lean Software Development.). Second of all, he is forcing his architecture as if it is the only one. There are many architectures for different purposes and different tools. And Ruby on Rails uses one of them. And all the rest of the team have understanding of it and are trying to follow it. He is the only one who is ignorant about it and believes that his architecture works for Ruby on Rails.
- Developers are expected to bring the code in their laptop to the next meeting. Committing the code to RubyForge is prohibited. -> That's not utilizing Open Source approach. When some of them were working on this project under SourceForge, one person (the same one as the first one above) was committing the code without running tests and the code was constantly broken. Now they are preventing developers from committing the code? Write tests, do Continuous Integration!
I wish I could speak up. But just like the consulting company I worked for before, which I wrote about several times, if I speak up and say the right thing when others are completely wrong, if they don't get it, they do anything to discredit me and socially destroy me by spreading bad rumors in this city. Unfortunately, there are many people in the city who take part in as their tools.
It is even a joke that a person in that company who is writing testing patterns book is criticizing me that I'm insisting on writing unit tests, using the excuse that unit testing is not necessary if testing doesn't fit the organization. (The claim that Agile should be adjusted to fit local environment is not an excuse to ignore software quality.)
So I learned that it is important to work for a project/organization/team that embrace what I'm into, namely, Agile software development. And it is better than persuading a team who doesn't embrace Agile software development.
And because last year in this project, there was an argument between me and the first person above about Test-Driven Development and idea of Continuous Integration, both of which he had no idea about, when I was invited again to the project about a month ago, I decided not to say anything because I thought it was not an environment that embraces Agile software development.
Luckily, there were at least two people who understand Agile software development. And until a few weeks ago, I was getting a better feeling about this project.
Now, I'm disappointed again.
And there are many things they are trying to solve that are already identified by Agile software development (, which even provides solutions already). Do I have to go through all the troubles and time until they rediscover the same solution on their own?
No comments:
Post a Comment