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.


Follow

Get every new post delivered to your Inbox.

Join 195 other followers