25

I have an interesting, fairly common I guess, issue with one of the developers in my team. The guy is a great developer, work fast and productive, produces fairly good quality code and all. Good engineer. But there is a problem with him - very often he fails to address edge cases in his code.

We spoke with him about it many times and he is trying but I guess he just doesn't think this way. So what ends up happening is that QA would find plenty issues with his code and return it back for development again and again, ultimately resulting in missed deadlines and everyone in the team unhappy.

I don't know what to do with him and how to help him overcome this problem. Perhaps someone with more experience could advise?

Improve this question
11
  • 11
    Ask someone to cover his code with unit tests.
    – Job
    Jun 14, 2011 at 14:46
  • 9
    The best qualified person to test-cover the code is its author.
    – user8685
    Jun 14, 2011 at 15:16
  • 16
    @Developer Art : Completely disagree. The worst person to do any testing of code is the person who developed that code. Everyone has blind spots but the person doing the creating has the biggest blind spot in reference to his code.
    – James P. Wright
    Jun 14, 2011 at 15:18
  • 2
    @Developer Art: I believe writing automated tests is actually a fairly common role. Typically it is something you do for a year or two if you are not quite ready for prime time in the company you are at. It is sort of a purgatory period.
    – Morgan Herlocker
    Jun 14, 2011 at 15:30
  • 19
    You describe him as a "great developer", "productive", a "good engineer", and producing 'good quality code". But QA keeps finding problems with his work. Would you really use those terms to describe someone who regularly and consistently injects defects into their code? I'm wondering if there's more to this story, since the description of the individual as a professional and the work that they are doing don't match at all.
    – Thomas Owens ♦
    Jun 14, 2011 at 16:49

10 Answers 10

Reset to default
29

Require him to write automated unit tests for his code. Writing unit tests forces one to think through the edge cases.

Some particulars:

  1. To ensure he doesn't feel singled out, this should be instituted for your entire team. Require everyone to write automated unit tests for new code or code they modify.
  2. Require the unit test names to be descriptive as to the case they are testing.
  3. Cover the automated unit tests in the code review at a high level. Have the reviewers look for missed test cases (i.e. those edge cases he perennially misses). After some amount of feedback from his team about missed edge cases, he will probably learn to consider those before the review.
  4. Enforce this rule for the entire team: If QA finds a bug, the developer responsible owes the automated test that confirms the failure and then proves they have fixed it. (before they do any other work)
Improve this answer
7
  • Amen, even better, require that everyone write their code test-first. Using a BDD framework usually lessens the pain of this
    – George Mauer
    Jun 14, 2011 at 16:47
  • @George Good idea. TDD would help even more here.
    – Matthew Rodatus
    Jun 14, 2011 at 17:10
  • 3
    Unit testing is not about finding bugs - blog.stevensanderson.com/2009/08/24/…
    – Dainius
    Jan 4, 2012 at 10:28
  • 1
    @Dainius I agree. The unit testing facilitates a developer thinking through the edge cases, which can preclude (but not identify) bugs.
    – Matthew Rodatus
    Jan 10, 2012 at 15:30
  • After some amount of feedback from his team about missed edge cases, he will probably learn to consider those Developers who have bad practices often argue the irrelevance of the additional effort required for good practice (because they don't see the benefit of doing so). While the developer may acquiesce when you add additional edge cases, that doesn't mean he thinks it's relevant or whether he's going to add them himself.
    – Flater
    Feb 21, 2019 at 12:38
23

Give him a checklist, e.g.

  • null inputs
  • inputs at extreme large end of range
  • inputs at extreme small end of range
  • combinations
  • inputs violating assumed invariants (e.g. if x=y)

The QA folks can help devise the checklist

Give the checklist to all the developers, not just this one.

Improve this answer
7
  • 1
    Good point that all developers should use the checklist, singling out one developer can cause bad feelings. And it could help improve every one's code quality.
    – FrustratedWithFormsDesigner
    Jun 14, 2011 at 15:15
  • Good idea, although I am curious as to how that could be viewed from devs perspective. I never actually came across this practice in my career as a developer, so it's kinda hard to gauge the reaction. Any insights there?
    – Alex N.
    Jun 14, 2011 at 16:01
  • @Alex: checklists are a routine practice for some devs, and a horrible insult for others. Try it and see what happens. If he quits, then your code quality will improve ;-)
    – Steven A. Lowe
    Jun 14, 2011 at 16:27
  • 4
    Your devs won't use checklists? If a checklist could save lives, would they use them? Many doctors don't, and patients suffer. Read this: newyorker.com/reporting/2007/12/10/071210fa_fact_gawande
    – Barry Brown
    Jun 14, 2011 at 17:07
  • 1
    @Barry, I didn't say they won't. Checklists in this case sound, IMHO, like a remedy for symptoms of a problem, not to the problem itself. The problem being discipline and diligence in this case. When the problem is the complexity of a system that require emergency maintenance with a high degree of responsibility and stress involved, that results in a degraded level of attention to detail, then yes, checklists ftw(pilots, doctors, etc.) But that's more of a philosophical debate I guess, outside of the scope of this question.
    – Alex N.
    Jun 14, 2011 at 19:15
17

Good engineer.

Okay.

But there is a problem with him - very often he fails to address edge cases in his code.

It is a quality good engineers don't share.

Watching for edge cases is a characteristic that is either present or not in people. It has nothing to do with being an engineer or a programmer. The development of this characteristic is influenced by the cultural background, living environment, childhood events and the life experiences. Then the attitude is simply applied to any work an individual is doing.

What you need is to find out whether your guy is of that type which has not this certain sense developed (perhaps yet). It is also very likely that he just doesn't care for some reason or another. You need to analyze the entire situation, whether he's happy in his job. If not then perhaps you should do something to help him first.

If he's fine with the job but hasn't experienced the danger of edge cases yet then you may start on educating him. If he takes it seriously he might change his ways over time. Though I'm skeptical on this one you could still give it a try.

If however he'll turn out to be that type of a person who's not good at edge cases then you may have nothing else left but to remove him from the team. This characteristic is essential to practical programming. Sadly, without it even a great person would not produce good work.

Improve this answer
4
  • 7
    +1 This is a skill that some people have an some people have to learn to be a good programmer. However, I'd note that there are two types of edge cases: business requirement edge cases ("If we order 27 left trainers and 28 right trainers that order is probably wrong") which should be dealt with in the project requirements, and actual coding edge cases (dealing with invalid inputs, constantly iterating through lists when a hashset would be more sensible speed-wise when the set gets bigger than x etc.) which are more something you just have to learn about.
    – Ed James
    Jun 14, 2011 at 15:26
  • Thank you for your insight. Really appreciate it. You're quite right on all fronts here, although I am curious, if he is a great person but just lacks this something that makes great engineers great, how can I still put him to do other work and keep him in the organization, maybe moving to another team or something... Although I guess only I can answer that question :)
    – Alex N.
    Jun 14, 2011 at 16:00
  • I've been thinking about it but I'm not sure. Another role to become acceptable for that kind of person should not require attention to details and there aren't many of them in a software company.
    – user8685
    Jun 14, 2011 at 16:33
  • The world isn't so black and white as your first sentence implies. I reckon there exist developers who can identify some edge cases but not all.
    – Mike Partridge
    Jun 6, 2012 at 15:21
5

Could you do code reviews or design reviews earlier on in the process?

Improve this answer
4

There are infinite number of edge cases, covering them all is infeasible. What if someone does #define TRUE FALSE? It adds edge cases, will you check them too?

Also, I wouldn't consider fool-proofing every function of a private class or internal function.

The approach I choose for code that has to be very solid and stable is:

if(conditions_met)
{
DoStuff();
}
else
{
CrashAppAndDumpMemory();
}

This way you get solid application dumps in QA, and by the time you get to a release, the app is solid and safe.

Working around errors is bad. Ok, you might save a function if the file handle is null and returns null, but in most cases, there is a design error somewhere, and app crash is a better way to force you to find the cause. Most edge cases just mask the error by hiding a problem, say - button stopped working. Crash tells you that some assumptions about product are wrong, and you have to revise the logic that's caused the crash.

Improve this answer
1
  • #define TRUE FALSE is not an edge case, it's a sacking offence.
    – gnasher729
    Feb 21, 2019 at 19:59
4

Teach him to program test-first. Pair with him. You will write the test cases and he will write the code to pass the tests.

Improve this answer
3

Could getting QA involved early enough in feature development help provide him with a list of edge cases near the beginning to cover? While some may see this as not expecting the developer to cover everything, this may be a way to work around this if he tends to miss those boundary cases that a tester may well catch initially.

The other idea I'd have here is how does he see this issue. Is he really annoyed and ticked at himself for this pattern or does he just see this as normal and not something for him to worry in resolving? Granted this does require a great deal of trust and getting him to be open on his perspective but I think there is a degree of empathy here that may help if you can see things from his perspective.

Improve this answer
1

If it is an edge case does it even need to be considered? If the edge cases are important then the edge cases need to be feed into the requirements / feature / user story.

If the edge cases have been considered as part of a piece of work and devices are required to be put in place then they should be part of the work item and by definition the work item is not complete until the mechanism for handling the edge case is in place.

This gives you as the Team Lead something to check off against after the work has been complete during the post work discussion and it gives the developer something to check off against as he completes the work.

Improve this answer
2
  • There are always edge cases. If someone claims the edge cases will never be encountered, those aren't the right edge cases.
    – Barry Brown
    Jun 14, 2011 at 17:24
  • 1
    @Barry Brown I agree there are always edge cases but there are a difference between important edge cases that the Stakeholders deem to be important which we can call Scenarios and edge cases that a developer deems important. If a Stakeholder thinks something is important then it should be discussed at the planning session and included as a Scenario on a User Story and not left up to the developer to think of, it should be a proper requirement against the task. It is very time consuming and not necessary to but null checks against parameters on every single non public method.
    – Bronumski
    Jun 14, 2011 at 20:54
1

Catching edge cases is why QA exists. Programmers have a responsibility to push out work on a timely basis. Spending all of their time looking for edge cases is very innefficient. If you have a reasonably quick iterative cycle, then this should be no problem at all. Edge cases are close to infinite in number. If it was a problem with "Core" cases then I would be a bit concerned. Just as developers are expert at development, a tester should be an expert at testing. When a tester finds a problem, they send it back to development. The developer fixes the issue. Problem solved. The time for a developer to track down every edge case is a lot longer than the iterative testing cycle should take. Also note, when I am talking about testing, I do not mean white box unit tests, but strictly black box tests. Writing unit tests is the role of the developer, and is part of the development process, not the testing process.

Improve this answer
2
  • 1
    This is really not the right answer. Being rewarded for outputting half quality work is bad practice. The development team should as a whole be responsible for high quality work.
    – David
    Dec 3, 2016 at 14:15
  • Decent developer doesn't have to look for edge cases. Some code is written so it doesn't have edge cases, in other cases edge cases are obvious. Code not handling edge cases is incomplete code.
    – gnasher729
    Feb 20, 2019 at 21:25
0

That is one of the case where I believe test driven development comes to rescue because it helps to think in terms of edge cases and anything that can break the code.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.