Posts Tagged ‘Evident Based Managment’

Evident Based Coding – Stating the Obvious II

January 31, 2009

Continuing from the previous post let us check why would one pay a developer who can’t prove his code is working.

When I was in Check Point I used to have weekly pseudo-random interviews with employees. It is a great habit that I learned from Dorit Dor, my manager at the time.

When you manage 200+ employees it is one of the only ways to get direct feedback and stay in touch with what’s really going on, but it turns out to be a good idea even when there is only a single employee reporting to you.

One of my favorite questions to developers was :

How do you KNOW the code you produce really works ?

Amazingly, this pretty simple question had all of them surprised.

The university graduate, the PHD, the autodidact  , the hacker, the PC kid and even the group manager. None were prepared for this question.

The Surprised Software Developer

The Surprised Software Developer

The common answers were :

  • I don’t know it works, but I have a good feeling about it
  • It works most of the time
  • QA will test it and than I’ll know it works
  • I tried it a bit and it looks fine
  • I did a code review with my team leader and he approved it
  • It is a small change and I’m confident in it
  • There is no way to do it in the time I was given

As you can imagine, I was not very happy with most of these answers. Here are some of the best developers in the world, with five time the salary of a social worker with 30 years experience, and they can’t explain why their work is actually ,hmm, working.

My belief is that the Developer has to PROVE ,to a reasonable degree, that code he commits is working as planned and does not break other code.

If he can’t do it , he should not be committing the code to the general working branch.

How can the poor programmer achieve this goal:

  • Running and writing unit tests for his code and running them
  • Writing sub system tests for his code and running them
  • Using code checking tools, looking for warning, errors and suggestions
  • Asking peers for a code review
  • Going through the design and requirement and validating actual code implements them
  • Manually working with the system and going through all scenarios he claims to support
  • Spending couple of hours trying to come up with all the extreme cases and special problems
  • Going over the QA test design and making sure his code will pass the tests

And by the way, if all these methods are not available \ reliable or feasible it is also OK to commit the code if the developer EXPLICITLY lets everyone know the status before and gets the managers approval.

I want to commit the new screen, but I never tested it on FireFox and there for I assume it does not work on FireFox. Is it OK to commit ? I also didn’t test the sorting or the client side validation, but I think they might work because I didn’t touch this code and it is very solid

Obviously , developers are notoriously over optimistic  so this should be kept as a last respot, but making them say it out loud is key to maintaing high level of professionalism and ownership. More on this in the next post.