wrote an interesting blog about arguments related to the programmer vs tester who is better at testing and why (Programmers make Excellent Testers - Arguments and Counter Arguments). The idea comes up now and then in development circles, and whether you are a programmer, a developer, a manager, or a student of Software Development, sooner or later a question like this may enter the picture.
Shrini does a pretty good job of illustrating some of the reasons why at any given snap shot moment, why a programmer or tester may be better for a particular task of testing. I've hard some of these arguments before, and I find that the context of the situation, and sometimes the budget of the team often dictate just how much a programmer or tester is asked to do. One thing that I find interesting, is why things end up being the way they are. Each of us if you will may start off as a blank slate at birth, and we learn many, many different tasks. When we enter the Software field, we even at that point have different ideas, philosophies and hopes and dreams of what a life and career in software might be. Whether that is to be an Engineer, Programmer, Designer, Architect, Manager, Lead, Tester, each of us started off with an idea of what we might get from this rewarding field. How many of us though stay on the path we initially pointed our ships bow of learning and experiences towards? I'm not sure a survey could even give a good idea for why people choose one career path from another. People are as varied and individual as grains of sand or rocks on any given beach.
So when I reflect back on my career in the software profession. I can't help feel the irony to have basically come full circle, and reminded of at least one of Shrini's points. When I Started, all I wanted to do was write Code. I had aspirations of being a "Software Engineer" and thought I had a pretty good idea of what that entailed. Though I lacked experience I had not thought beyond that little view point. So when it came time to start my first professional job, it didn't take long before the ideal, and reality clashed.
Learning is often seen as climbing a pyramid between four points. Along one Axis is technology and the closer to it the more experienced with technology, particularly specific technological contexts represents your learning and experience. At the other end of that Axis is the Second point of our Pyramid, that of working with people. The closer you get to it, the better you work with people, but perhaps you end up spending more time with people then the technology. Then off on the opposing axes would lie the other two points, in one direction is that of being more of a specialist. The closer to it, the better and more specialized you are in your context. You might call someone at that point an 'expert' of sorts, while at the other end is the generalist. They may be better at one thing than another, but their broad base of experience helps give them a larger context to evaluate their problem set.
As you move from the Technologist point of extreme towards the specialist you are really moving around the base of the Pyramid. Or if you move to generalize you may be moving back the other way along that face. However, since Computer and technological problems are inevitably people problems, noone stays on the base very long, they begin to grow upward, and toward being able to deal with people.
I recall being taught taught this 'myth' that programmers code, and testers test, and neither the twain shall meet. Thus fresh out of college there was this propensity among some of us, myself included to see testing as beneath them and not worth their time. This may have been vocalized by professors, or it may simply have been a matter that Testing was not a focal point of CS or Engineering coursework in college. The absence of a tester point of view from my Academic experience, clearly colored my early thinking about software.
I had a desire to crank out quality code, usable code, and I saw Software Engineering as a tool to get there. Just one problem. In the first shop I worked, Software Engineering principles were not necessarily being practiced. Even if they had been, I'm not convinced it would have solved the host of problems I encountered early in my time there. I came to realize very quickly that programming alone didn't insure the code was ready and met the customer expectations. Heck sometimes even other programmers don't meet other programmers expectations. Now almost 8 years later, I'm a full time tester, and now I see the other end of the equation, where some developers seem to see the majority of testing related tasks as 'not their job' or beneath their position or station.
I'm sure, I am not alone in seeing this, and I find it both sad, but in some ways understandable. After all in the technical realm you have generalists and you have specialists, to be good at one thing requires many hours of study and honing of that skill, often at the expense of others. Thinking back to that Pyramid, and admittedly, this is a very rough model or metaphor in need of tweaking and polishing, We may walk around a level of that Pyramid closer to one skill or another, We may move up it at an angle as we learn multiple skills practically at the same time, and sometimes we may move straight up.
I see the technical Specialists close on the face between the top of the Pyramid (the metaphorical pinnacle of learning success), and the Specialist and Technology points. The more specialized the developer, the closer to the specialist point they may be, and likely further up the pyramid to its zenith. For generalists, the same could be said between the Technology and generalist point to the peak. The more a person pours into one technology or into technology in particular the less time they've spent gaining other experiences. So it should come as little surprise when a twenty or thirty year experienced developer who has poured his life into coding has gotten so far away from knowledge about testing as to see it as a foreign country.
Even among programmers there are generalists and specialists in particular ideas or platforms, and each type of developer brings their own unique viewpoint to the problem at hand. What does that have to do with testing? Well we have something a bit similar do we not? We have people who focus on particular schools of thought, we have people who pour everything into automation, or pour everything into exploratory style testing. We even have some who are trying to learn as much as they can from every category, not knowing what tool they'll need next.
Now Imagine that there were two more points, a high and a low along the Z Axis the top would be Programmer and the bottom Tester. I can see from adding those points, and removing the metaphorical pinnacle and replacing it with a point for programming and testing. A person who is a good programmer and continues on that path, may learn at the expense of learning things related to testing. Just like a programmer who chooses to learn more about testing, will have less time to focus on the craft of programming. Each of us then may move upward or downward toward being more programmer or tester. Forward or backward at being more involved in the technology vs the people, or more a specialist in one area vs a Generalist in others.
So when I look at the tree of development with Development as the grand daddy of all the other nodes, and programming, and testing each on separate branches, I can't help see that there are so many varieties of testers and developers out there. Making each of us unique, or different as our experienced build upon one another. The real question I think we should be asking, is where do we fit in these areas. Are we more technical or more people oriented? Are we more specialists or generalists? More programmer or more tester?
So who is better? I'm not sure the question matters. I think the context of program budgets, team size, and backgrounds often weigh into who does what, and as a team on a project we must each do what we feel we can do that will help the project effectively. Maybe that Senior level developer with twenty years experience would be wasting his time testing, its not his strength, or area of study, so a specialist tester would be better. However, I would hesitate to ever rule out a particular individual from testing or other development tasks simply because of lack of experience. The software profession, like so many is one where dedication to life long learning is paramount. So we should bear that in mind as we forge ahead, no matter which direction we point our bow of learning to on the next course we may set.
