Is a programmer supposed to be self-sufficient?

Question

At my current workplace, we don't have any testers, the rationale for that from the management being: "if we had testers, you wouldn't test your own code at all". This kind of thinking seems to be detrimental to product quality, as while I do test my own code, there are a lot of things that I will miss just for the fact that I know the system inside out and don't know how to use it "wrong". Black box testing doesn't really work as I subconsciously avoid the pitfalls that a dedicated tester would fall into. A lot of my time goes into fixing bugs that have slid into production code and found by the end user.

The system in question is large but is developed solely by me. This has also caused some managemental duties to fall on my lap, such as defining schedules and working on specifications.

Should these kind of tasks be my responsibility? I see myself strictly as a programmer and nothing else. And if these are my responsibility, to what extent? When is a project so large that it requires testers? Should a programmer have to refine the specification, worry about management of the project or even provide customer support?

Note

Some might have got the impression that I am against widening my responsibilities – that is not the case, I'm eager to get a role that involves more management duties, but currently it is not in my job description. Until I'm officially employed as such or the additional duties start showing in my paycheck, I'm going to think of myself as 'just' a programmer. Unfortunately, as a junior developer, shifting to managerial duties is not going to happen very soon.

Excellent answers so far, keep them coming if you have something to add or personal experiences to share!

Answer 1

You do have testers. Only, you call them "end users." This is detrimental for all the reasons you describe; no matter how conscientious a coder you are, you're simply never going to be able to do a good enough job overcoming your own preconceptions about how the code is "supposed" to be used for you to find all the ways it can screw up.

You need to re-open this issue with management. By this point, it sounds like you have some hard data to back your case; the current hands-off approach to Quality Assurance both wastes your time and compromises your users' experience. You need to be careful in how you present this so that it's clear this is a structural problem and not a case of "You just suck at testing," but it sounds like a discussion that needs to happen.

It sounds like you're coming to a crossroads with this employer. If you're intent on remaining a programmer and nothing else, you may need to start pushing back and requesting that they start getting you the help you need to take some of the managerial tasks off your plate, either by bringing in somebody new or by expanding an existing co-worker's responsibilities. ("This isn't what you hired me for, and these tasks aren't going away. Time I spend doing this stuff badly is time I'm not spending on what I'm good at.") But that may or may not be realistic. Do you think you could handle moving into to a more managerial role if they gave you the resources and authority you'd need to get the job done right?

As to how big does a project need to be before it needs testers, I'm not sure how to precisely define that line, but I definitely think you've crossed it. You're spending more time than you'd like fixing bug reports coming in from actual users; to me that says it's time to spend more effort stopping the bugs from getting to the users in the first place.

Answer 2

Yes. If you have to, you should be able to test your code. (I'm not talking unit tests, but acceptance tests and such.)

No. Testers are better at testing than you are. And as you point out, just like proofreading, it's very hard to spot your own mistakes. Having extra eyeballs will have a major (good) impact on your program quality.

You have a lot of other questions. I'll only answer one:

Should a programmer have to refine the specification?

Yes! You have to implement the specification, so you have to ensure that the specification is actually implementable. Also, as a programmer - trained in clear thinking, precision and such - you can help people discover what actually needs to be done, and weed out ambiguous or logically flawed requirements.

Answer 3

What they are saying and reality are probably two different things. Most likely the rationale is:
"Why do I have to pay a tester's salary when I can just make the programmer do double duty?"

Of course, they aren't going to say that and will make up all sorts of excuses they think are reasonable. I can think of several rebuttals to their point, but honestly they aren't going to help. I've seen this battle over and over and they will just shift their approach whenever you debunk their current reasoning. Eventually they will give up and just direct you to do it anyway and you will be labeled a complainer.

The best approach I can think of is to address it not from a quality point of view, which management never seems to value until there are problems, but from a cost point of view. Testers are, or at least are perceived as, less expensive than programmers. Remind them that by having you do double duty they are paying a higher paid resource (programmer) to do the work that could be accomplished by a less expensive resource (tester). Thus they are not maximizing the value they are extracting from your programming skill.

This approach does have the downside of falling apart if you are salaried and they have no compunctions about just making you work more unpaid overtime, but it is worth a shot.

Answer 4

The system in question is large but is developed solely by me. This has also caused some managerial duties to fall on my lap, such as defining schedules and working on specifications.

Fair enough.

Should these kind of tasks be my responsibility?

That is ultimately up to your management to decide.

I see myself strictly as a programmer and nothing else.

Perhaps you are in the wrong job then. A lot of people like being given the extra responsibility.

And if these are my responsibility, to what extent?

If management say so, yes.

When is a project so large that it requires testers?

When there is too much other work that the developers have to do. At that point, management need to decide whether they want to employ a dedicated tester, or take the risk of skimping on testing. (Ultimately, developers can only do so much.)

There are definite advantages in having dedicated testers, but there are downsides as well ... in addition to the cost of employing extra staff.

Should a programmer have to refine the specification,

If necessary, yes. In fact, if the specification needs refining and there's nobody else working on it, then the failure to do this is likely to cause the project to fail.

worry about management of the project

If necessary, yes.

or even provide customer support?

If necessary, yes.

It sound to me like you are overworked, and reacting to the pressure. This is a problem. But taking the position that it is "not your job to do X, Y, Z" is not going to help. A better plan is to make it clear that there is only so much that you can do, and point out that this is likely to cause deadlines to be missed, quality to slip, poor customer support and so on. But do your best anyway ... without damaging your health, relationships, etc in the process.

Answer 5

We have testers. I would not want to work without them. Although I do write unit tests (using TDD), and automated integration test for all my code, testers still have a very valuable function.

1. They are highly skilled, and have different skills to programmers.
   1. They have lots of experience and knowledge of how to do QA testing, and how to verify that the code that has been produced really matches both the user's expectation and the actual behavior of the users.
   2. They have experienced many bugs, and are very good at thinking of situations that could break the software.
   3. They tend to be cynical and systematic. I have observed that programmers are often much more optimistic.
2. They provide valuable early feedback on usability. For instance, when creating a REST API recently, areas which the QA testers could not understand easily were a good indication of areas that the user would also be unhappy with.
3. They test on the actual environment, in fact many configurations of the real hardware, OS, etc.
4. They know how to build large scale, realistic, test beds and do performance, load and stress testing
5. They are focused on preventing bad releases from getting out. Programmers tend to focus on getting the code released. Its almost like, a programmer will release the code by default, but a QA tester will need a reason to release it (it has been shown to work!)

Answer 6

First of all, testing, or better said Quality Assurance, is not only about testing the funcionality by clicking through the application. Quality Assurance is about processes. Not only to test the application to find the errors, also they have to prevent developers from doing them.

1. Product specification + use cases
   Even if everybody know (or think they do) what the product functionality is, it must be written down. You can't test an application without a clear specification. A specification defines what is correct behavior and what is a bug.
2. Unit tests, Integration tests
   Tests of the internals which are difficult to test through the UI, exceptional application states. This is a must for every bigger system. Both types of tests have also another interesting property - they force you to go through every part of the code again and you'll realize bugs/architecture problems you never saw before.
3. Code Quality & Coding Standards
   One of the tasks QA should do is measuring code complexity. Low complexity code reduces the possibility of errors (preventing bugs).
4. Code reviews
   When a project reaches a given size, or it is used by a lot of users, code reviews are a must. Another programmer always finds code problems/bugs you had missed. Programmer are sometimes blind to obvious bugs in their own code.
5. Documentation
   Document your code and its architecture, it will help you realize possible flaws (my own experience).
6. Testers
   Tester is not a monkey who just clicks through the UI. A tester takes the specification & use cases and creates test cases. Then he/she test them one by one. If a bug is reported by end users, a test case must be added for that.

A programmer should never create the specification (1). You are not there to decide the funcionality. Usually they have to speak to the end users, create graphic designs etc. It's a time consuming task. If a programmer decides the funcionality, usually it ends up with "it's okey but could you change everything in this window by tomorrow?" "this is not what I wanted" "it works but it's hard to use" "it's missing the only functionality we really needed".

What a programmer can achieve is 2, 3 and 5.

You need another programmer for 4. Any company with a big IT project and only one developer who knows the system steps on a very dangerous ground.

If you don't have enough time, don't ever bother to create test cases (5). A dedicated person is usually needed since it takes a lot of time. Without test cases, testing is just a joke.

Answer 7

"if we had testers, you wouldn't test your own code at all"

"If your car had a seat-belt you would crash it all the time!"

Should these kind of tasks be my responsibility? [...] And if these are my responsibility, to what extent?

The answer to that is "it depends". From what I understand,your employers see you as the "one-man-IT-department". If that is the case, yes, they are (your responsibility). If you have responsibilities that you absolutely hate and wish to avoid, look for a position within a company with a larger IT department.

When is a project so large that it requires testers?

That's not (quite) a correct question to ask. You're better of asking "when is the quality of the product/image of the company so important that it require testers?"

Should a programmer have to refine the specification, [...]

Yes, definitely. Most times, there is a large discrepancy between what a developer/implementer needs and what the clients provide [as specifications].

Many times it is up to you to find gray/unspecified areas and ask the right questions, to notice and point out technically impossible or contradicting requirements and so on (especially if you are the only developer).

[...] worry about management of the project or even provide customer support?

That depends on the responsibilities you accepted when you took the position. For example, some positions require you to address customers directly. All other things being equal, I would attempt to avoid such positions (but it's up to you, and you may not have many job choices).