Question everything

One of the most important things that I could ever teach anyone is to always question everything. This doesn't mean that there is necessarily anything wrong but you might miss chances for improvement if you're not looking for them. Regardless of how well you think something is working it always helps to take a step back and see if you can improve it. Perhaps take on a different persons perspective and imagine it from their point of view. For work processes it's always useful to imagine you're new to the company again. Look at the things you that you might question about how you work and maybe consider how you might adapt or change these. Even with industry standards that might be widely accepted as the norm, you should always take a look at them now and then.

Let's consider unit testing. Although this practice isn't yet an industry standard it is certainly well accepted by now. Relatively recently the team I was working in changed the way we wrote our unit tests. We were a fairly varied mix of developers all previously coming from different companies but all with a fairly standard way of writing unit tests. If you had ClassA then you would also have ClassATests. If you had any dependencies these would all be mocked out and injected into the class using dependancy injection. Most of us had been using the same methodology for years. We'd long since accepted that this was the best way of doing it and that was how we now worked. The trouble was that we'd grown complacent. Although this was indeed better than when we'd been writing code without unit tests, with less bugs and less fear of changing code, we'd forgotten to keep questioning the process. Cue a talk from Ian Cooper on TDD asking where did it all go wrong. I'm not sure who saw this first but I believe it was Mark who first shared the link on twitter. Nick was certainly the first person who shared it with the team. I'd highly recommend anyone who hasn't seen it taking a look.

The important thing is that the signs had been staring us in the face all along. We'd just stopped looking for them. We had solved a number of problems by moving to TDD as we were applying it but code was too hard to change once it was written. As a team we decided to change how we started writing tests. I won't go into details here of how we changed the tests as that's not what this post is about but you should get a good idea from watching the video if you're interested. This of course doesn't mean that we've got it right this time round, but it's definitely better than it was. Hopefully we'll remember this time round to keep questioning the way we do things, even if we think it's working pretty well at the moment.