OT - How to deal with coders who don't do what they should

[Juerd]

Hi,

We've probably all been in a situation where you let someone do something, and when it's done, it doesn't even meet the simplest requirements.

The code in question this time was some server side scripting of a website. The objective was very simple: let the user enter data, and save the data in a database, and let the user be able to query it via pre-set queries. The result was a working website, and some beta testing users entered over a hundred of entries. It has been online for a week, and today, I requested login information so I could get some statistics out of the database. I logged in, fired up mysql, requested a list of tables, let mysql describe them, and when I found the table I was looking for, I looked for the field of which I wanted statistics. The field was not there. I checked the source code of the scripts, and the field was not there.

The information was supposed to be one of the fields in a unique index. The user has to fill it in, but after checking that, the data was never saved or even parsed!

I'm not sure what to do. My first reaction involved cursing and yelling (fortunately, nobody could hear me), but I don't think I should do the same when I talk to the guy who coded it. However, if I'm going to be too friendly, he might not realise he's done something terribly wrong.

How would you handle this?

UPDATE
Thank you all for your detailed responses. I like the solutions that involve standard procedures, and we are going to set up some. For this particular incident, more faults were made than the database issue - a big mistake was not beta-testing the results of the entries. The beta testing was done completely web-based, and no-one realised essential data was never used. The database design should have been tested against the requirements.
As for fireing, that's not an option. This programmer tends to be lazy at times, but in the end is a good one. I have spoken with him on the phone and over irc today, and the problem will be fixed soon (I hope). All of his code is going to be reviewed, and from now on, every implementation has to be tested on the server too, not just web-based.
Thanks again for participating in this meditation. It has helped me to re-arrange my thoughts and to take action in an appropriate manner.

U28geW91IGNhbiBhbGwgcm90MTMgY
W5kIHBhY2soKS4gQnV0IGRvIHlvdS
ByZWNvZ25pc2UgQmFzZTY0IHdoZW4
geW91IHNlZSBpdD8gIC0tIEp1ZXJk

[footpad]

I tend to agree with lemming. Perhaps you should verify that the field in question was, in fact, included in the specifications you provided to the coder. (Based on your initial reaction, I presume that it was.)

(I'm also presuming that there's more to the story, given the title you gave the thread.)

Next, I would time myself out long enough to be able to approach the coder with something along the lines of, "um, I can't seem to find this data we're supposed to be tracking. Am I missing something?" This provides a graceful exit in case an honest mistake was made, either by your coder or you.

Finally, once you figure out what the problem is and what needs to be done to resolve it, then I would tell the coder that, "OK, this needs to be resolved quickly and I'm going to send an email to follow-up." That will give you a paper trail, in case it becomes necessary, and highlight to the person involved that it's serious enough to be tracked.

At that point, you see what happens. If the problem is resolved, then simply make a note to discuss unit testing and requirement checklists during your post-mortem. In fact, you might even try to generate some discussion about how to improve that. Use care not to mention specific problems or to embarass your staff in front of your customers, their peers, or others. (That doesn't help in the slightest and, in fact, hurts a great deal.)

In other words, once the specific problem is resolved, you'll want to focus on preventing similar incidents in the future. While there are times big sticks are useful, I've rarely seen them effectively applied to improving employee morale or programmer accountability. YMMV.

--f

[dug]

Lemming makes a very good point that if the first reaction is scream and curse and yell that it's probably a good idea to meditate on your response for a bit(which you obviously realize, or you wouldn't have posted a Meditation).
It really depends on what your relationship is with the offending coder. If he reports to you, you have a couple of options.


• Teach him. Do code reviews on *all* code that is going to be pushed into a production envionment. It's your job.


• Fire him. If you've repeatedly tried to teach him, and it hasn't worked, he's probably not right for the job. This could also mean firing him from his current position and moving him into another that he's better suited for.

If the offender doesn't report to you, it's more a question of how you want to deal with your personal working relationships, and I don't have any advice there. <grin>

[oakbox]

Having your own mistake pointed out to you is extremely embarrassing. There are three possible programmer reactions:
1. Programmer gets a sick feeling and immediately tries to fix the problem . . . perhaps even before fixing the process that made the mistake in the first place.
2. Programmer takes a look at how the mistake got in the code and modifies the process to keep it from happening in the future.
3. Programmer denies responsibility for the mistake and chalks it up to 'bad requirements'.
The thing is, number 1 is just as unhealthy to the long term as number 3. That's the preaching of Demming, fix what's causing the problem, not just the problem itself.

So, to be more specific, point out what went wrong, what you wanted to happen, and take time together to go over the requirements again to make sure that they are clearly understood. Make a better 'beta' process and don't rely solely on the person who wrote the code to tell you whether or not it works. Users are more creatively stupid than programmers, you have to let them practice THEIR expertise :)

I hope that wasn't too far off-topic.
-oakbox

[lemming]

Hmmm. Could a bit of code that was probably going to be put in last and was forgotten?

I would just tell the coder that the information you wanted is not being saved. Could he fix it as soon as possible? Perhaps send an email, though in your situation, I would save the draft, do a couple other tasks, and then read what you wrote before sending it.

[dws]

You didn't indicate how you communicated the objectives to the programmer. I'm guessing you did so verbally, and am further guessing that you didn't specify acceptance criteria (i.e., "when you're done, this is how you'll have to prove to me that it works").

A bit problem with one-time verbal instructions is that it's too easy to hear enough of them to get your mind latched onto a tempting problem, at the expense of the complete requirements. You've gotten the problem halfway explained, and their minds are already racing ahead towards crafting the perfect regular expression/using some new CPAN module/whatever. Happens to me all the time.

So follow up with an email, laying out the objectives, including what you'll look for in a solution (i.e., acceptance criteria). I've found that it often helps to throw in additional context, such as some notes about who will be using the result, and what their usage pattern is expected to be. If you want to go a bit more formal, sketch out a Use Case.

[Ryszard]

FWIW I go the proactive approach with these types of situations.

If there is a project I'm working on with others, I:

1. Explicitly define the deliverable
2. Define milestones
3. Have regular (weekly) meetings to track the project
4. Test the project against specifications
5. Make any necessary changes, repeat previous step until it meets spec.
6. Sign off the project

Of course, this isnt going to help once the horse has bolted, so my preferred course of action would then be to book meeting with said individual and calmly ask him/her to explain why their deliverable is off spec. After that, it is getting them to re-do the project on spec with the above guidelines.

HTH

[Slipstream]

If you paid him for the work there's no reason to be shy about how you feel about the results. If he did it for free you probably shouldn't be too hard on him. Definitely let him know what the coding mistake was, but do it nicely. He'll probably be so embarrassed about the mistake and the time it wasted that he'll know he's done something terribly wrong without you yelling at him too.

[insensate]

Your license to criticize the developer's role in this depends entirely on the requirements you provided him/her with for this project. Were they formalized and agreed upon? Were they clearly presented and sufficiently comprehensive? Sadly, I think all too often developers get the bad press when poor requirements gathering is, in fact, to blame. It is somewhat sad how meticulous one must be when presenting development guildelines, but not doing so will bite you in the end. So, my advice...if the requirements were clear, a stern rebuke is in order...if not, perhaps a process revamp. -Jason

[trs80]

• Who was at fault?
• It seems that something like a key database table field should have been spotted earlier in the process, who signed off on the beta testing?
• Who wrote the table create statments?
• How long has the person been doing development?
• Who made the work assignment?
• Who wrote the requirements?
As for the tone in which to address them, that is the same tone you wish to be addressed in when you do something that someone else will think is stupid.

[Desdinova]

When I first starting get paid to program i made a bunch of mistakes like this. Thankfully my boss at the time was really into helping me learn from the mistakes. I ened up learning a lot about how to ask the right questions during the requirement process.

One of his favorite things to do in a situation like this would be to ask to use the code as intended ie in this case the stats you couldn't find. Doing this had two effects one it made me rememeber the mistake without having to berate me. I aslo ened up adding this to my QA process. After I get done with a piece of code I grab the requirements sheet and try the software based only on what is written on the req.