Monday, January 15, 2018

Leadership Philosophy

I've been a tech lead for several years now, and I'm often asked (at interviews or general discussions) about my leadership philosophy. The running joke in places I've worked has always been that I run a tight ship - but this while true, can often be misleading.

It's true - my software projects have always met deadlines and always had some of the lowest bug per release rates of the places I've worked at. Some may jump to the conclusion that do this my dictacting the every move of my development team, which couldn't be further from the truth. Far from it, all the developers that have worked on my systems will readily tell you that they have enjoyed more individual freedom working under me than they did most anyone else.

How do I achieve this? Simple I focus on and create an extreme culture of accountability around the what, not the how. What I want is simple: robust maintainable software that conforms to spec (functional and performant) delivered on time. How individual developers achieve this is their concern, and while as lead I'm always willing to suggest ways to improve on quality and speed of an individual developer (hello vim..haha) I'm certainly not overly (or much at all) concerned with individual preferences. Focussing on HOW they deliver their code is micromanaging. Yes it is. Insisting on pair programming? Micromanaging. Insisting on TDD? Micromanaging. The worst thing about micromanaging (apart from the fact that everybody fucking hates it) is the fact that time spent focussing on the unimportant (the how) is time spent not policing and focussing on the important (what is actually being produced).

Look TDD is awesome  - I find it is especially useful in making me focus on requirements and not code when writing tests which is pivotal when writing quality tests. However, if a developer is giving me quality code with well written tests without using TDD, why on earth would I force them to use TDD?

It's important to differentiate things that constitute individual working styles/process and separate that from (and focus on) the work they produce. Try as little as possible NOT to dictate personal process - it's not just that it's not helpful, it's often counterproductive.

Now if a specific developer is failing to meet clearly defined team standards e.g unacceptable number of bugs introduced by said individual, failing to meet deadlines, failure to write proper tests, code not meeting specs (all things that you should be religiously tracking on your team) - Then and ONLY then should you sit down with said developer and go over their process insisting on changes that you feel would result in better software.

Monday, January 8, 2018

Writing Tests - Why do we actually do it?

I recently had a discussion about about whether or not people should test private methods. One of my colleagues exclaimed that the problem with rule of not testing private methods is that it is essentially tantamount to saying that you should not have anything complex enough to test in your private methods, which on its face would appear to be a bad rule.

My colleagues response illuminated a common and dare I say almost crippling problem with our industry. A failure to properly distinguish between preference, philosophy and fact and properly convey said differences when communicating. A failure to take the time to understand what the other person is saying and why before drawing conclusions.

Testing private private methods is not a rule so much as it is a logical conclusion. One that stems from a fundamental difference in the philosophy of testing.

We do not write tests because the code is complex; inversely and INFINITELY more important, we DO NOT neglect to write tests simply because the code is simple. We write tests as a means to programmatically state and verify system requirements. We test system requirements/specs NOT implementation. Good tests as much as possible refrain directly touching implementation details (and let’s be clear - a private method is the definition of an implementation detail). A excellent test suite should be able to endure significant system extension/refactoring/implementation changes and still run successfully - this in fact is one of the major advantages of a good test suite, the ability to refactor with confidence.

If you’re testing a private method, it means you are doing one of two things:

1) Neglecting to test the actual feature/requirement which said private method was written to fulfill
2) Testing a piece of code that is already being tested via the test written to verify the feature/requirement that said private method was written to fulfill - this is called testing noise.

Both cases are obviously a violation of the philosophy behind testing as stated above. As a result, both are equally dangerous in the long run. While the dangers of the former are obvious, the latter, apart from rapidly making the test suite unwieldy, makes the development team numb to failing tests - tests are failing not because the system isn’t working properly anymore, but just because I cleaned things up and removed this unnecessary private method - and makes developers comfortable deleting tests when they fail.

This is one of the fundamental strengths of TDD. TDD forces you to write tests before implementation, which ensures that the tests focus on the requirements and not implementation. TDD is a process that lends itself to significantly better tests which in turn result in significantly better software.

Tuesday, January 2, 2018


Here you will find the simple musings of a longtime technologist, as I take a much needed break.

Part perspectives on specific issues, part industry level disgruntlement from far too many years creating software professionaly.

Leadership Philosophy

I've been a tech lead for several years now, and I'm often asked (at interviews or general discussions) about my leadership philosop...