Have you given your development processes the thought they deserve? Do you consider the benefits of different approaches in different contexts? Do you question whether established practices are right for you and your team?
It seems obvious to say that we need to separate our tools from how we choose to use them. Or that ‘best practice’ varies depending on your particular situation. Yet it is common to see teams fall into process by default.
Branching strategy dictated by git clients
Feature Branching is not Continuous Integration. Whatever your thoughts on these branching strategies, they are clearly contrasting approaches. It basically comes down to a choice to integrate now or integrate later.
Yet, i’ve seen talented engineers who have embraced CI, suddenly start to adopt a feature branching approach without thought. So what made these usually considered software professionals switch to an opposed branching strategy in the blink of an eye?
They simply installed a new git client. Led astray by shiny new UX flows, having rashly abandoned their long established principles.
So, it was interesting to see Thoughtworks placing the Gitflow tool on ‘Hold’ in their November 2015 Technology Radar explaining that they believe in CI and “abhor tools that encourage bad engineering practices.”
While highlighting undue influences in this way is useful, are tool authors really the party to blame?
Killing off TDD because of dogma
A similar problem occurs when we blindly follow best practice to the extreme.
As a test-first fan, I was saddened to read David Heinemeier Hansson’s experiences that led him to declare that TDD was dead to him back in 2014. He felt pressure to follow the dogma and to not even question whether it was the right thing despite his instincts that it was having a detrimental effect on the software he was producing. What chance does your average developer have of rationally evaluating best practice if this is the experience of the creator of Ruby on Rails?
Whenever I teach TDD, I encourage developers to think of it as a tool in your armoury. Part of mastering it is to understand its benefits and limitations to the extent that you can apply it where and when it suits you.
No technique should be elevated to the point where it is beyond question.
BDD thrown out based on tooling preference
Questioning the value of a practice in our own context, does not mean dismissing the success others have had in theirs.
I’m a happy user of SpecFlow to create executable BDD specifications, but in the past have also taken a more simple approach when the tooling wasn’t up to scratch for my given technology. A recent Thoughtworks article highlighted a similar alternative and triggered a discussion that not only questioned the value of those tools, but bizarrely of BDD itself.
It took Dan North to bring some common sense to the discussion. Here’s his response to the question of whether BDD should be ‘considered harmful’:
Why are we obsessed with finding the one true way? The experience of employing both of these options with success in different contexts should be seen as a good thing. A deeper level of understanding that will help you face that decision again when the next new situation comes along.
Be in control of your autopilot setting
Some things aren’t important enough to spend time thinking through. Sometimes you just need to trust in the popular option for now and get on with more important things. But these should be conscious decisions that this thing doesn’t matter enough for me to care.
Don’t slip into autopilot on the things that matter to you and your project. The autopilot switch is yours, choose when to use it.
We can learn from others who understand our situation or from experimentation. But we should do it explicitly, with consideration. An experiment with a deliberate learning goal is not the same thing as taking the easy, default route without thought.
Context is everything, and responsibility has to be ours
As an industry we need to be open to the idea of different solutions being applicable in different contexts. We need to understand the benefits and limitations of the tools, process or practices that we adopt. Only we can take responsibility for their success or failure in our particular context.
Experimentation can help us to learn. We can decide it’s not important enough to matter. But if we blindly apply someone else’s approach, how can we blame them or their suggested practice for our failure?
Regardless of what you think about git branching strategies, TDD design feedback or BDD tooling, don’t let someone else’s best practice, dogma, or UX decisions silently dictate crucial parts of your software development process.