Don’t be pragmatic be agile

For those of you that didn’t know I used to work at Typemock. I was in the midst of the unit testing world where TDD (Test Driven Design) was my bread and butter. As part of my work I’ve learned, taught and blogged about unit testing and Isolation/Mocking.image

At Typemock I working in an “Isolated” environment where I always had time for writing tests, code reviews, and pair programming – and I believed that this is the way it should be done…

Since I left Typemock I was exposed to a new world – the world outside of the TDD inner circle where developers don’t write unit tests or write them after the code has been written.

Luckily for me my team were well aware of the benefits of writing automated tests even before I got there and so my main goal was teaching them how to improve their tests and how to use fake objects, but the change doesn’t happen overnight it does takes some time.

At Typemock I was very strict – the code should be written THE RIGHT WAY and pair programming should be done when possible, unit tests should be written before the code etc. On my current position I cannot afford to be this way – there is a big code base some of it written according to the best practices and some that did not, luckily for me most of the code is covered by automatic tests but some of them need to be refactored. Had I started my work expecting everything to be “perfect” I would have probably gone insane! Instead I’ve concentrated on incremental improvement, as long as I could see a daily improvement I was happy. I’ve used code reviews to teach coding practices and test writing skills, I’ve scheduled several sessions with the team and thought them about fakes and TDD and of course wrote quite a lot of code that served as examples for the rest of the team and helped me get familiar with the system.


Now when I look back at the last two months I see great improvement in the teams code and project quality.