Agile programming (was Re: [P|C] Banksel)
Vitaliy email (remove spam text)
"Nate Duehr" wrote:
>> did a calculation on the cost in $ per line of code, and it was
> 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.
> 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?
See also: www.piclist.com/techref/microchip/devprogs.htm?key=programming
You must be a member of the
piclist mailing list
(not only a www.piclist.com member) to post to the