|
Why programmers should do their own support
From the "Tale of J. Random Newbie"
http://www.faqs.org/docs/artu/ch16s01.html
" Unless Newbie is very, very lucky, he is not going to be able to get library bugs fixed within the lifetime of his project. In his saner moments, he may realize that the working code in the libraries doesn't draw his attention the way the bugs and omissions do. He'd love to sit down for a clarifying chat with the component developers; he suspects they can't be the idiots their code sometimes suggests, just programmers like him working within a system that frustrates their attempts to do the right thing. But he can't even find out who they are — and if he could, the software vendor they work for probably wouldn't let them talk to him."
This is a result of programmers not doing their own support. Where I work, we're a small shop of 8 or so programmers, everone does support for the code they wrote. If you email us, or phone us, you're gonna talk to the guy or gal that wrote the code.
When someone phones or emails to complain about a bug, or get more information because the docs are sketchy then the person who gets the call is the person who can actually do something about it, and not just sympathize. Sure there are times when it seems that "all I do is support" but instead of hiring some other guy to field the support (leaving me to write "real" code) I get to do all the support myself. Nothing motivates me more than this to get bug fixes done (and released) and docs improved etc.
When support drops off, _then_ I can turn my attention to adding more "real code".
Bruce Johnson
Tuesday, December 16, 2003
"When support drops off, _then_ I can turn my attention to adding more "real code"."
Great code. You might also add "And I've fully documented all my code"
Mike
Tuesday, December 16, 2003
I meant great quote
Mike
Tuesday, December 16, 2003
There is one thing I'd try and force in this case, as you said the documentation is often not so great, what if this person leaves?
You need to let other people do support from time to time, even more basic support, letting people support parts of the application that interface with your code is easier to give at first, since they at least have an idea of how it works.
fw
Tuesday, December 16, 2003
Steve Mconnell refers to this as "EATING YOUR OWN DOGFOOD" in his book CODE COMPLETE.
(He may actually be just quoting Microsoft's C++ developers. They wrote each new version of C++ in the previous version, thus "eating thier own dogfood").
Entrepreneur
Tuesday, December 16, 2003
Depends on the users: how many and what sort.
Some projects I have been involved with have so many users that you would never get any new code done.
Some users will just keep asking for "bug fixes" that are really requests for heavily customised code. Those users will never stop making requests.
Andy Jones
Tuesday, December 16, 2003
Also, if you have lots of idiot users, they will ask a lot of stupid questions.
I know - you will say that there are no idiot users, but I know from personal experience that there are a lot of idiots out there.
Many users are intelligent, and many users are idiotic.
For my shareware app, I get lots of requests of support from users in the US, UK, France (English and French are the two languages we offer support for) who don't know how to write their own languages:
- many bad grammar errors
- poor choice of words even when writing about non-technical subjects
- partial and even complete lack of basic logic
- I can hardly understand what they write
X
Tuesday, December 16, 2003
Documentation can suffer with this set up because as long as the original authors are around it doesn't seem necessary.
I've seen this scheme work really well, but then fall apart when another programmer leaves. This was especially bad during the bubble because everybody was changing jobs. Whole teams could be replaced within a few months.
Mconnell encourages self documenting code, which is always more reliable than maintaining seperate documents, and totally agree with him.
I think the best approach is to have a tight team who support each others code.
This way the person supporting the code has the technical abilities and has easy access to the author. It is also means that knowledge of the code is spread around.
The supporter can also be given the task of updating/creating the relevant documentation.
In terms of documentation I think a Wiki for the high level overview with all of the details in the form of comments, ideally with Javadoc or equivalent.
Ged Byrne
Tuesday, December 16, 2003
We have this appoach at our company. When you call technical support, you talk to an engineer (hardware or software).
We have been told by many of our customers that we have far better tech support than any of our competitors. We're also better at finding and fixing problems. When a customer is calling with a problem, and engineer will recognize it as a design problem with a board, while a low-level technician will simply follow the script.
Obviously, this approach is very expensive in terms of engineering time. You need to pay an engineer $60K to answer the phones, instead of a tech that makes $30K. Plus the engineer needs to deal with the distractions.
We recently hired a technician to screen the really basic calls (did you plug it in?).
We also have the same approach for our marketing department.
Myron A. Semack
Tuesday, December 16, 2003
But then, considering how much a developer and a tech support person cost... it makes more sense for the former to concentrate on writing software, and the latter, on answering calls. That's why you can't talk to a developer directly in most companies. They're busy writing programs :-)
Frederic Faure
Tuesday, December 16, 2003
Myron: We also have the same approach for our marketing department.
What, you hired a tech to make sure marketing plugs things in properly? Sorry, couldn't resist. Hmm, has potential.
I suppose a few days support a month couldn't hurt. Heh, when the caller says 'who writes this crap' what are you going to say?
Nothing like getting in touch with reality, which is the issue.
As already mention, eat your own dogfood, ie become a USER. Go work in the call centre, you find many astoundingly crappy apps there. Then go back & fix them.
AJS
Tuesday, December 16, 2003
Cheap tech support isn't cheap; for a couple of years companies got away with Premium call lines where essentially the worse the service the more money the company got, but that cash cow started showing signs of drying up so everything goes off to India for a few years until the whole idea implodes.
You need a clued up tech guy to answer FAQ's, but you need to have a direct line to the developer for what needs fixing.
On another tack, Cooper pointed out that software was not aimed at the majority of users, the middlingly competent ones, because the developers only fielded the difficult calls from the technically savvy, and the marketing guys mainly dealt with people who had never used the software before.
Stephen Jones
Tuesday, December 16, 2003
I work for the Condor project, which is a university project, but we write production-quality software. It's a nice blend between research and production: in my position as a full-time staff member I work with graduate students doing cutting edge research, and I help write production-quality code that people use every day to get work done.
http://www.cs.wisc.edu/condor/
We believe in eating our own dog food, and we make it happen in two ways.
1) Each week, one of the full-time staff developers is assigned to be the contact for incoming support requests. This person does not necessarily answer all of the questions, but he answers as many as he can and passes off the rest of the questions to the appropriate developers. Each person does support and learns more about Condor. This is incredibly useful to us. It does encourage us to write better code and do better documentation. And I know that I have frequently edited the manual or committed a bug fix as a direct result of handling the support.
2) We use Condor on a daily basis, both in-house and through collaborations with other people. This is a mixed bag. On one hand, we learn from the problems that we have in the product and improve it, which is fantastic. On the other hand, we think like programmers, not like users, so it isn't a 100% solution. We need to rely on feedback from our users.
One thing that we do is when we hire a new staff member is to ask them to learn to use Condor and read the manual. Then suggest any improvements that they can. While they still think like programmers, at least they are novices to our software.
Alain Roy
Tuesday, December 16, 2003
There has to be an "intelligent" procedure for escalating support calls and I think that developers do need to be shielded from day to day support issues. I do not believe that most SW companies can afford the hit in productivity that results from programmers responding to support questions constantly. I worked with one place that mandated that programmers get involved in technical support on a regular basis - and it was hellish and chaotic.
The problem in the technology and tech services industries is the reverse: escalation is often reserved for large commercial accounts and absolutely no exceptions are made. An example: I tried to get an answer from a local (but conglomerate owned) ISP as to the availability of ISDN in my area and absolutely none of the heads down junior twinks and feebs that I spoke with even knew what ISDN was. And they absolutely, with religious zeal, refused to get me the access phone numbers so that I could make my own determination. It was as though providing concrete information was absolutely against company policy.
I'm pretty cynical about this issue. Most companies simply want your money and want you to disappear afterward without "burdening" them with any questions requiring real insight or expertise. It's certainly not exclusive to technology providers either. And it creates an opportunity for service oriented companies to thrive.
Bored Bystander
Tuesday, December 16, 2003
Senior engineering management is responsible for marketing and advertising in our company.
No one can sell a product better that the engineer who actually desgned it and knows how it works. We market our product to other engineers after all.
It keeps our advertising honest.
Of course, you need an engineer who can actually do a good job designing an ad, which is a rare find.
Myron A. Semack
Tuesday, December 16, 2003
I read that Microsoft used to charge product support costs to that product's P&L budget. This gave product management a stronger incentive to create less problematic products... because the cost of supporting buggy products would come back to bite them!
runtime
Tuesday, December 16, 2003
Entrepreneur said (quoting Code Complete) :
'They wrote each new version of C++ in the previous version, thus "eating thier own dogfood'
I think you mean they build the new version of VC++ with the new C++ compiler. Doesn't make much sense to dogfood the previous version...
Rick Childress
Tuesday, December 16, 2003
Dang, am I confused. What I read was the guy was suggesting that programmers support applications as if only programmers wrote applications. Where does this guy live? I've got levels of people before me and the multitude of end-users. I don't do the testing for the applications, testors do. Darn, if I were going to do the support then I'd gather the requirements as well. Heck, I'd do everything. Uber programmer. Hello .... real world means teams. Small worlds, different but I don't see a programmer doing much work when he has to jump when the phone rings. And who does the requirements gathering? I hope you do that as well. And you deliver before it passes testing? Or are you talking about evolution or change requests? I've worked at a small ISP where I had to handle support via phone and email and I've worked where I've had an office and no phone (only internal) and guess where I was more productive? Honestly.
Me
Tuesday, December 16, 2003
Re: (They wrote each new version of C++ in the previous version, thus "eating thier own dogfood").
As opposed to writing the previous version of C++ using the new version ;-)
RecursiveThought
Tuesday, December 16, 2003
but what about doing support, say, two days per release cycle. you lose the one day of programming, but learn a lot.
same with testing--doing it every once in a while forces your mind to learn about aspects of the product you normally don't think about, making you more rounded when you return to 'programmer' mode.
mb
Tuesday, December 16, 2003
Having programmers do the tech support for their apps is, IMO, a terrible idea. A phone that's constantly ringing is up at the top of the list of things that kill a programmer's productivity. Programmers do need some interaction with end-users to keep them grounded in the real world, but having them do tech support is a poor way to accomplish this goal. Having the programmers go on a few site visits every year to observe real users' workflows and discuss issues and having a clearly defined mechanism that ensures important support issues are addressed is, I think, a more efficient use of development resources.
This may not be as much of an issue right now given the current state of the economy, but having programmers do tech support also virtually guarantees that you will end up pissing off your most talented development staff and they will leave your company for a better work environment.
One other issue to think about: A development staff besieged by a heavy tech support workload will go into "fire-fighting mode" and will not hesitate to employ all sorts of quick and dirty kludgy hacks to solve immediate problems while maintaining good intentions of going back later to fix the problem correctly when they have time to do so. Unfortunately, the road to an impossibly complex, buggy mudball of code that nobody can understand or maintain properly is paved with such good intentions.
anon
Tuesday, December 16, 2003
And in other news, 50,000 years of progress was disregarded as the entire power grid was dismantled in order to liberate hundreds of thousands of miles of top grade copper wire for fishing line. Burning human dung warmed citizens now living closer to the ultimate source of energy.
Smart Posterior
Tuesday, December 16, 2003
Nobody is really suggesting programmers man the phones while coding. The idea is to make programmers aware that there really are users, not 'lusers', and that their problems may actually be your fault. (More likely sales & marketing, but that's another story.)
Programmer, meet clue stick.
Even the much-maligned car mechanic will come out of their hidey-hole to meet the users, especially if she has nice legs.
AJS
Tuesday, December 16, 2003
A couple of clarifications & answers...
Firstly I should point out our context. As I said we're a small development house. We develop mostly vertical market applications, but along the way we developed some interesting technology for the environment we use (Clarion) and so we sell that to. So our customers are a mix of developers (some good, some bad) and the regular "computer illiterate" end-user.
For the big complicated applications we make use of distributers and dealers to do front-line support. This takes care of the usual day-to-day questions, windows related stuff, that sort of thing. But the dealers can, and do, bump problems straight to the developer if they can't solve them.
Since we got into the tools market we now develop most of our new code, certainly all the exciting code, as "technology". Each product is made by 1 programmer, and they have complete control. From a team point of view we all meet once a week (and in smaller groups more often than that.) We have a particular "style" in the way we build the tools which means they all "work" in the same way. We get a fair bit of support on these tools, 99% of it via email.
While some companies are obsessed with productivity, we are concerned more with the quality of the offering. We primarily want happy customers. I'd rather have fewer "high quality" products than a whole range of stuff folks would rather avoid. And because we build applications as well we are continually using our own tools, and we are the toughest customers we have. Productivity for us is not measured in lines-of-code-written, but in the number of sales, and ultimately the size of the bonus at the end of the year.
We do have office support staff as well, to pretty up the docs (correct grammer etc), maintain web sites, process pre-sales (non technical) issues, do customer relations all those sorts of things.
>> Documentation can suffer with this set up because as long as the original authors are around it doesn't seem necessary.
I agree. The stuff we've developed for in-house use is not nearly as well documented as stuff we sell. Also some programmers just can't write. In that case we have a dedicated documentation guy to help out.
>> But then, considering how much a developer and a tech support person cost... it makes more sense for the former to concentrate on writing software, and the latter, on answering calls. That's why you can't talk to a developer directly in most companies. They're busy writing programs :-)
There's an implicit assumption here that support is a non-adjustable item. And to a point you're right. We don't have programmers explaining to folks how to install a printer. But product support, and especially technical support, can be reduced. The person who can reduce it is the person responsible for the product, and the person responsible for the docs.
One example happened recently. We released a new tool, and quiate a few folk snapped it up. After some months, and more than a few sales, we start to notice that developers are strugelling more than they should. Support is increasing. The developer is getting less and less time to develop. We analysed it and decided that our docs were to blame. Folks couldn't get the answers they were looking for in the docs (we pre-supposed too much background information.) Solution is to rewrite the docs. The programmer is currently doing that. Apart from bug fixes there's been a month of no-new-code. But at the end of it support will drop off, and for the next 5 years the product will be _better_ for it. Is she being productive or not?
>> Darn, if I were going to do the support then I'd gather the requirements as well.
yep, who better? The person programming needs to fully understand the big picture else how can they develop the program? The fewer people between the customer and the developer the better. Less chinese-telephone that way.
>> I don't see a programmer doing much work when he has to jump when the phone rings
Fortunately it's mostly email. The point is to reduce the need for the phone to ring. If the answer is "That's in the FAQ, Question 4" then the phone call is very short - AND the person will probably read the FAQ before phoning/emailing the next time. If not after 2 or 3 like this they certainly do. If the question is not in the FAQ then it's probably unusual enough for the developer to hear it. If it's not unusual then it _should_ be in the FAQ.
There seems to be a perception that the support phone is "constantly ringing". Now if you're Microsoft, or IBM then fine, I'm sure it is. But if you're a small shop with a customer base measured in thousands or less then you have to ask _why_ is it constantly ringing? (Hopefully it's folks looking to buy <g>). If it's constantly ringing because of support issues, then it's worth taking a long hard look at whether or not that can be reduced.
>> A development staff besieged by a heavy tech support workload will go into "fire-fighting mode" and will not hesitate to employ all sorts of quick and dirty kludgy hacks to solve immediate problems while maintaining good intentions of going back later to fix the problem correctly when they have time to do so.
This is often true early. But very quickly you discover that taking the time to fix it _right_ means few support calls later. If anything the developer is _more_ motivated to fix it right than hack it, because they know who will be picking up the pieces later.
>> having programmers do tech support also virtually guarantees that you will end up pissing off your most talented development staff and they will leave your company for a better work environment.
Actually for us it's been completely the opposite. Our talented programmers aren't sitting in a backroom somewhere coding, they're interacting with customers on a daily basis. As a result the customers see them as real people. Often their names are quoted on newsgroups etc when refering to a specific product. And to everyone they've helped they're heros. Because each one "owns" the product they're making the credit goes to them personally. They're a hero to every customer they deal with. We get these "rave" emails from time to time from a customer where we just saved his bacon big time. We get thank-you's posted on public forum's, either for a product or support. This means a whole lot more to a programmer than just counting lines of code. They're making a difference to another person, and they know it. And that is a lot better IMO than "writing lots of code."
In closing - this works for us. Obviously it's not practical everywhere. If the company goal is lots-of-code then don't try it. If the company goal is happy-customers then it might be worth it.
Bruce Johnson
Wednesday, December 17, 2003
"This is often true early. But very quickly you discover that taking the time to fix it _right_ means few support calls later. If anything the developer is _more_ motivated to fix it right than hack it, because they know who will be picking up the pieces later."
Having the coder be the sole party responsible for support of his/her code is what saves you from mayhem. There's no diffusion of responsibility. If the situation was such that Senior Developer Bob wrote the code, but Junior Developers Suzie, Jack, and Jill have to help field support calls for Bob, then in all likelihood the code will become a nasty hack job even if Bob is still the sole owner and maintainer of the code, unless Bob is an exceptionally self-disciplined quality-conscious guy (he's probably not). Meanwhile, in this work environment Jack and Jill don't have much motivation to keep their own coding projects in beautifully logical, top notch shape because others will share the burden of supporting their apps and kludgy hacks are an accepted way of doing things within the organization.
Suzie, who happens to be a really self-disciplined quality-conscious person that takes pride in her work, continued to write quality code and do things the right way, but kept getting pressured from others in the organization about her slow progress on her coding projects even though about 90% of her day is spent dealing with support calls caused by Bob's kludgy code and about 9% of the remaining 10% of her day is wasted time because of all the interruptions. "Why can't you be more like Bob?" says the manager, "Yesterday morning I asked Bob to add TRQ widget reporting to the AVMRZ app and he had it completed and deployed onto the server before lunch." Suzie got sick of working in this mismanaged cowboy shop and just gave her two weeks notice. She's going to work for company XYZ.
anon
Wednesday, December 17, 2003
Spending long months gathering requirements and designing and testing a system is more “tedious” to most people than debugging. Most of us designers work in relative obscurity. No customers call us “heroes” because we’ve “saved anyone’s bacon big time”. The long, hard slog to creating a new product means hours of isolation every day, concentrating on one facet of the product at a time. It’s when you get interrupted that the design flaws appear – because we’ve lost our train of thought at a critical moment.
I’ve seen too many superb maintenance engineers be ‘promoted’ into development and crash and burn. We desperately need the best debuggers to keep doing what they do best. Anyone can see that they love the hunt of the bug and the feeling of satisfaction they get when they trap one. Let them be “heroes” to the customers. They deserve it.
Bruce Johnson is right that you have a problem if the help-desk phone is ringing off the hook. The problem is probably that you’ve got the wrong person in a design role. Find him and put him where he can shine. Rubbing his nose in customer complaints is unkind.
anon 2
Wednesday, December 17, 2003
 Recent Topics
Fog Creek Home
|
