+972 52-548-6969
Slipping under the radar
I am having quite a few interesting discussions at DevTeach, and one of those had to do with introducing projections and processes against opposition. For myself, I am a... bit forceful about such suggestions, especially in face of stupid opposition.
One of the things that came up was simply to do it, the old "it is easier to ask for forgiveness than permission". I am both supportive for that and not really comfortable with the idea.
I support it because it is a way to actually get things done, but I got a really good example of why it is not always a smart idea. The story was using Rhino Mocks for mocking, with some team members starting to use it without proper introduction.
The resulting code created tests that passed, but had a strong coupling to the code under test (too many mocks, too much expectation). When the code change, the test broke, because it was specifying too much.
For myself, I have seen similar issues that can result as slipping stuff under the radar, which is why I am not comfortable with that in most cases.
It is not always the case, continuous integration is one such case in which there isn't usually a problem in just setting it up. But if you are adding a dependency to the system, you need to make it clear to the team how it works. Doing otherwise introduce the bus factor, damage the ability of the team, and a host of other problems.
By the way, this doesn't mean that all your team members have to have a vote in any dependency, or any pattern, but it does mean that they all should be aware of them.
Comments
About forgiveness vs. permission, I used this approach and I can point one more issue with it - I'm not always right (although usually I am :-) ) and this can cause doing stuff the wrong way. Besides, when someone else in your works this way and in my team there is this someone else u get inconsistent approaches to do the same thing which is really bad.
Still, sometimes u just can't avoid working this way.
Comment preview