Just change stuff

The last few months i was supporting another team in it's efforts to deliver their product for a deadline. I was a guest developer with a fixed set of stories to finish. As a guest developer i try to absorb the development culture of the team and follow it. Because as a short term support i don't have the time nor the leverage to change the culture. But in these months i observed a certain rigidness, that was blocking change. This is a short story how change was realized.

This team has a self written assertion framework (in general this is not advisable, however in this special case there are valid regulatory reasons for this). This framework is still very young and not as mature as any of the outside world assertion frameworks - so there is definite room for improvements. However every time there ought to be an extension to that framework, like a more precise assertion than Assert.True(), they started a series of events: Discus this extension with the whole team; write and verify the actual extension; adapt ALL tests that may be improved by this new extension; write and integrate a new static code analyzer to guide all developers towards the correct usage of the extension and finally tell everybody again about this. There are enough developers on this team to do all this work within a few days. However this big rigid process, that just grew somehow, was forcing the assertion framework to remain in its state.

Now i was happily TDD'ing may way through the stories and found the assertion framework somewhat tedious to use in order to express my intentions - which is perfectly normal for a young framework. So i fiddled with the assertion framework and just added what i needed with a few unit tests. This little extension took me roughly 30 minutes to write. Now this extension was living on my private branch and i was happy with it - i wrote my own tests with it and adapted a few dozen tests that i encountered along the way. However i was worried that this extension might not be easy to bring to production because of the grown team culture. So in the next big meeting with all developers i raised my hand and stated that there is an upcoming pull request in which i changed the assertion framework, because "i wanted to do this". I explained the gains of the new extensions and everybody agreed that this is nice. And then they started thinking about their process and a moment later they were joking about they shear complexity of it. Long story short, the extension went to the main branch without any hassles. Adapting all existing tests and maybe a code analyzer are still options, but they are not strictly necessary and they can be realized when there is nothing more important to do.

My takeaway from this experience is: Sometimes process and culture seem very rigid, tiresome and intimidating. But in many cases this is just by accident. Situations like this should be challenged. And an easy and very direct way of challenging such a process is, to not follow it but take the short route to the solution and observe the reactions.