It's stressy being a developer...

[LucieLastic]

hi All

My better half has started doing VB in Excel and came home from work the other day and said "it's really stressful putting a release of software out" - he had to distribute his spreadsheet (with embedded VB) to all the appropriate people.

He said errors kept occurring (it was his initial release) - I could just see it: users sat there huffing and puffing, and shaking fingers at their pcs, swearing ...they're not very understanding. Then there's that sinking feeling and sweaty palms.

He's also not a programmer by trade and is teaching himself VB, doing this extra VB stuff to help everyone out, so he's actually going out of his way, somewhat. A few times he's wanted to defenestrate his computer during the development process (I know the feeling).

Yeah, he's right but I just took it in my stride really, that's programming for you, be it writing code or designing/managing databases.

I wish that some of these impatient users would give us programmers(and DB people) some thought instead of whining and complaining, calling our bit of creativity 'a piece of crap' because it doesn't align a title or something. These also tend to be the people who aren't very helpful when it comes to trying to replicate the error...'I pressed that button and it crashed, it's crap!, I'm getting a coffee...'.

Sometimes, I just get the impression that anyone directly involved in building & releasing a new system is not really appreciated by some(not all) users - maybe these users need defenestrating

The other users, though, are brilliant and try to help wherever they can, by being patient and constructive - those people are on my Christmas card list

lou

 

[benlinkknilneb]

One way to prevent this is extensive testing by several people who aren't related to the project's development before releasing it to the ingrates. Usually we try to find the least computer-savvy person who will need to use the program and sit down with them before finally releasing... that way we know it's as idiot-proof as possible when it's ready to go. Don't get anyone who knows about computers to test it for you... they'll miss the stupid things that you and I as developers take for granted, but the average user would not comprehend. They're a lot less likely to call it 'crap' if you allow them to think they're helping you develop it which is the kind of image I try to portray to "my" users. I treat them as the expert on the business procedure and myself as the computer guy who needs to understand it in order to make their work go faster... and it's worked so far.

Ben

"If thine enemy offend thee, give his child a drum." - Anonymous

 

[LucieLastic]

You're absolutely right, Ben.

There's one user that sticks in my mind, though, and she'd take every opportunity to rip the new system to pieces and stop it's progress, as she loved her Dos based system and didn't want to change to windows. She was the user delegated to me to help me develop and test the windows version. She actually left the company in the end.

lou

 

[CajunCenturion]

The only question about what has been posted thus far is in the original phrase My better half has started. Sounds like you may have that part reversed weez.

Quality control is the not the strength of most developers, and we do need help in that area, especially from people who are not part of the development team. Developers tend to test the system by using in the manner in which it was designed to be used, and not from the perspective of how the user will employ it.

I've always tried to include as part of the QA phase and handful of the user who will use the system day to day. As you watch them, rather than ask yourself, "Why would they do it that way?", you need to ask, "How can we make it work for them that way?"

Let's hope that your "users" work in a tall, real tall, building. :-D

Good Luck
--------------
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein

 

[Sashanan]

I find myself in the lucky position of having one user who is somewhat computer savvy (just enough to understand the difficulties in developing software and the inevitability of lots of bugs in the initial release), but very picky. If there's a bug in there, chances are he'll root it out, and I've been able to teach him the importance of figuring out under what conditions it takes place. I do my testing in three phases now:

- My own testing, which obviously removes only the very obvious errors;
- His tests, which go a long way to solving things I, as the developer, would overlook;
- The public test involving the less helpful users, who hopefully have little trouble left to find.

This is but a small company, but even here I'm learning the value of having an "ally" in every department involved in using your program, one you approach more personally than the rest, and who can be that bridge between the developer who doesn't find the errors (you) and the users who find them but fail to describe them in a way that's helpful to you, but instead fall into the common "it doesn't work so what's there to test?" reaction. (Not to mention that their definition of "it doesn't work" can range from anything to fatal errors to a text field not aligning their way, or a program working fine according to the agreed upon specs but not in the way *they* expected!)

In larger environments, which I don't yet have practical experience in, I can only assume that having such allies is even more important.


"Much that I bound, I could not free. Much that I freed returned to me."
(Lee Wilson Dodd)

 

[grtammi]

Build your software with catch-alls. I tell users all the time that the software works fine; what's acutally occured is a situation that they didn't tell me about. We then iron out the wrinkles and go from there.

I've found the best way to develop anything, software included, is to get AT least 3 different people that are going to use your software, and have them each write out independently what THEY expect the software to do for them. Quite often than not, you'll see different things for different users. Combine all 3 things into a master list, and then come back to those users with your interpretation before development begins.

I think it's a little bit less stressful than designing something, then having your users come back at you and say "This isn't what I wanted!" ... and you say "That's what you told me!"

*sigh* If only administration people spoke programmer ... lol ... guess it has to work the other way around though.

"It's kinda fun to do the impossible." - Albert Einstein


Boss quote from an office meeting: We're going to continue to have these meetings until we figure out why no work is getting done ...

 

[LucieLastic]

hi grtammi

lol, like this:
'Boss quote from an office meeting: We're going to continue to have these meetings until we figure out why no work is getting done ...'

..does he have pointed hair by any chance?

lou

 

[rosieb]

I sometimes offer bribes to find the "deliberate" mistake, occasionally it even works. But the key, as previously said, is to find the right users.

 

[grtammi]

weez:

I got that boss quote from a calendar of one of my co-workers ... I have a couple other goods ones at my desk ... maybe I'll post them when I get there tomorrow.

Greg


Boss quote from an office meeting: We're going to continue to have these meetings until we figure out why no work is getting done ...

 

[DonQuichote]

To prevent errors, you can write unit tests. Unit tests are a kind of test-bench for classes and routines.

Look at

http://www.xprogramming.com/software.htm

for unit test frameworks for various programming languages. I can tell you that it is good medicine against stress...

If you want to read more about this, search the net for "test driven development" and "extreme programming".

Best regards

 

[Kavius]

I sometimes offer bribes to find the "deliberate" mistake, occasionally it even works. But the key, as previously said, is to find the right users[/qoute]

Doing some contract work individually, I was promised "full co-operation" in the testing phase. I just mentioned that there is no way I could possibly know what was going through their heads, so there was no way I could use the system the way they did. They promised me that they would find at least one person from each user group to run through the system.

I wanted to make sure I had my rear covered on the debugging thing (didn't want: "it worked fine when we tested it. what did you do?&quot so I inserted a couple bugs that should have been really obvious, as well as put in place a login/logout log.

Sure enough, come close to release time there was no data in the application, 1 of the 3 test users had logged in for about 30 seconds, and no bugs had been found. I went and asked when testing was going to take place as the deadline was coming soon. Sure enough, "it has happened and we are satisfied".

I was tempted to let them go forward and release the software as it was. Instead I informed the company of all of the evidence that I had that no testing had taken place (this was especially embarassing for my contact who was one of the test users that had not logged in and had just finished telling me that the software worked fine). I also reminded them that the testing was in the contract, and that I could not be held responsible for bugs that weren't looked for.


I gave them a deadline for testing. The did a bit, but the system got release with what I considered inadequate testing. Sure enough bugs were found and I billed them for every fix and functionality change.

I still do business with them, but they are a lot more co-operative when it comes to testing.

 

[Tarwn]

The problem with finding the most computer illiterate person for doing your testing isn't that they find all the bugs, it's the hour it takes explaining how to install it that bugs me the worst

"Ok Unzip both files"
"I got this error '_____ DLL not found'"
"Did you unzip both files?"
"No, I only had time to debug one"
"Ok, (sigh) unzip both files"
...

[sub]01000111 01101111 01110100 00100000 01000011 01101111 01100110 01100110 01100101 01100101 00111111[/sub]
The never-completed website:

http://www.tiernok.com/

 

[Sashanan]

Computer literacy and the ability to follow instructions do not necessarily go hand in hand, though. I've got a couple of users who'd have trouble finding a folder on the network without help, but when you tell them what to do, they do it.

On the other hand I know plenty of people who know their computers quite a bit better (and I must shamefully admit to being one of them sometimes), who don't follow the instructions properly and are then surprised when it doesn't work.

The truly dangerous user is the one who *thinks* he knows what he's doing and starts making the wrong decisions because of it. I prefer the ones who know nothing, are aware they know nothing, and don't touch what they don't know about.



"Much that I bound, I could not free. Much that I freed returned to me."
(Lee Wilson Dodd)

 

[ecobb]

I build/manage a large WAN Intranet. If you want some computer illiterate people for testing, buddy I've got 'em! My personal favorite was a guy who couldn't log in, so I went to see what he was doing. I have all usernames set up as the person's name, so it should be easy for them to remember, right? Each time a user enters an invalid login, it returns to the login box to force them to enter in the username and password again (Note: it doesn't save the username, they must retype it). I watched this guy consistantly misspell his own name 10+ times before I had to finally break down and tell him that he was leaving the "L" out!

I have another person who, about twice a week, decides that there is supposed to be a ".com" after his username, so he tries to log in as "hisname.com". Guess what...it doesn't work!

Oh, well...it's things like this that make the job interesting...

Hope This Helps!

Ecobb
- I hate computers!

 

[benlinkknilneb]

Excellent solution, kavius! Wish I could have been there to watch them "open mouth, insert foot"... and I guess you made a little extra money off their mistake, too. I'll definitely have to try that one...

Ben

"If thine enemy offend thee, give his child a drum." - Anonymous

 

[BakeMan]

When it comes to testing I am responsible for all of my own testing. This inevitably leads to a few things getting overlooked. So I have adopted the philosophy that:

"There are no bugs, only undocumented features"

It has worked well for me. After informing the client that the non-function component they have just located is not really a bug, but simply an undocumented feature, they begin to laugh and usually are good about providing me with the proper requirements and time to correct the issue.

BAKEMAN

 

[CajunCenturion]

"There are no bugs, only undocumented features"

You must work for Microsoft BakeMan.

Good Luck
--------------
As a circle of light increases so does the circumference of darkness around it. - Albert Einstein

 

[Kavius]

No, that's a Torvald thing. It's gotta be.

 

[sleipnir214]

No, I don't think it's a Torvalds quote. It'd be kinda hard to have an undocumented feature when anyone with a text editor can examine your source code.

Want the best answers? Ask the best questions:

http://www.catb.org/~esr/faqs/smart-questions.html

TANSTAAFL!!

 

[Kavius]

I mean the attitude behind it. 10,000 emails stating that there is a bug found...
[tt]
No, no, no, that's intentional, its just not complete, who wants to tweak it for me...
[/tt]