In the corner of SD devoted to testing (as an activity separate from the unit, system, or integration testing performed by developers themselves), is there room for separate (or sub-) guilds for Software Testers?

Given the absence of software testing as a standard degree at universities (for the most part) here in the US, and the varying opinions around the value of the various certifications available, in some ways testing has even more of the learn-by-doing and learn-from-others quality than the coding portion of software development. I know I’ve learned a great deal working with teammates, as well as reading the works of Masters and Grand Masters in the field. (Hm, reading books: an indirect form of guild participation not available in medieval times. Does it still count?) All of this causes the Guild concept to resonate for me.

Bret Pettichord created an interesting framework with which to evaluate different schools of software testing (www.io.com/~wazmo/papers/four_schools.pdf). In it, he describes the:

– Analytic School
– Standard School
– Quality School
– Context-Driven School
– Agile Schools

There’s definitely some overlap here with the guilds you list above, but I would nominate these as a starting point for testing-specific guilds.

Rick
Acolyte of the Context Driven Guild

You make good points about medieval guilds. I think the guilds of the software development world are intellectual institutions rather than real ones, but they may still have some of the same problems.

Also, the wikipedia definition of science doesn’t correlate to what I know of software development. Software development isn’t about collecting data about reality and modeling in a way that helps us understand it. It’s about solving problems with abstract software constructs that may or may not have any correlation to objects in the physical world.

“Being a professor” is also a trade, one that’s taught (if you’re lucky) through a master-apprentice relationship with your graduate advisor.

Generally, I think a profession is just a trade with legal muscle behind it. Does that mean hairdressers are professionals since (in Illinois, at least) they have to be licensed? I’d say yes. If you say no, I’ll amend my rule of thumb: a profession is a trade with legal muscle behind it and enough widely-shared cultural respect. Or, maybe: a legally-backed trade that deals with high-risk matters that make people feel helpless (sickness, legal jeopardy, etc.)

One thing to remember about guilds: a big part of their purpose was to restrict competition from people not in the guild. Also, I think I remember, competition from people within the guild by establishing a “just price” for guildsmen’s work. I also think I remember that they were not exactly boosters of innovation.

Maybe it’s silly to get petty about semantics, so I don’t want to labor this point to much, but I think software development is a trade, just like masonry is a trade. There may or may not be physical laws that govern “good” software, but you don’t necessarily need to understand those laws in order to be reasonably competent. Instead, you need to be skilled at the practices of your trade, regardless of your grasp for its theory.

People built cathedrals without the law of gravity or an understanding of the chemistry of cement. Developers routinely write decent software without understanding transistors, binary, bytecode, etc. A firm foundation in the basic laws of software development is not necessary to build software.

That’s what I think makes it a trade. If you are lucky enough to be mentored by an expert tradesman so that his or her practices can be imprinted upon you and creative/intelligent enough to add to them, you can do well even if you never crack a patterns book.

Some people may be offended by my view that software development is a trade. So is working on cars, building houses, etc. Lawyering, doctoring, and managing are not trades, and some readers may resent not being lumped in with professionals.

I’m not bothered by it. I think understanding our business as a trade makes it a lot easier to understand how to get better. Practice. Practice. Learning. Practice. Example. Practice.

For a book that has a simliar theme, try Pete McBreen’s Software Craftmanship: The New Imparative.

http://www.amazon.co.uk/Software-Craftsmanship-Imperative-Pete-McBreen/dp/0201733862

Sure, a book could help – Bob Martin’s Clean Code or Kent Beck’s Implementation Patterns are both attempts at this – but you could still give the same requirement to five different devs and get five completely different, yet correct-enough, answers.

Corporate America likes defined process. But try selling your defined process to a golfer; he’s say you’re on crack, get your clubs and let’s play and learned from that playing.