I had an interesting conversation with Doc Norton this morning. And it got me to thinking…

You know what an 800 number is. Some people call them “toll free”. The Telephone company call them WATS lines. Wide Area Telephone Service.

In 1976 I took a job at a company in the suburbs of Chicago. Teradyne Central it was called. We made test equipment for the telephone company. Our product was named 4-Tel. It tested every telephone line, in a telephone service area, every night. A telephone service area could have 100,000 lines or more.

A 4-Tel system could have as many as 21 terminals tied to it. Each terminal could be used by a tester in the service area to test a telephone line anywhere in that service area. The test would detect and diagnose any problems on those lines; and could determine whether the problem was in the central office, in the lines themselves, or in the customer’s telephone. This was important because those three diagnoses were handled by different crafts. Dispatching the right craft to fix the problem saved a lot of money.

4-Tel had many other cool features. It was a rich product with a lot of use cases. And it was installed all over the United States.

When one of our customers had a problem, they would call an 800 number. This would automatically get routed to one of our two WATS lines. If it was normal business hours, our receptionist would answer the WATS line. Once she had ascertained that this was a customer service call, she would put the caller on hold, and then speak over our internal public address system:

Would someone from software please pick up WATS line 54.

If it was after hours, we in the lab would simply hear the WATS line ring.

No mater what time it was, we answered.

There were about a dozen of us on the programming staff. We’d look up at the nearest phone and see the blinking light labeled “54”. Whoever was closest to a phone would pick up that line. If it was me, I’d say:

Teradyne Central Software: This is Bob Martin

And then we’d proceed to listen to the issue, and we’d advise the customer what to do.

Sometimes, of course, it was cockpit error, which we could quickly correct. Sometimes it was a known flaw in our system for which we could communicate a workaround. And sometimes it was a new defect or problem that we had to diagnose on the spot.

One way or another we stayed on the phone with the customer until the problem was resolved.

Responsible Engineers.

You might be asking yourself why we didn’t have a customer service department handling those calls; and entering defects into a defect tracking system. The answer to that is simple. We felt responsible for the system. We wanted to know what our customers were experiencing. We didn’t want a layer of people insulating us from the problems that we were creating in the field.

We had a term at Teradyne: Responsible Engineer. That was the subhead under the signature line on every Engineering Change Order. We signed for the changes we made. We were the Responsible Engineers.

That term had meaning to us. We felt responsible. And so we did not want anything insulating us from the real world of our customer’s plight.

At Teradyne, we did our own QA. We did our own devops. We did our own customer service. And we frequently traveled to customer sites to work with the Field Service engineers.

In fact, it was common practice for each software developer to spend a day or two riding along with a telephone repairman; just so we could understand what these guys were up against, and how they really used our system.

Insulation

Modern software development teams are often highly insulated. They live in a world free from the distractions of customers and their “petty” problems. There are whole groups of people who serve to insulate developers from the real world. Customer Service. Q/A. Devops. You name it. And why do these groups exist? They exist because each of these are areas where software developers have failed so badly at that companies have had to defend themselves by creating whole new departments and management structures.

I think that’s a shame. How can you be a software craftsman if you don’t communicate with your real customer? How can you be a software craftsman if you don’t directly experience the nightmares you are creating for devops? How can you be a software craftsman if you leave all your bugs for QA to find?

Software Craftsmanship

It seems to me that a software craftsman is a Responsible Engineer. A Software Craftsman should never be insulated from the real world of the customer, of devops, of QA, or of anything else. The responsibilities of a team of software craftsmen should include QA; should include devops; should include customer service. And every member of that team should be able to cover for every other member.

There’s nothing wrong with specialization. There is a lot wrong with insulation.