Software tech support



  • Hi guys, I have an IT business/organizational question for you all.  I currently (and for the past 6 years) have worked for a software development company doing a combination of development and help desk work.  The young-uns won't remember this, but back in the 1980's when languages like Cobol, Fortran, and C dominated the industry the general scheme of things was to put a copy of the source code on each customer's system and allow them to hire their own internal programmers to support/modify it if they wanted to.  The software vendor then had a help desk function to support the customer's technical staff.  That's how I "came up in the ranks" by getting hired for small companies and working on the financial/inventory/whatever software that they purchased from software vendors.

    That's still the model that my group uses, although as you can imagine it's long obsolete and becoming less and less needed or useful.  Looking ahead, I am thinking of positioning myself for a move to management, and rather than trying to teach this old dog new tricks like .NET programming I think I want to leverage my long experience in my particular market sector and even longer background in general IT principals.  I'm thinking that maybe I could work my way into managing and reorganizing our customer service organization to work better for modern business.

    To that end, I would like to know how that would work with the new software development methodologies.  We have a new product line that follows the more modern release cycle strategy that's common today.  They don't give customers the source code, and don't make ad-hoc changes to it like we do in my area.  I understand that when bugs are found post-release they are incorporated into the next release.  What I would like to know is how do modern software development  houses handle customer service/support?  Should I learn (and work toward) standard CRM methods?  Do many of your organizations offer help desk support for your software customers, or is it all provided via peer-to-peer forums and such? 

    If I sound surprisingly clueless about this, it's because I am.  My company - despite having migrated to new methodologies about a decade ago, still hasn't modernized the customer service organization.  So I don't have an internal example to follow, I can only look at what I've found out there as a customer to other companies.  But having that limited viewpoint, I wouldn't be surprised if I'm totally missing a lot of organizational and functional details.



  • Support should always be part of the company's services. Especially when new software is introduced. Taking customer feedback and tracking their issues will help make the product better. At least some minimal phasing support should be done to help existing customers who purchased the software. If there was some critical bug in the system that affected operations, you could be costing the customer money. By providing at least a certain amount of support and updates after release, the customers will recognize your efforts and are further inclined purchase future releases.  Without that support, they might feel like they could find a better product elsewhere - preferrably from someone who will offer them continual support.

    I would use Issue Tracking software because it provides a means to follow up on problems and hold people accountable for resolving the issues.



  • I agree. I hate having to websurf to get help with motherboard problems (for example) after buying new hardware. Sure, the peer-to-peer forums are helpful ONCE YOU FIND THEM, but I resent how so many companies make me feel I'm on my own with their products.

    Internally, what we seem to do is gather a team of developers to develop the product. Sell it to the first few customers. Then those developers are slowly migrated into maintenance/support roles for specific customers who purchased that particular version of that particular product. So after about 5 years we have groups of people supporting specific customers. And of course probably getting bored with the maintenance work and stagnating skills. Then we hire a whole new crop of developers to work on the new releases or new products. It seems to me that other companies hire people specifically for the helpdesk role and keep their development teams as development teams. Is that an accurate perception? If so, how do you keep the helpdesk folks from getting bored or stagnating and leaving? Clearly lots of companies either outsource the help desk function or hire script monkeys to read troubleshooting scripts to the customers who call. I hate that and believe it's counter-productive, but what is the better strategy?



  • Well, a better strategy is to have about 3 groups of people.. Devs, QA, and support. Making a solid product is sometimes better than making a new product.  After the bulk of the issues are addressed, you don't want Devs to be sitting around when they can be working on new projects. The support group can key in issues from the field. The managers can assign certain issues to certain developers. So you might have a dev or two that basically has each of your legacy products on their second burner. Thats what you pay for, might as well get the moneys worth out of the dev and keep their dock full.  QA should do most of the testing, and QA support should at least have an idea of how to reproduce issues before sending it to development. Now you have these groups of people that become good at what they do, and are hopefully happy at where they are at. Think of it this way.. the support and QA people would know they are going into this type of job when they apply. Don't make the Dev slowly become a full time (support or QA) person, thats not why you hire developers.



  • Okay I think that's basically how we do business.  The problem we ran into is that our original product was soooo stable and solid that it runs for decades.  Quite literally it's over 20 years old.  We used to have help desk people who were hired for that purpose, but now we don't.  I honestly don't know if they've tried to hire people to do help desk work for it, though, or just assumed that you can't find anybody willing to do Cobol and assembler maintenance work.  It's an assumption that most of us make, so it's hard to blame them.  On the other hand, if you don't try you don't know.

    <P>

    Anyway, so the question comes back to, if your product is that stable, how do you keep a group of support people to work on what is considered in the industry to be obsolete technology?  I'm not worried about our current group of people, because I'm expecting the current product to be dropped in the next 5 or so years - about the time I become manager.  But it's still a good lesson to learn for the next product - when C# and .net become the next obsolete technologies.  (Hard to envision, I know, but it WILL happen.) 



  • Maybe I'm kinda reaching out my bounds, but you'd think after a certain time period, you do start phasing out the amount of support you provide (especially one 20 years old in your case).  A product that old, there comes a point where you just have to say, "Thats just a known issue for this product." Like you said, its very stable, and you reallly don't want to change anything and risk rendering it unstable. Pretty easy to do if some of it was written in assembly.

    You have to think too, that the reason that its hard to find those people is that they can't make any more money on that technology other than what a select group is paying. If you found your man/woman that you need, there prolly isn't anyone else in town for other candidates to want to dive into COBOL and assembler. 

    It is just my preference, but I wouldn't write a whole system in assembly if my life depended on it.



  • Yeah, that's one thing I thought of after I posted my last reply.  We probably should switch to the business model that Taxcut and Quicken use where they stop supporting older versions of the product after about 5 years or whatever.  I've read on blogs like Ed Foster's Gripeline that this really ticks off your customer base, though, so I'm not sure it's the right approach.  On the other hand, you really can't expect to support old code forever.  (Or actually, maybe the problem with those examples isn't the support cessation as much as when they deliberatey BREAK functionality to force the user's to upgrade.)

    Although we've rewritten our product using modern technologies, we haven't addressed support for it yet.  Not that I can see anyway.  I don't work for those groups so I may be wrong, but it seems like customers go straight to the project manager or lead developer.  Just like they do for our group.  I don't think we (as a company) have fully figured out how to support our software, which is where I'd like to fit in when I move up to management. 

    I think it's kind of interesting that you're the only one who is replying to this thread.  I do value your comments.  But I wonder if this indicates how very few people here are support/maintenance programmers or if it's just a lack of interest.  Anybody else want to chime in?

    Also, this doesn't address the topic, but you mentioned it, so I thought I'd throw this back just to make your skin crawl.  The Cobol/Assembler product has always since the beginning been modified at customer request.  Part of the reason it's still around and still so loved by our customer base is that very reason.  If they're willing to pay for it, we're willing to do it.  So no two customers have exactly the same system, we long ago lost the ability to point to one version as the "base".  Amazingly (or perhaps appallingly to our management), the "post-sales enhancement" business has always been so lucrative for us that we haven't been able to drop it.  The product been astoundingly stable despite all that, since it's lasted so long.  But perhaps the reason it's seen as stable is that when we do introduce errors in our modifications (and we do, yes), we're lightening quick to fix them.  The customers don't have to wait for the next release of the product.  We dial into their computer and fix it asap.  But of course that's the old paradigm.  We definitely do NOT do that for the newer products.  So the challenge for me personally, is to bring my mindset away from that old paradigm where I'm used to working, up to the new software development and maintenance models.


Log in to reply