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 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.
Tags: developer, Evident Based Coding, Evident Based Managment, interviews, quality, Software Testing
