As Matt Heusser sees it, the "war on work" that exchanged centuries of craftsmanship for being a small part of the big machine has itself been replaced in the past decade--at least in the software industry--with a revitalization of the craftsperson. What's more, he sees the realization of the "boutique developer" as a promising sign for the possibility of boutique testers.
Generations ago, craftspeople lived in the center of town, owned the building, and lived upstairs. They generally owned their own tools. Independent craft was such a part of their being that when it came time to pick up last names, they looked to their crafts-Cooper, Miller, Smith, Carpenter, etc.
A few hundred years later, when it was time for young Matt Heusser to start his career, that independent spark was all but gone-at least from software development. Oh, it still existed in some of the trades; you still can find an independent plumber. But, the American people had begun to declare war on work. As Mike Rowe puts it, we relegated that plumber in our minds to a 300-pound slob "with his [rear end] hanging out."
At the time (1997), it was very hard to be an independent software contractor. To distribute software you needed to print CDs, stuff them in boxes, and market then to large retail stores. The few people who were online were using dialup modems and wouldn't stand to download Win32 software. Building a Web presence was expensive; you needed to build a server farm, rent a T1 connection, and hire an army of developers, DBAs, system administrators, analysts, and testers. The few craftsmen making shareware and open source software were hobbyists-it wasn't expected to pay your rent. Why, even the methodologies popular at the time pushed you toward an assembly line of specialists.
While you could work as an independent contractor for companies, the idea of making things for yourself just wasn't part of the scene. Aldous Huxley's brave new world had come.
Computers are faster and cheaper. Now I can rent a box that will run PHP, is stuck inside a collocation facility, and is connected to the Internet for a hundred dollars a month. A majority of Americans have a high-speed Internet connection, and the Web has evolved nearly to match the functionality of the traditional Win32 environment. Free programming tools at higher and higher levels of abstraction, combined with methods (like XP) that focus on the generalist, allow the programmer to be programmer, developer, and system administrator at the same time.
All of a sudden, it makes sense to hire one guy (or maybe two) to write your Web site. Custom software development-and the craftsman-is back, baby, and back big time. The Ruby on Rails movement alone is full of small companies like 8th Light, Obtiva, and Atomic Object that have generalists making custom software.
I believe this is a really good thing.
But, what about the tester? Why, the software tester doesn't make anything. The tester is just part of some assembly line. That's a job that should just go away as we all become generalists, right? Gosh, I hope not. Sure, I've done development and analysis, and I've been a generalist responsible for everything. It's just that I enjoy testing. It's what I want to do.
So, if we have found a space for the boutique developer, can we find a place for a boutique tester? And, if yes, what would that look like?
I believe the answer to those questions is still up for discussion. To compete as a craftsperson, the tester role will have to evolve. He'll have to be smarter, sharper, and faster. He'll have to explain testing services to people who are skeptical of such services and believe they can do it themselves. In the words of Harry Harrison, in his novel The Stainless-steel Rat:
It was easier in the old days, of course, and society had more rats when the rules were looser, just as old wooden buildings have more rats than concrete buildings. But there are rats in the building now as well. Now that society is all ferrocrete and stainless steel there are fewer gaps in the joints. It takes a very smart rat indeed to find these openings. Only a stainless steel rat can be at home in this environment.
So what would a "stainless steel," boutique tester look like?
Imagine a development project that is outsourced to one of these boutique development shops. The programming budget is in the area of at least $50,000 and also has an outside design firm and internal costs. The total cost of project is probably in the $100,000 range.
Now, imagine the project is halfway through. The customer begins to be concerned with functionality. This is a make-or-break project, the customer explains. Perhaps the customer is a media outlet, like NBC or the BBC. It starts to talk about how the project "has to work" and legal implications. The development staff-a bunch of craftspeople-start to hear about contracts, clauses, and SLAs.
What's does the CEO of a shop with seven employees do now?
Hopefully, the owner will tell the customer that he intends to hire a tester-someone independent, who can make an assessment of the software. This tester will be dropped in to mitigate risk for two to five percent of the development cost. At $5,000 for a $100,000 project, this is a simple insurance policy.
This means the tester isn't going to moan that he was not involved early or insist on detailed documentation-he will have to contribute actively to the project right now.
Perhaps, over time, this service becomes so valuable that the development shop plans on using a tester as part of its risk-management strategy in general. Sure, the developers will do test-driven development and perhaps even automate story tests for the customer. The final layer of testing-the pièce de résistance-is the air-dropped tester.
With a few shops to work with, it's possible that tester could create a boutique test consultancy. There are already a few people who do this sort of thing-stainless steel testers in the maze.
Keep in mind that testing as a profession is not going anywhere. There will be plenty of testing roles in larger organizations in the years to come. But is a testing boutique possible? I certainly believe so. Will it be a good thing? And, what will it take for us to get there? Alan Kay, the man generally credited with object-oriented programming, once said that the best way to predict the future is to invent it. Let's go prove him right.