Sign up ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

Hi Programmers Community.

What are your thoughts on the following:
Is there value in having new developers (graduates) start as testers / bug-fixers?

There are two schools of thought here that I have come across.

  1. Having new developers (graduates) start as testers / bug-fixers / doing SLA (Service Level Agreement) work, get's them familiar with the code base. It also allows them the opportunity to learn how to read [other people's] code. Further more, by fixing bugs, they will learn certain bad and good practices, which could hopefully help them in the future.

  2. The other way of thinking though, is that if you immediately start new developers on something like testing / bug-fixing / SLA work, their appetite for the development world might go away, and/or they might leave the company and you potentially loose out on a great future resource.

Is there a balance that should be kept between these two? Currently where I work there is no clear-cut definition of what new starters do. Some go directly on to client work, while some fall in to the SLA world. Should companies have such a policy? Or should it be handled on a case-by-case or opportunity-based basis?

Hope to hear from some of you that have experience in this field. Thanks!

share|improve this question

closed as primarily opinion-based by Ixrec, MichaelT, durron597, Bart van Ingen Schenau, GlenH7 May 28 at 13:49

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

I think an "orientation program" where they spend 2-4 weeks focused on the different aspects of the job migh not be a bad idea. – Joe Internet Mar 12 '11 at 16:18

4 Answers 4

up vote 7 down vote accepted

I would argue that it is a poor way to introduce new developers to your organization's code base. However, given the poor state of many organizations practices in many organizations, it may work to introduce them to the practices.

It has been my experience that most organizations don't have a lot of good development practices. This makes it difficult for a new hire to start developing code in the organization's way when they first join the company. Starting people out debugging forces them to get to know the code and practices of the organization. (This may beat whatever good practices they came with out of them.)

There also seems to be a feeling that new hires aren't ready to start developing code and they can't do much harm debugging. I would argue the opposite, that it would be better to have them start coding, and use mentoring and reviews to instill any standards. They may add needless complexities. (Research at NASA showed bug fixes tended to cluster around the most complex code which got few fixes.)

I can't think of another field where you would be expected to spend their first six-month to a year doing something else than what you were hired them for. If you need testers or bug-fixers hire them, or change your process. These practices may be the balance you are looking for:

  • Have your developers create the automated tests for the code they write. Now you don't need as many testers for your code, and you can continuously test your code.

    Hire testers for the things that really need a face in front of the screen. This is likely a different skill set than your developers will have.

  • Have the developers of a feature fix its bugs. Now you don't need a bunch of bug-fixers. You may want to have someone else review the bug. That should be part of your normal practice anyway. You will still need to parcel out bugs created by developers that have left the organization or project. These should mostly be bugs that have made it into a production release, and may require significant skill to fix.

    Continuously improve your process. Track your bugs so you don't have as many and they get better contained. Your new hires may be some of your better resources for process improvement. They will arrive with fresh ideas, and an outsiders view of the current processes. Use that for all its worth.

share|improve this answer
+1 for pointing out the flaw in hiring people to do something, and having them spend the first year doing something else. However, as a tester, I'd say you're wrong about "Hire testers for the things that really need a face in front of the screen". Yes, that is a small part of what I do. But I don't always need my face in front of a screen to find issues - in fact, I often find a lot of issues before the code is even written. You are right that it's a different skill set. The point of having me or my tester colleagues on a team is because we practice looking at things differently. – testerab Mar 12 '11 at 13:56
@testerab: I fully agree with your comments. I realize being a face in front of the screen is a small part of what a tester does. However, it is clearly something that can't be automated. The testers perspective is important in ensuring the requirements are correct and complete. – BillThor Mar 12 '11 at 14:33

There are two schools of thought here that I have come across.

Both positions largely wastes of everyone's time.

There's an assumption here that somehow -- magically -- testing or bug-fixing are easy and boring jobs.

  • It's a good entry-point because it's easy.

  • It's a bad entry-point because it's boring.

Both positions are based on demonstrably false assumptions. It's neither easy nor boring.

Unless you make the position easy and boring by dumbing down the workflow.

Is there value in having new developers (graduates) start as testers / bug-fixers?

Yes. If you need testers and bug-fixers.

If you don't need testers or bug-fixers, they should start doing something you need to have done.

Here's the point.

If you have a position called "tester" -- someone who doesn't write unit tests and then write code -- you have a really poorly-designed organization. Get rid of that position. Programmers should be writing unit tests.

Other folks doing integration tests are often doing programming to create test harnesses, test scaffolding and test frameworks. As well as test cases. This is not a junior or entry-level position.

If you have a position called "bug fixer" -- I have trouble imagining what this person is doing. Do they code? If so, they have to write unit tests for their code and they're just as responsible for a deliverable as any other developer, right? Then they're a developer, right?

The idea of a "bug fixer" usually means that they have really carefully written specifications. Why not just do pair programming with the specification writer and save everyone a lot of time?

Rather than have an experienced person write the spec and review the spec and review the work done by the bug-fixer, just pair them up and make the fix.

"But", you say, "the experienced person does other things than write specifications for bug fixers". Really? First, validate that. It's rarely true. But second, when it is true, the pair programming will teach the bug fixer even more about the code base.

share|improve this answer
Your answer makes very optimistic assumptions about the ubiquity of automated tests. – user281377 Mar 12 '11 at 13:24
I disagree. No matter how good your automated tests are, you still need testers who manually go over the program. Especially for GUI related programs. – Carra Mar 12 '11 at 14:37
I think you're confusing creating programmatic test cases (like junit programming) with someone who tests by using the application. In my organization when you're asked to be a tester you are not writing the code, you using the application to test functionality. Why? You get to know the application through hands on experience before you're allowed to write code for it. – jmq Mar 12 '11 at 15:09
newcomers can fix layout-errors (ok butten must be moved 3 px right to allign with ...) or corect typos, can manualy try to find bugs using the gui but most likely cannot fix logical errors. the extra value of manualy testing the gui is that they learn the business perspective of an application – k3b Mar 12 '11 at 16:53
Testers might write programmatic test cases, and test manually. I would expect testers to be able to bridge both sides - looking at the app from the technical and the business perspective - in order to create really challenging tests. In my organisation, there is a distinct separate role for "tester" - different training, different mindset, different (but overlapping in some places) skillset. – testerab Mar 13 '11 at 11:47

I think this depends on the type of project, therefore there should NOT be a 'company wide' rule on how new hires start.

There are project that already have good automated tests and good development practices. On these projects there might only be a couple of bugs and those bugs are extremely hard to fix. In this case a new hire will completely drown in the work and will need an expert eye to fix the problem anyways.

Another problem with new hires being 'debuggers' is that a new hire has no idea where to start. When you are an established team member, YOU can usually localize the bug. A new hire does not have the context and have no idea where to start. In this case they will come to you for advice. What will you say? 'Oh its a Hibernate issue'. The new hire will say 'Hibernate?'. And you are already screwed. You cannot explain how everything fits together to a new hire. It's too much.

I think a better approach is to break off reasonably easy tasks and let new hires work on it. Each iteration you can give them different types of work, so they get the feel of the overall picture. Piece by piece you can build their confidence while explaining how the team does things. Piece by piece you build up their context about your project. This will have a lot less burden on the team member who is helping the new hire as well. You only have to teach them a little at a time.

This is how I started and it worked out well for me.

My 2c.

share|improve this answer

I tend to give newbies real tasks that does not require good knowledge of the system, so that they start hands-on. Another great way to introduce the system to the new developers is to make them do refactoring of your code!

share|improve this answer

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