Things About Computers That Irk Me

[Maksutov]

This one is near the top of the list.

New software.

Time to install it.

After agreeing to the EULA and offering up one's first-born, one clicks on "Next".

Eventually a new window appears to advise you about the progress of the installation.

The only problem is, the progress bar that gradually fills up from 0% to 100% indicates how the current part of the installation is going. In other words, not the installation, just a fraction of it.

Then another progress bar pops up and lets you know how well the next part of the installation is going.

And so on.

Can we say "useless"?

There should be ONE progress bar that shows overall how the installation is going and estimates how long it will be until you can either use the new software or restart the computer in order to use the new software.

If progress bars for subsets of the main installation are so freaking important to someone, then let them show up above or below the overall installation progress bar. They are not, I repeat, ARE NOT an acceptable substitute for a progress bar showing the overall completion of the installation.

When I see just subset progress bars, I want to reach through the monitor and strangle the geek who thought that's what should be displayed.

http://www.cosgan.de/images/smilie/boese/k090.gif

Anyone else have similar observations, or is the PC/Mac hardware/software industry at the leading edge re customer satisfaction?

[NEOWatcher]

There should be ONE progress bar that shows overall how the installation is going and estimates how long it will be until you can either use the new software or restart the computer in order to use the new software.
That depends on the installation software.
These are discreted modules that are created as packages individually. There are some packages that have 3 vertical bars that show the progress of the load. One for overall progress, another for the component progress, and the third for available memory (or lack thereof).

Remember, technical people think everything is simple, and the user doesn't need to know anything useful.

[Donnie B.]

One valid reason for having subset progress bars is if the installer requires user input at the end of each subset. That would apply to some of the Windows installs that I've done (the OS, I mean, not a windows app).

But I agree that it can be annoying to see the bar hit 100% and then recycle to 0 without any apparent reason.

[Moose]

A likely reason is that there are multiple installable modules, making a true %-complete computation unfeasibly difficult. Sometimes you simply don't know ahead of time where the 100% mark is.

But these installer programs are pre-packaged with pre-built progress bars. We don't rewrite installer software each time we have a program to install (if we did, your software would be even more expensive.) But like clothing, one-size-fits-all software rarely does.

So, if we don't have an overall progress to show you, and can't leave it looking like it's broken (which you know would drive more folks to gripe on message boards like this), and we can't hide it, then the software pretty much has to default to a module-by-module or file-by-file progress.

Remember, not all decisions are simple (to make or to explain) and non-techie folks won't let us not display progress information, no matter how useless it is.

Let's be careful about sweeping generalizations, folks. I can't tell you how many times various managements (or clients) have forced me to take well-behaved software and make it look or function klunky to conform to some widget-fad-of-the-week. But of course it's all the proggie's fault. We're to blame for everything.

I got stories. Boy do I got stories...

[Fazor]

I just hate when the install software doesn't specify that it's not an overall process bar, expecially when the first part takes forever. Finally hits 100 you start to cheer then BLAM! back to 0. Or the progress bars that just move at a steady rate but cycle back to 0 after 100 percent so they really only tell you that the GUI is still being refreshed. Whoopidy do!

I mainly just install games now though, I don't really use my PC for much else (word processing but how often do you have to install a new WP program?). And I can usually recognize the installation software now, there's really only 2-3 that game companies use, every now and then you'll see them use thier own installer but it's fairly rare.

[Maksutov]

NEOWatcher, Donnie B., and Moose, allow me to make one thing clear. I've been on the other side. For example I had to learn C back in the early 1980s because none of the programmers could understand geometric dimensioning and tolerancing, which is what I needed a program for. So I wrote the program myself. Actually a series of programs which then used a crude GUI to guide the end user to where they needed to go. Compiled with Borland.

I understand what you've said, but once again, the end user is interested in when the application will be available for use. Subsets progress is perfectly fine, in fact any steps that require end user input need to be there, but that still doesn't mean there's an excuse for no overall progress bar.

If the prepackaged installation software doesn't allow for such a thing, then just put in a popup at the beginning of the installation process that says "Progress bars are not able to be displayed with this installer. On average, the software installation will be competed in approximately 10 minutes."

An even better message would include the above (or not if an overall progress bar was feasible), plus a message stating that, e.g., "User input will be required for modules 3, 6, and 9. Please be sure to be ready to supply input when these modules are ready to be installed."

This would eliminate the unfortunate scenario where I've started the installation, then left to do other things (yes, there are other things to do than sit in front of a computer watching and waiting for the installation to be completed) and then returning a half hour later and finding that the installation dead stopped at 23% while waiting for end user input.

I guess I've been corrupted by being in the quality field for so many years, but often the more important thing isn't making life easier for the programmer, it's making life easier for the end user. After all, who pays for and uses the software?

[Ronald Brak]

When computers are easy to use, the singularity will have arrived.

(Converesly, computers say that when humans are easy to use the singularity will have arrived.)

[NEOWatcher]

I guess I've been corrupted by being in the quality field for so many years, but often the more important thing isn't making life easier for the programmer, it's making life easier for the end user. After all, who pays for and uses the software?
That's exactly my point. The more information that you can supply to the user, the better (up until the point where it will be confusing).

I have seen too many instances of developers doing the bare minimum to get the job done, only to have a support nightmare. Plus, there are programmers, and there are analysts, and there are programmers that are called analysts. Many programmers think they know what the user wants, but are lacking many of the details.

Most of this is due to the arrogance that thier code should always work, and any errors that arise are out of control of the application, so there is no point in giving the users anything meaningful, because they won't know what it means. And, I'm not only talking about program exceptions, I'm also talking exceptions in data. If the user sees a piece of data that seems unusual, there needs to be a way to dig deeper as to why it happened.

I can give you horror stories (as can any IT professional).

[Moose]

I guess I've been corrupted by being in the quality field for so many years, but often the more important thing isn't making life easier for the programmer, it's making life easier for the end user. After all, who pays for and uses the software?

*shrug* If programmers were out to make things easy for themselves, all installers would be tarballs to set locations. Not pretty interactive things with flash like progress markers.

As I type this, I'm "watching" a conversion script run (similar to an installer). It's run from my programming editor and takes its prompts from variables I've set within the code. There is no interface. No progress bars. No possible way of measuring progress within modules (I can't even look at the results until the code is done), although the script will tell me when it switches from module to module. I've been running the first module for over an hour now, and I'm hoping it's working. (It did when I used a 1000 user subset of data).

Because I am the end user (or rather, the end user never sees the installation step), I have the rare luxury of not wasting programming zots on the comfort stuff (interface, pretty logging, etc) the user (me) doesn't really need.

Believe me, Mak, programmers know the user counts. We keep that firmly in mind. But you seem to be under the impression that programmers decide where our effort goes or what the interface should look like. That's the exception, not the rule. It's also the exception rather than the rule that the folks drafting the project plans even budget for important things like installers and interfaces.

Programmers nearly always get the short-end from both directions. Given vague, incomplete project requirements. Drastically shorted on time to do the work. Told to make it happen anyway (usually requiring very large amounts of uncompensated overtime.) Then get blamed by everybody for being late and unstated client expectations not being met.

[Moose]

Many programmers think they know what the user wants, but are lacking many of the details.

And these are often the programmers who are given incomplete user requirement docs and poorly drafted design docs and told to code it in this amount of time. And these docs frequently have no basis in what the user actually asked for.

Seriously, NEOWatcher, "you" keep the prog from talking to the user, put them at the far end of a very long communications chain, or better yet tell him nothing at all, then blame him when he turns out to not be psychic.

I recently had to go through a hissy-fit from the colleges where they refused to sign-off on a completed report that conformed in every way [Edit: Including visually] to the design spec they wrote and signed off on. Apparently they were bent out of shape because we didn't code a feature they didn't ask for, and they wouldn't budget additional time to add it. So they threw away the code.

This, of course, was somehow all my fault.

Most of this is due to the arrogance that thier code should always work, and any errors that arise are out of control of the application, so there is no point in giving the users anything meaningful, because they won't know what it means.

Wow. And you think we're arrogant. Sure, users always read the instructions and use the software as intended. They never break the rules, enter crap data then ask for reports to pull information they didn't feel like entering into the system.

(For example: we're somehow supposed to send tax forms to clients when the colleges decided the postal code wasn't an important component of their addresses. This was also, somehow, my fault.)

And this sort of argument doesn't come up on a weekly basis either.

And, I'm not only talking about program exceptions

Actually, these you can blame me for. If the program is buggy, let me know and I'll fix it if I can break open some time to do it. (Not that I have any control over my schedule.)

I'm also talking exceptions in data. If the user sees a piece of data that seems unusual, there needs to be a way to dig deeper as to why it happened.

You cannot blame the programmer for users misusing the software. [Edit:] I should also mention I routinely take time I don't have to help users figure out how their bad data broke the software (partially just in case it was a programming error) and then helping them fix the entry. If I didn't care about the users, I would simply not be available to take those calls. Technically, management doesn't want me taking that time. I do it anyway because I think it's important.

I can give you horror stories (as can any IT professional).

And for every story you can give, I can give you a counterexample. And yet, the programmer is always ALWAYS at fault.

[NEOWatcher]

Programmers nearly always get the short-end from both directions. Given vague, incomplete project requirements. Drastically shorted on time to do the work. Told to make it happen anyway (usually requiring very large amounts of uncompensated overtime.) Then get blamed by everybody for being late and unstated client expectations not being met.
That is very dependent on the environment, and if it is an in-house or saleable product.

I have been in IT for over 20 years, and can only speak anecdotally. But; I have seen user specifications that looked like absolute garbage (to your point of requirements). Most of the staff at our place have technical backgrounds, look for the "cool" stuff, and don't have a lot of business saavy.

A project is usually drafted by business, and IT managers with no technical skills, and dates are applied. The manager hands the project over to a programmer that applies the solution that they are familiar with, rather than having someone determine the best solution. That middle layer of someone who can both talk to the business, and talk to the "nerd" is lost until there is some milestone. By that time, the project is locked into a specific route.

The programmer speaks to the project from the details of technology, the algorithms, how the data is stored. The user usually speaks with different language, speaks to concepts, and in specific situations rather than a commonalities between situations.

[Moose]

The programmer speaks to the project from the details of technology, the algorithms, how the data is stored. The user usually speaks with different language, speaks to concepts, and in specific situations rather than a commonalities between situations.

User: I want a rocket capable of landing a man on the surface of Jupiter. You have one year and a budget of $300,000. Get to it.

NEO, the technology, the algorithms, and the data storage define what is possible. Yes, it's true the user doesn't understand this, and that's fine. A good prog/analyst will tell you what's possible, what isn't, and where it isn't, suggest feasible alternatives that will meet your needs, and will show you what it looks like (in diagram form) for sign-off before the design doc gets written.

I can't claim 20 years in the industry, but when I've been involved in the user req process, I've hit what they've said they've wanted. What they've signed-off on. Every single time.

I do this whenever I'm permitted to. More often I just get some half-tailed user requirements doc (usually in the form of a two paragraph email from a manager who wasn't even at the user requirement meeting), a schedule I've had no input in, and an instruction to make it happen on time and on budget.

[Donnie B.]

Wow, this is all so a propos of the Project Management training I got recently.

If you believe what the PM folks say (with studies to back them up), all these issues can be ameliorated by using proper project management techniques. It takes management buy-in and some extra money and effort up front, but the results overall make it a bargain.

Of course, when you have employees willing to work 80-hour weeks for 40 hours' worth of pay, it's probably not worth spending the extra money to run the project as it should be run.

[Donnie B.]

User: I want a rocket capable of landing a man on the surface of Jupiter. You have one year and a budget of $300,000. Get to it. Reminds me of the Dilbert that had a user requirement for his next widget to use an ESP-based user interface.

[Moose]

Dilbert is a documentary, not a comic strip.

[NEOWatcher]

And these are often the programmers who are given incomplete user requirement docs and poorly drafted design docs and told to code it in this amount of time. And these docs frequently have no basis in what the user actually asked for.
And when the programmer doesn't ask questions, they dig themselves deeper in. Not that I put all the blame here, but too many times, the person in the know can not be bothered by occasional "trivial" little details or questions.
Seriously, NEOWatcher, "you" keep the prog from talking to the user, put them at the far end of a very long communications chain, or better yet tell him nothing at all, then blame him when he turns out to not be psychic.
We all know that happens. But from management point of view, the person who does the work is usually the one to blame.
I recently had to go through a hissy-fit from the colleges where they refused to sign-off on a completed report that conformed in every way to the design spec they wrote and signed off on.
Been there many times, it's usually the PM's fault for not keeping thier involvement in the project.
This, of course, was somehow all my fault.
Also the fault of the PM.
Wow. And you think we're arrogant. Sure, users always read the instructions and use the software as intended. They never break the rules, enter crap data then ask for reports to pull information they didn't feel like entering into the system.
I never said they weren't. But I have seen too many times when a simple data check could have solved a major problem.
(For example: we're somehow supposed to send tax forms to clients when the colleges decided the postal code wasn't an important component of their addresses. This was also, somehow, my fault.)
On the other hand, I have had a situation where a user entered a ZIP+4 and the programmer raising a fuss and blaming the user because nobody ever told him that this was possible (even though he left the field large enough for it)
Actually, these you can blame me for. If the program is buggy, let me know and I'll fix it if I can break open some time to do it. (Not that I have any control over my schedule.)
Which in my mind is perfectly ok, as long as the bug stopped the process, and didn't ignore it and cause a disaster.
You cannot blame the programmer for users misusing the software.
That depends on the misuse. The user doesn't always know the rules, or can't remember them, so I will blame the user for not following clues, but I will also blame the programmer if those clues are missing.

And for every story you can give, I can give you a counterexample. And yet, the programmer is always ALWAYS at fault.
Yes; that's life. After all, no matter where the blame should be placed, the end product was the creation of the programmer, so that's where the blame starts. It takes a very well seasoned professional to find that balance between keeping every one informed, and not turning it into a CYA situation.
It also takes a good manager to intercept those political situations.

[NEOWatcher]

Wow, this is all so a propos of the Project Management training I got recently.
Yep; been to various PM classes. PM has nothing to do with the way management is willing to do things, and they are the ones saying that PM is important.
This is the reason I've never been interested in a certification.
If you believe what the PM folks say (with studies to back them up), all these issues can be ameliorated by using proper project management techniques.
But, when it gets to the phase where an assumption falls false, and the proper PM step is to go back and re-evaluate, management has a hissie fit, and throws all PM concepts out the window and says to just get the job done.
It takes management buy-in and some extra money and effort up front, but the results overall make it a bargain.
Around here, the managers love proof of concepts, ROI studies, and know the importance of them all. But at the same time, they wonder why other work isn't getting done.
Of course, when you have employees willing to work 80-hour weeks for 40 hours' worth of pay, it's probably not worth spending the extra money to run the project as it should be run.
Willing? More like no other choice. But, have that same employee show up 5 minutes late...

[NEOWatcher]

Dilbert is a documentary, not a comic strip.
Absolutely, but keep in mind, that even in the Dilbert world, there are inept peers. Dilbert is not the only engineer.

[NEOWatcher]

Reminds me of the Dilbert that had a user requirement for his next widget to use an ESP-based user interface.
We call that the "clarivoyance module".

[Demigrog]

Having done a few windows installers in my time, let me put the blame squarely where it should be: Microsoft.

Every couple of years they completely redo their installation infrastructure. We're currently stuck with a weird SQL like database that is so complex to work with that I've had coworkers quit rather than be stuck dealing with it.

The main problem on progress bars is that there are several distinct "black box" steps in an installation:
1) Uncompressing the installer itself
2) Installing 3rd party packages that cannot be integrated into the main installer (ie DirectX, .NET framework, etc)
3) The main installation
4) Sometimes, post installation configuration of 3rd party components

Each step gets its own progress bars, and there is typically nothing the software developer can do about it.

[Doodler]

Doodler's First Law of Computing:

Any computer is faster than you need it to be until you need it to be fast.

It never fails that glitches, hiccups, crashes or other anomalies pop up right when I REALLY NEED SOMETHING DONE RIGHT NOW...

Very irksome.

[Donnie B.]

NEO, have you considered changing jobs? :think:

My work is in the embedded world, and I do both h/w and s/w in a small development group. Maybe I've just been lucky, but my experience has been that I've been able to work reasonable hours (40/wk or even less) except for a few short bursts at crunch times.

[Moose]

We all know that happens. But from management point of view, the person who does the work is usually the one to blame.

And from Bart Sibrel's point of view, NASA never went to the moon. If the plan is wrong, the plan is wrong.

On the other hand, I have had a situation where a user entered a ZIP+4 and the programmer raising a fuss and blaming the user because nobody ever told him that this was possible (even though he left the field large enough for it)

One situation? Or is this a pattern of situations? Did the description of the field in the design doc (or user reqs) specify ZIP+4? Yes, in that situation, the user's not at fault. The prog's at fault if the field was properly documented. The person writing the design doc is at fault if the field wasn't documented properly.

"Do what I meant, not what I wrote (assuming I wrote anything at all)" is bad management, not bad programming.

Which in my mind is perfectly ok, as long as the bug stopped the process, and didn't ignore it and cause a disaster.

That isn't always desirable. In larger bulk jobs, you don't want the process to die on the first bit of malformed data. There's always malformed data. (Which is something my boss, for one, didn't understand at first. He's since come to.) Generally, the right action to take with very large data sets is to log the problem row and make sure there's a way to fix it after the fact.

That depends on the misuse. The user doesn't always know the rules, or can't remember them, so I will blame the user for not following clues, but I will also blame the programmer if those clues are missing.

That's why we write user manuals. (Something else that is almost never budgetted for.) If it's in the manual, it's not the programmer's fault.

Yes; that's life. After all, no matter where the blame should be placed, the end product was the creation of the programmer, so that's where the blame starts.

And this is where I disagree. Strongly. I'm not saying programmers never make mistakes, or are never careless. But it's grossly unfair to automatically pin the blame on the prog. Just like it would be unfair of me to blame stubbing my toe this morning on you.

[NEOWatcher]

Doodler's First Law of Computing:
Any computer is faster than you need it to be until you need it to be fast.

And the user's computer is always less powerful than the developer's.
It never fails that glitches, hiccups, crashes or other anomalies pop up right when I REALLY NEED SOMETHING DONE RIGHT NOW...
Yep; Murphy is a very irritating coworker. He's also usually on the critical path.
And; he's never included in a project plan because management doesn't like risks.

[Moose]

Yep; been to various PM classes.

...

Willing? More like no other choice. But, have that same employee show up 5 minutes late...

On this entire post, NEO, very well and accurately put.

[NEOWatcher]

NEO, have you considered changing jobs? :think:
No; because I am one of the lucky few to have a manager that sees it like it is.

[NEOWatcher]

One situation? Or is this a pattern of situations?
Yes, a pattern.
Did the description of the field in the design doc (or user reqs) specify ZIP+4?
Design documents around here never get down to that level. It is up to the programmer to determine these details or ask the questions.

This might be our major point of disagreement. Around here, we have a high level staff that is supposed to work as analysts, with fill-ins from contractors to do the technical nitty gritty. Unfortunately, the nitty gritty usally ends up in the staff's laps.
"Do what I meant, not what I wrote (assuming I wrote anything at all)" is bad management, not bad programming.
Around here, it's not wrote...

That isn't always desirable. In larger bulk jobs, you don't want the process to die on the first bit of malformed data. There's always malformed data. (Which is something my boss, for one, didn't understand at first. He's since come to.) Generally, the right action to take with very large data sets is to log the problem row and make sure there's a way to fix it after the fact.
Yes; I usually deal with user interfaces, so bulk is not usually an issue. But when I do bulk, I always consider that the single record process is the entire process, and either process it, or not process it. No half process.
That's why we write user manuals. (Something else that is almost never budgetted for.) If it's in the manual, it's not the programmer's fault.
Again, a point where we differ. IT does training, but the business is in charge of the documentation so they can incorporate in in their procedures.
And this is where I disagree. Strongly. I'm not saying programmers never make mistakes, or are never careless. But it's grossly unfair to automatically pin the blame on the prog.
At this point, it is obvious that we have had very different experiences.
Just like it would be unfair of me to blame stubbing my toe this morning on you.
But, I didn't tell you that the table leg is a potential stubbing hazard. :lol:

[Moose]

So, if I understand you correctly from what you've said in prior posts: your progs don't meet with the user, they don't get detailed design specs and minimal feedback, they have no input in the user manual or training, they're under-budgeted, required to work significant unpaid overtime, and they're first in line to take blame regardless of what happens?

And you say there's a pattern of problems? Huh.

You wouldn't by any chance work for Electronic Arts, would you?

[NEOWatcher]

So, if I understand you correctly from what you've said in prior posts: your progs don't meet with the user, they don't get detailed design specs and minimal feedback, they have no input in the user manual or training, they're under-budgeted, required to work significant unpaid overtime, and they're first in line to take blame regardless of what happens?
Yes; and there is plenty of blame to pass around.

Although, for the most part, we do waiver around the 40 hr week with only a few exceptions.

And you say there's a pattern of problems? Huh.
Did I? :whistle:

You wouldn't by any chance work for Electronic Arts, would you?
Nope.

[Moose]

I should mention a relevant situation that's come up from time to time here. We have a COTS (commercial, off the shelf) database system for college management. It's big, it's clunky, and it's very easy for the user to make errors that have fairly wide repercussions.

One of the major components is communications delivery. That too is big, clunky, and easy for the user to mess up in a way that's not so convenient to fix. The person assigned to do this task daily is barely computer literate and even after four years of doing it, has to follow a step-by-step instruction guide and is unable to use her own judgment in performing this daily duty. I've had some experience modding that system, so I can't blame her for feeling overwhelmed by it (although four years of FUD on her part is a bit much.)

Thing is, I've worked directly with these people for years. I know them. I genuinely like them. At some point or another, (I've interned with them twice,) I've done most of the day to day tasks they do now. I've had lots of time to become familiar with the precise limits of each of their technical capabilities. I've learned how to explain things to each of them so they understand. And they've come to trust me enough that they come to me directly if they need help with something rather than try to CYB/bury it for someone else to deal with.

See, they can tell you what they have trouble doing. They don't know how to accurately express what they think will fix the problem (assuming it's possible, and they'd be guessing anyway as they really don't understand what's happening under the hood.) That's fine. They don't need to know that, so long as someone does.

At my own initiative, on their behalf, I've filed a modification request (management set it at low priority, of course) to correct some of the major design problems in the communications module, adding some much needed features, taking its many (unchanging) prompts from preset tables rather than making the user enter them each time, simplifying the whole process, etc.

I know what their needs are because I've modded the as-delivered system already. I've trained the users personally. I've done their tech support on this system for four years now, and thus I know (and have documented) every single error they've made (and they're getting pretty good at tracking down their own data-entry mistakes now), along with every system bug they've encountered (and told me about. I'm pretty confident they told me about most of them.)

Goodness knows if I'll ever be granted time to do any of this work, but it needs doing.

[Pinemarten]

As an electrician I have no difficulty installing new systems and other electronics.
"Your wall plug has 120 volts and a good ground. Bye."

[ToSeek]

There should be ONE progress bar that shows overall how the installation is going and estimates how long it will be until you can either use the new software or restart the computer in order to use the new software.

There was a piece of software that I used at work for a while that had a progress bar when it was engaged in any time-consuming operation. The progress bar would gleefully flicker from left to right over and over again, as if to say, "Look, I'm making progress!" My task lead would roll his eyes whenever he saw it.

[mr obvious]

I'd be happy if a progress bar was actually indicative of the progress being made. I'm tired of progress bars that:
- tell me you have 10,453 hours left and then, 15 minutes later magically adjust to 20 seconds and then finish at the same time as the task finishes. Thanks!
- repeat the same animation over and over again without telling you how much progress overall is being made. This is especially annoying in some software where the installation hangs, but the animation keeps going, making you think you just need to keep waiting.
- measure an arbitrary level of progress. Related to the first point, if copying files, why not go by total size of all files, rather than number of files or whatever they use? I've actually had progress bars move back to the left (when the progress is measured by moving left to right), suggesting to me that files were uncopied. So this is an 'accurate measure' but since I don't know what's being measured, it has limited utility. Heh.

[Moose]

- measure an arbitrary level of progress.

It really depends on the operation being performed. For example, that conversion script I've been working on that I mentionned earlier. Sure, I could mock-perform each operation beforehand to count the number of rows I need to process first, or I can just go ahead and process the rows, and it'll tell me how it did afterwards. Sometimes it's worth doing that pre-count. Sometimes not.

In my case, I'm indicating progress by operation, not by overall elapsable time. Sometimes that's the best you can get.

If you're pulling files from an archive through a third-party utility (very likely the single most common task in an installer), all you really know beforehand is that you have an archive and a utility. The installer doesn't actually know what's inside the package until the third party utility is done unpacking the archive.

[mr obvious]

I have no issues with differing indications of progress (as long as it's measuring a single factor and lets you know what that factor is), nor with multiple progress bars over the course of an installation. However, I'd like it if the program told me what, precisely, it was measuring. For example, if I'm copying 200 files, it could track by file, so each file moves the progress bar by 0.5%, but it takes a different amount of time to move each file.

However, what happens (to me, sometimes) is that the progress bar tracks by some mishmash of number of file and a floating average of the size of all the files that have so far been transferred (I'm guessing as to this very last part). So I copy 2 files over, it finishes copying one, and the progress bar moves to 50% done, then it starts on the second, and finds that the second file is much larger, and adjusts the progress bar back to 10% done. So what, precisely, is this bar supposed to tell me?

[LurchGS]

Heh, fortunately, as a small company, we learned this from an early age. Put your request in writing. Add as many details as you think are necessary. Double the level of detail. Let the draft sit for a week in the closet. Add more detail..

Hand it to the programmer (until recently, that was my partner - and he was swamped, so it took a while to get your results)

Do *NOT tell the programmer anything resembling how. "How" is his problem.

Don't require a language. (these are enterprise apps, and the programmer knows what languages are available)

Make sure you let the programmer know if this app will be interfacing with other apps. Will they be swapping data?

Tell the programmer the order in which the data must be entered (if aplicable). This may be related to a form where the data originates.

If somebody comes up with something that is a must have, set it up with the same level of detail as the original document. Recognize that it will almost certainly add significant time to the programmer's job. Decide if the feature is worth the delay, or should it be in V2? DISCUSS IT WITH THE PROGRAMMER - it may sound messy to you, but it might be 3 lines of code - and the reverse is true, it may sound simple to you, but require an extra 6 weeks to implement.

When the programmer tells you X amount of time to get the job done, always multiply by at least 1.5, because he WILL get set to other "more urgent" projects that "will take only a moment..."

When you get the app back, from the programming staff - YOU sit down and write documentation for it. Not from the original plan you gave the programmer, but from the app itself. Enter digits in a text field. Enter text in a numeric field. Enter too many characters.

In other words, take simple steps to break it. These are the most common data-entry errors - if they're not dealt with at the entry level, the data entry person will never know he needs to improve. If they're not dealt with, the programmer needs to fix.

A programmer should not make assumptions. Field length/type etc should be determined before he gets the design document. If there is ambiguity, he should get the update in writing.

All in an ideal world.

Oh - almost forgot: Never ask for a progress indicator. Do ask for a "task started" indicator, a "task in progress" indicator (tied to the actual task, not a separate program), and a "Task Done" Indicator.

[Moose]

Good list, Lurch. Yours sounds like a good company to work with.

When doing user reqs, one trick I have that seems to help (when designing reports, anyway) is to take an hour or so with the client and do a Word-document (or more commonly Visio) mockup of what the output is going to look like. I've found it to be a great communication aid for bridging that "communications gap", and it's a great blueprint to follow for doing up a design doc with sufficient information for the prog (usually me.)

[farmerjumperdon]

I hate some of the logic in Word. It thinks it knows what I want to do, but it don't know jack. Bullets and outlining are a good example. Anyone know how to disable it's desire to force me to outline using it's criteria instead of mine? Short of a sledgehammer or blowtorch. And I'm not worried about bruising.

[NEOWatcher]

I hate some of the logic in Word. It thinks it knows what I want to do, but it don't know jack. Bullets and outlining are a good example. Anyone know how to disable it's desire to force me to outline using it's criteria instead of mine? Short of a sledgehammer or blowtorch. And I'm not worried about bruising.
It easy if you just think the same way Microsoft thinks...they are here to help.
Oh, sorry, that is the same thing as a sledgehammer or blowtorch to the head.

[mike alexander]

"When computers are easy to use, only the easy will use computers."



Farmerjumperdon has picked by own worst annoyance, Word (upon which I have rained invective elsewhere).

Why can't I make it indent paragraphs right? Even after following what I think are the directions?

Why doesn't it ASK before assuming since you did something twice you intend to do it for the rest of eternity?

Why is it so easy to inadvertently turn on the 'overlay' function? (This happens to me all the time, resulting in writing over several lines of deathless prose)

[mr obvious]

I hate some of the logic in Word. It thinks it knows what I want to do, but it don't know jack. Bullets and outlining are a good example. Anyone know how to disable it's desire to force me to outline using it's criteria instead of mine? Short of a sledgehammer or blowtorch. And I'm not worried about bruising.

Depending on which version of Word you have, you can go to the "Tools" menu, and select "Autocorrect." In the Autocorrect dialog box, select the "Autoformat as you Type" tab, and under the section "Apply as you type" you can uncheck the Automatic bulleted lists and numbered lists, etc. Indeed, there are a bunch of automatic stuff you can turn off here if you don't like them. Hope this helps. You may keep the sledgehammer and blowtorch.

[Zachary]

When computers are easy to use, the singularity will have arrived.

(Converesly, computers say that when humans are easy to use the singularity will have arrived.)

What do you mean by easy though? Plop a computer with a modern OS in front of a 1960s college student who has to write programs by sticking holes in a punch card with a sewing needle, then I'm pretty confident they'd say our computers are easy to use!

[LurchGS]

well, actually, our computers *ARE* easy to use. It's the software (and I don't exclude the OS) that tries to run on our computers that's a brass plated .. um.. bad thing.

Some software is blindingly easy to use, some is WTF?!?! Most, of course, falls in the middle. I tend to use share/free ware because I understand that kind of person better - which means I understand their software better.

I will NOT use Word. Nope. Ain't happening. Nor will I use Excell. And ACCESS!!!! geeminy! And Microsoft's version of Hypercard; PowerPoint.. ok, I have no choice there. A lot of my training comes down in PP, so.. there I am.<yawn>

I really hope Apple brings back Open Doc - there was a concept way before its time.

[Maksutov]

Then there are the useless, misleading, or downright wrong popup/embedded messages one sees too frequently.

Here's an example of the third kind (not A, B, G, G (drop octave), D):

http://img517.imageshack.us/img517/3023/nerodvdburn1cm4.th.jpg (http://img517.imageshack.us/my.php?image=nerodvdburn1cm4.jpg)

"Writing at 10.225 KB/s" sounds nice, but at this point in the process the DVD burner was doing its initial read.

I was very taken aback when I first saw this message, since I was duplicating a DVD backup of part of one of my hard drives, which I had repartitioned. Yeah, it was great seeing that the first thing the burner was doing was writing.

Fortunately it's reading and writing the ISO image to the HD at this point (of course) but the tyro wouldn't know that from the message.

[Moose]

"Writing at 10.225 KB/s" sounds nice, but at this point in the process the DVD burner was doing its initial read.

Are you sure? It's also the part of the process where the file system header gets written.

[amok]

Personally I think nero's status windows are pretty informative. They at least list and will tell you what is going on... 'Creating the image for burning'. The only case where I am irked at a window is when it doesn't give Enough information. In nero's case it gives almost too much.

But that might just be me, plus I like nero.

[Pinemarten]

What do you mean by easy though? Plop a computer with a modern OS in front of a 1960s college student who has to write programs by sticking holes in a punch card with a sewing needle, then I'm pretty confident they'd say our computers are easy to use!

I remember seeing the quadratic formula on punch cards from the '70s. I think it used 200-300 cards.

[Maksutov]

Are you sure? It's also the part of the process where the file system header gets written.Yeah, I know there was writing going on (i.e., initial steps to create the ISO), but the main concern was where the writing was taking place. Since there was no "target" specified, and I was dealing with a DVD burner, it could have been the source DVD, in which case, goodbye data.

Of course that wasn't the case, but I'm just relating the initial jolt when first using the software.

If the programmer is going to tell me there's writing going on, where it's happening is useful information. Addition of "to the hard drive" re "writing" would have been nice.

[LurchGS]

Maksutov-

I'd completely forgotten that one - yeah. There are a number of apps out there, on all sides of the OS wars, that do that - not tell you WHERE they are doing what they are doing. I just looked at some of my recent stuff, and I provide a bit of overkill - I include the full pathname. I am, therefore, proud of myself. [insert smug look here]

I think there's one on the mac that has a button that says "Burn Disc"... before it even reads the source.

[Maksutov]

Maksutov-

I'd completely forgotten that one - yeah. There are a number of apps out there, on all sides of the OS wars, that do that - not tell you WHERE they are doing what they are doing. I just looked at some of my recent stuff, and I provide a bit of overkill - I include the full pathname. I am, therefore, proud of myself. [insert smug look here]My sincere congratulations! There are a few end users who actually have concerns about where the data're going.

:clap::clap::clap:

I think there's one on the mac that has a button that says "Burn Disc"... before it even reads the source.I wonder if I'll ever get over the reaction I had back in the mid 1980s when a Macophile told me it was intuitively obvious that if one wanted to eject a floppy, it should be done by dragging the disk icon to the Trash icon.

http://img247.imageshack.us/img247/6122/trashiconemptycy1.png (http://imageshack.us)

[Celestial Mechanic]

I remember seeing the quadratic formula on punch cards from the '70s. I think it used 200-300 cards.
My first computer program was solution of quadratics, and it even handled complex roots. It did not take more than 20-30 cards, and this was in 1968. Of course there may have been some problems with numerical precision, for example the small root of x2-x-10-12=0, but hey, I was 15 and didn't know any better! I also wrote a sort program using the obvious algorithm--bubble sort! Same disclaimer applies. :)

[Maksutov]

My first computer program was solution of quadratics, and it even handled complex roots. It did not take more than 20-30 cards, and this was in 1968. Of course there may have been some problems with numerical precision, for example the small root of x2-x-10-12=0, but hey, I was 15 and didn't know any better! I also wrote a sort program using the obvious algorithm--bubble sort! Same disclaimer applies. :)Funny, the first program I wrote had to do with solutions for Boolean expressions (coals to Newcastle, I know). I figured that rather than going through all the math for the intersected areas, it would be simpler just to have a machine do it. That was back in 1965. My physics prof had to plead my case with the "mainframe" guys, essentially arguing that it would only take up about 128 bytes of their precious processor, memory, and storage capacity.

Only 42 years ago.

PS: Oh yeah, the program wouldn't have passed muster on the net, since it was ALL CAPS.

[Celestial Mechanic]

[Snip!]I wonder if I'll ever get over the reaction I had back in the mid 1980s when a Macophile told me it was intuitively obvious that if one wanted to eject a floppy, it should be done by dragging the disk icon to the Trash icon.
I could never make sense of that one either. I guess it's because they "think different". ;)

[mugaliens]

I wonder if I'll ever get over the reaction I had back in the mid 1980s when a Macophile told me it was intuitively obvious that if one wanted to eject a floppy, it should be done by dragging the disk icon to the Trash icon.

http://img247.imageshack.us/img247/6122/trashiconemptycy1.png (http://imageshack.us)

Believe it or not, I actually heard a guy tell me the same thing about two weeks ago. He's a friend and I actually spend fifteen minutes of each afternoon eating my snack in his office just to hear him rant and rave against Windows which he's required to use.

Lots of comments like:

"The government actually used to use Macs. Why did they pick Windows? Windows stinks. Here, watch this (he does something in Windows). Why does that happen? Why doesn't it to this, instead?"

He usually gets it out of his system in about 5 minutes and we spend the next 10 minutes talking shop.

It's quite a pick-me-up!

[Pinemarten]

My first computer program was solution of quadratics, and it even handled complex roots. It did not take more than 20-30 cards, and this was in 1968. Of course there may have been some problems with numerical precision, for example the small root of x2-x-10-12=0, but hey, I was 15 and didn't know any better! I also wrote a sort program using the obvious algorithm--bubble sort! Same disclaimer applies. :)

I may have been wrong on the number. I was young too. The stack was 1-2" tall which seemed like 200-300, it was probably closer to 20-30. I think each card was one byte.

[mike alexander]

Hah. I remember sitting through an Excel training course when we were told to insert a time in a cell, press CTRL SHIFT ;

After a few seconds silence I blurted out "Well, THAT'S intuitively obvious."

[LurchGS]

I wonder if I'll ever get over the reaction I had back in the mid 1980s when a Macophile told me it was intuitively obvious that if one wanted to eject a floppy, it should be done by dragging the disk icon to the Trash icon.


Yeah - I've been using Apple products for 20 years (a bit of a stretch), and that has ALWAYS bothered me. I still just right-click (or left, depending on which machine I'm using) and eject it from the pop-up menu.

[SockMonkey]

I just hate it when I get a pop-up for a security update every other day.

Said security update being to protect the software from pirating and NOT my computer from viruses.

It's getting to the point where the anti-pirating features no longer take up a trivial amount of space.

I often liken it to putting a car alarm on a skateboard.

[Maksutov]

Hah. I remember sitting through an Excel training course when we were told to insert a time in a cell, press CTRL SHIFT ;

After a few seconds silence I blurted out "Well, THAT'S intuitively obvious."Good one!

Reminds me of back in the late 1980s when the company got hijacked by DEC and we were condemned to "work" with nerds from Maynard. Trust me, those are the worst kind, just the opposite from G. Krebs.

Of course all the PC and Mac stuff was considered by them to be beneath their dignity. It was VAX/VMS all the way.

I actually asked one of the DEC nerds who seemed semi-human if there was some way to do graphics in VAX/VMS. She replied, "Of course! VAX/VMS can do anything!" She then showed me how to assemble 2D objects using something that looked like the ASCII character map (250C through 256C, etc.). "You just just take this horizontal line here, and then this vertical line there, and then enter a (35 character) command to get them to join to form a corner. And then you..."

The worst was when the head nerd would be called in. If any of us got into a code (or earlier, a pseudocode) corner, this fellow with a neatly trimmed mustache above an upper lip that never moved would make his presence known, much to the awe of the other DEC nerds, and to the chagrin of those of us who were trying to do useful work.

He would impatiently listen to one of us describe the problem. Then he would summarily dismiss the person from their chair, wipe it clean, and then with blazing speed, type a 129 character command, which would solve the problem.

He would then majestically rise from the workstation chair and announce "See how simple that was?"

The DEC nerds left earlier in the afternoon than my workforce. That probably prevented us from running over them in the parking lot.

[NEOWatcher]

I actually asked one of the DEC nerds who seemed semi-human if there was some way to do graphics in VAX/VMS. She replied, "Of course! VAX/VMS can do anything!" She then showed me how to assemble 2D objects using something that looked like the ASCII character map (250C through 256C, etc.). "You just just take this horizontal line here, and then this vertical line there, and then enter a (35 character) command to get them to join to form a corner. And then you..."
Ok; Now you touched a nerve... Watch out... Here I come...

VAX/VMS is hardware and operating system.
It is not an application or user interface. It can only be equated to the kernal of a windows box.
You are also talking about mainframe technology as compared to a single user technology.
You want a user interface? You had DecWindows.
You want a graphics program? You had a whole lot of stuff.
Can a MAC or Windows box serve many users at one time?
Many of the VAX/VMS concepts and implementations were before PC technology was available.

I was once the Sys Admin of a system that ran our entire business systems. We rebooted the box after about a year and a half of non-stop operation only because we were worried that it was so long between errors.

We ran AutoCad on VAX/VMS single user systems (DecStation) because at the time we implemented it, it was the fastest machine of the time (the days of the 286). It did get eclipsed real fast in the price/performance arena. We also reviewed various other CAD packages for VMS, including one from NASA.

We even ran WordPerfect on "dumb" terminals off a mainframe system. (of course, this was before "WYSIWYG")

The command language was intuitive and extremely flexible (although a little wordy at times - trade offs)

Now, do I think that VAX/VMS is better. Well that depends on the application and the time frame you are talking about. In a multiuser environment, absolutely. In a networked environment, depends. From a security standpoint, Yes. For reliability, Yes.

From an availability of layered products, now that is the huge no. From a user's point of view, No. It was always a tech's type of machine. And; I believe that is what doomed it. It was never touted as a user's machine, and was never meant to be. Therefore, it never developed or evolved. DEC missed the boat drastically on this one.

[Maksutov]

Ok; Now you touched a nerve... Watch out... Here I come...

VAX/VMS is hardware and operating system.
It is not an application or user interface. It can only be equated to the kernal of a windows box.But the DECies promoted it as such.
You are also talking about mainframe technology as compared to a single user technology.Of course.
You want a user interface? You had DecWindows.Was that available in 1988? If so, then the DECies kept it under wraps. You want a graphics program? You had a whole lot of stuff.Such as? 1988 remember...
Can a MAC or Windows box serve many users at one time?Sure. That's why they're called "servers".
Many of the VAX/VMS concepts and implementations were before PC technology was available.But they never kept pace. I was once the Sys Admin of a system that ran our entire business systems. We rebooted the box after about a year and a half of non-stop operation only because we were worried that it was so long between errors.Hope the reboot was a good one. And done late Sunday night, unlike the DECies preferred reboot on Friday afternoon. We ran AutoCad on VAX/VMS single user systems (DecStation) because at the time we implemented it, it was the fastest machine of the time (the days of the 286). It did get eclipsed real fast in the price/performance arena. We also reviewed various other CAD packages for VMS, including one from NASA.What happened? We even ran WordPerfect on "dumb" terminals off a mainframe system. (of course, this was before "WYSIWYG")Yeah, always loved all those "*", "_" , and other formatting symbols that wouldn't show up in the printout but made the on-screen version a real mess and almost impossible to read.
The command language was intuitive and extremely flexible (although a little wordy at times - trade offs)Intuitive my foot. Perhaps if one were raised to speak VAX/VMS, but for the unwashed English-speakers, it was about as arbitrary and arcane as dragging a floppy to the trash can to eject it. Now, do I think that VAX/VMS is better. Well that depends on the application and the time frame you are talking about. In a multiuser environment, absolutely. In a networked environment, depends. From a security standpoint, Yes. For reliability, Yes.

From an availability of layered products, now that is the huge no. From a user's point of view, No. It was always a tech's type of machine. And; I believe that is what doomed it. It was never touted as a user's machine, and was never meant to be. Therefore, it never developed or evolved. DEC missed the boat drastically on this one.Funny how the users tend to determine the ultimate fate of OSs.

On that we agree.

[NEOWatcher]

Apparently, you didn't get the point of my post. In summary, we are talking apples and oranges. Why do you feel the need to compare them?
But the DECies promoted it as such.
Did they? I don't remember that.
Of course.
Was that available in 1988? If so, then the DECies kept it under wraps.Such as? 1988 remember...
Yes... I was working on graphics terminals on Dec Equipment in the early eighties in collage. They were dumb graphics terminals, but they were graphics.
And; I don't remember the timeframe, but it was around the time of the introduction of the 386 that I was working with X-Windows, DecWindows, and the such.
Besides, again we are talking mainframe vs PC. The device that attached to the computer dictated the graphics ability, not the computer.
Sure. That's why they're called "servers".
Not a good analogy. The difference between server and mainframe is the fact that a server requires a smart terminal (computer) to talk to it, a mainframe does not.
But they never kept pace.
Hard to say...Marketing for DEC was abysmal, they never saw merit in PC's because everyone else was doing it cheaper, so they stayed in the high end arena.
And, Pentium was based on Alpha (some say stolen) technology. DEC had some of the most sophistacated chip manufacturing in the world, and they sold themselves out to Intel.
They led the pace until someone tripped them.
Hope the reboot was a good one. And done late Sunday night, unlike the DECies preferred reboot on Friday afternoon.
And now we get servers being rebooted in the middle of the weekday for no reason whatsoever. Sounds like a personal problem with your "DECies", and has nothing to do with the hardware.
What happened?
A complex situation, but the popularity was turning from Workstations and Turnkey systems to PC's.
Yeah, always loved all those "*", "_" , and other formatting symbols that wouldn't show up in the printout but made the on-screen version a real mess and almost impossible to read.
And HTML is easy to read? Formatting is formatting, device drivers are device drivers. There is no way around it.
Intuitive my foot. Perhaps if one were raised to speak VAX/VMS, but for the unwashed English-speakers, it was about as arbitrary and arcane as dragging a floppy to the trash can to eject it.
What are you comparing it to? I am comparing it to other popular command languages, namely DOS, and Various flavors of UNIX.
Funny how the users tend to determine the ultimate fate of OSs.
Which is also based on marketing, which was not Dec's forte.
On that we agree.
Interesting how you agree on my summarization. Yet you slam the ideas (or at least seem to).
Again; apples and oranges... a different branch on the evolutionary tree which went extinct.

[HenrikOlsen]

Many of the VAX/VMS concepts and implementations were before PC technology was available.But they never kept pace.
Not so.
What actually happened was that NT was co-developed by DEC and Microsoft people and the concepts and implementations went into that, to flourish in the wild.

[Maksutov]

Originally Posted by Maksutov http://www.bautforum.com/images/buttons/viewpost.gif (http://www.bautforum.com/showthread.php?p=986814#post986814)
Quote:
Originally Posted by NEOWatcher http://www.bautforum.com/images/buttons/viewpost.gif (http://www.bautforum.com/showthread.php?p=983236#post983236)
Many of the VAX/VMS concepts and implementations were before PC technology was available.

But they never kept pace.
Not so.
What actually happened was that NT was co-developed by DEC and Microsoft people and the concepts and implementations went into that, to flourish in the wild.In other words, DEC let it slide.

In general I've never dealt with nerds who were so in love with their software/hardware as the DECies they sent down from Massachusetts to put various wrenches in the systems we were trying to develop. If similar nerds were heading up marketing, no wonder they failed. I can see the ad campaign:Hi. I'm DEC nerd and I'm much smarter than you. You will buy what we sell because we told you to.How we ever got our FNMCP approved by DOE is something I still marvel at. I guess the boys in Rockville had been through similar nightmares and commiserated.

[please]

When computers are easy to use, the singularity will have arrived. I have heared this reference a few times already. What is it from? A novel? A movie?

[NEOWatcher]

In general I've never dealt with nerds who were so in love with their software/hardware as the DECies they sent down from Massachusetts to put various wrenches in the systems we were trying to develop.
So you are going to chastise anybody that likes DEC because you had a bad experience with a few people? That is called prejudice.

See; we went DEC because the salesmen that came were down to earth, answered any questions we had, and had a good understandable set of documentation.
IBM came in thier primmed and preened suit and said "trust us...we'll be able to figure it out".

If similar nerds were heading up marketing, no wonder they failed. I can see the ad campaign:.
I would agree there.

[Maksutov]

Originally Posted by Maksutov http://www.bautforum.com/images/buttons/viewpost.gif (http://www.bautforum.com/showthread.php?p=987402#post987402)
In general I've never dealt with nerds who were so in love with their software/hardware as the DECies they sent down from Massachusetts to put various wrenches in the systems we were trying to develop.
So you are going to chastise anybody that likes DEC because you had a bad experience with a few people? That is called prejudice.Where did I say I was going to chastise anybody that likes DEC?

Cite please.

Prejudice means prejudging people based on assumptions, etc.

In the case of the DECies, we had no preconceived notions about what they were all about. Silly we, thinking they were here to help. BTW, the number of DECies was close to 30. We, the end-users, numbered around 500.

30 is a good number for determining statistically significant results. The statistically significant results of our encounter with DEC was that they couldn't have cared less if we succeeded in our endeavor, and were looking forward to getting back to the world of pure code.

See; we went DEC because the salesmen that came were down to earth, answered any questions we had, and had a good understandable set of documentation.
IBM came in thier primmed and preened suit and said "trust us...we'll be able to figure it out".But who delivered? The DEC promo was similar, but once the DECies infiltrated our ranks, it became obvious their affiliation was with Olsen, and they could have cared less about our mission-critical projects.
Originally Posted by Maksutov http://www.bautforum.com/images/buttons/viewpost.gif (http://www.bautforum.com/showthread.php?p=987402#post987402)
If similar nerds were heading up marketing, no wonder they failed. I can see the ad campaign:.I would agree there.Fer sure!

[NEOWatcher]

Where did I say I was going to chastise anybody that likes DEC?

Cite please.
Perhaps it's your definition of DECie vs Mine. Perhaps it's the fact that whatever is being mentioned in relation to DEC is a slam.
Yes; no direct cite, but in context, the feeling is coming across pretty loud.
30 is a good number for determining statistically significant results. The statistically significant results of our encounter with DEC was that they couldn't have cared less if we succeeded in our endeavor, and were looking forward to getting back to the world of pure code.
No; Your sample was ONE contract, ONE salesman. Was it also one location?
You could have been the victim of a money hole contract where the contractor uses yours as billable bench time.
But who delivered? The DEC promo was similar, but once the DECies infiltrated our ranks, it became obvious their affiliation was with Olsen, and they could have cared less about our mission-critical projects.
Sorry to hear that. Every one of our projects was smooth, no hitches, and very responsive. We ended up buying 3 seperate mainframes, and many workstations along with a networking project.
Plus; we went through a DEC distributer, and not DEC itself. Perhaps that was the difference.

[Maksutov]

[edit]Sorry to hear that. Every one of our projects was smooth, no hitches, and very responsive....No hitches, eh?

Tell you what.

Please provide me the user name and password to that alternative universe, and, in return, I'll make you rich.


http://img394.imageshack.us/img394/4879/iconbiggrin1kg.gif