"Nate Duehr" wrote:
>> did a calculation on the cost in $ per line of code, and it was
>> astronomical*.
>
> I didn't say it was cheap.  I said the code worked.

In a free market, everything has a maximum price that the market will 
bear -- the "break-even point". If software costs more than the users are 
willing to pay, the project is a failure.


> If companies REALLY knew how much it would cost -- including all
> bugfixes and later releases and patches -- to do many of the things we
> do with computers today, when they STARTED the project -- they'd have
> kept the paper, pens, and filing cabinets.  Seriously.

Well, it's not that bad. As I mentioned, I worked in a call center, and we 
used very crappy software. But at my company we do lots of things with 
computers, and it's working pretty well. Most of the things would be very 
hard to do without a computer, and some impossible.


> Every trouble ticketing system I've EVER seen deployed, for example,
> is over-budget, missing critical features that then require paper or e-
> mail workarounds, and never hits the mark 100%.

We've been using Kayako eSupport since 2005 at work, I've used it myself and 
it works very well. Certainly beats email.


> Trouble ticketing software and projects are an utter nightmare.  They
> almost NEVER ask the "customer" (the techs) what information they want
> to see displayed, what information they can get readily from a
> customer, and what information they don't care about.  Just a little
> UI work would go a long way -- but it's usually the "Business
> Development" group, or some Tiger Team of project managers and people
> who've never done tech support who set the screen layout for the large
> company systems I've worked on.

When were were shopping for an inventory tracking and invoice system, the 
future end users attended every presentation, and ultimately had the 
decision-making power. CS and warehouse managers who themselves are end 
users did the preliminary research. The software that we ended up buying is 
not perfect, but it certainly improved the way we do things. And the staff 
bought into it -- so there was no resistance to overcome.

Another example is the shopping cart. Our web developer did the research, 
but there were several meetings with the end users to gather requirements, 
and then a meeting where the shopping cart was presented and its features 
checked against these requirements.


> My favorite thing about our current system at work is that it causes
> pop-ups for every text entry box in a browser-based system.  You know
> how slow that is?  Incredibly stupid software design.  And like I
> said, I've heard it cost ... in total... about 1/2 a million bucks.

At Getronics, we were running the support app over what looked like a Citrix 
connection. Dialog boxes took several seconds to update, and you could not 
see in real time what you were typing.


[snip]
> Ironically, ticket systems are SIMPLE things.  RT proves it.  I can
> work and notate and complete five tickets with RT in the same amount
> of time as I can do it in Siebel.  The reason?  The e-mail
> integration.  I can send an EMAIL to add a note to a ticket, OR to
> have the system send my comments back to the customer and LOG them.
> Or if I want to see the full history or whatever, I can pop open a web
> browser.  But e-mail's always open in a tech support department
> anyway... so... might as well use it!

eSupport captures emails, and converts them into tickets. They don't work in 
parallel the way you're describing, however.

How does RT forward customer requests to email? Does each customer get 
assigned to a particular tech?

Vitaliy 

-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist