All progress is done in the light of resistance. Without it you don't have a real chance to refine your thoughts and check if what you believe is really something that you can trust. The discussions as long as they don't get personal and long as they don't become monologues are very constructive as you may find holes in your ways and only then you have a chance to spot them and in effect progress.
So yesterday I did have a chance for that in two areas.
First I discovered that I favor static mocks over dynamic too much. It started when a colleague asked whether or not he uses mocks correctly, because he found that changing some system behavior he has to change the dynamic mocks he uses as they are still set to the old way and the test fail. I said that it's perfectly normal and he should change them as well. Then he's shown me how he uses those dynamic mocks (dynamic proxies), and I said that in most of these cases I would use a static mock (a null implementation), and we talked a little more.
The conclusion was that there isn't a hard line which separates the use of static versus dynamic mocks, but more importantly I found that I got too friendly with the static ones, as e.g. it is a good thing that his tests didn't pass as it's a empirical proof that those tests really do test something, and that has built more trust in us. And that's good.
I found that the use of static mocks in such a case might have not cached the change and we wouldn't get that valuable piece of feedback, but what struck me was that a dynamic mock has a greater chance to uncover a badly written test (or mock), because you set specific expectations and not just a dummy null implementation that does not verify how it's been used. I certainly have to pay more attention to that and make more use of them.
But then my further remark was that on the other end the extensive usage of dynamic mocks may uncover, cause, or sanction tight coupling and an unclear architecture, so you have to stay alert and primarily use your head then mocks :).
The second thing was a chat with the leading programmer, he also plays a role of a customer proxy. He was the one to earlier refuse to work on some subject for now, as he has a different view on how do implement something from the rest of the team. He told me that although he sees that those things I've brought to the team are good and helpful he does not identify with them. He said he will not cause any trouble and will cooperate, but personally this is not a way he wishes to work, he has a long (10+ years) history of software and hardware development and he likes to work alone or with his partner who grasps everything just like him. Additionally he says that all the planning, story cards and stuff he has in his head and that suffices if he and his partner are the only one on the team. He says he has a history of happy customers that loved the products he gave them, done quite internally with little in-process feedback from the customer, and those programs are till today flawless.
Well what could I say to that? I said: "Well, let me treat that as one of the wonders of nature. I'm happy for you, but too many times I saw just the opposite to fall for that." What was I supposed to say? :)
We had an open talk so we assured each other that all your disputes are not personal and stay professional, so that we progress as a whole. Again he added that this is very interesting for him to realize that this style of work as advocated by XP is very useful and valid but it is not the style he wishes to practice in the future and maybe that's a sign for him to change some things in his professional life.
I'll never give up trying to convince him to those values but I know I'll have a hard time doing that. Nevertheless it was a healthy discussion and I hope it has set our attitudes towards each other in the right direction.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment