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

 

[Onyxpurr]

I guess I've been really fortunate. I work for a company unit of 300 people and I think everyone one of them uses at least one of my apps.

They've been really good about finding bugs, REALLY good (lol), but are very understanding about the time it takes to fix them.

Usually I try to meet a plethera of times before testing, but there's alway one thing they left out. And one thing I've always noticed that if I'm programming and think, "I know they didn't say they wanted it, but it would be helpful to do", I'd better put it in there or else they will come back after implementation and ask for it.

 

[DonQuichote]

"There are no bugs, only undocumented features"


What's the difference? You still have a program that behaves in an unexpected way. And if it is unexpected for me as a developer, I'd nail it down with unit tests as fast as I could...

Best regards

 

[KornGeek]

My software never has bugs, although it occassionally has issues. The two are essentially the same, just without the negative connotation.

 

[NiteLink]

Reading things, I find that I commit mistakes too. :~/

I've done quite a bit of programming for about 3 years now and quite familiar with the coding. However, when I roll out my "finished" product on the launch date, users who have never seen it before would call and say that it's lacking some things or after a while of usage, they say that the data is not correct.

Usually, I test it and try to get 2nd opinion from my colleague who is a little more computer savvy and test my programmes. The suggestions usually work. However, I forget that there are some users who like to "hack" oops, "accidentally" rip the programme to pieces. I try to forecast what users would want to do. It's a good idea to have a user who don't know anything and try to use the programme and then I'll know how to place a counter-measure.

Fight?

What fight?

 

[rosieb]

korngeek
According to an old boss, mine (occasionally) has infelicities[/b].

 

[KornGeek]

One of the largest stresses in my job is when I do a presentation/testing session when my product is nearly ready to ship, and then get told that it needs to have certain features implemented. The frustrating part is that I often have to undo my own hard work because these features weren't requested initially.

To combat this, we are having a meeting tomorrow where we will be using a blank notepad instead of a computer and defining what features it needs. (I may even ask for emails to submit suggestions to avoid the "I mentioned that it should do that" that I often hear.) The rules will be:
1) If it's not requested at this meeting, it's not going in. (Although I know we'll violate this rule.)
2) Failure to participate in the meeting voids your rights to complain later.

I'm even considering getting signatures on the agreed-upon spec before beginning the coding.

A former co-worker (back in my days as an intern) had a sign on his cubicle wall that read "To write any computer program, begin by debugging a blank sheet of paper." I think it's time I return to the basics here.

rosieb
infelicities - I like that. I'll have to use it.

 

[rosieb]

I find getting a spec is often nigh on impossible. I usually go round all of the users, find out how they currently do the work, what they like / dislike about the current (ususlly paper) system, make suggestions etc. Then write it up and get it agreed. I still get feature creep, but usually not too serious. Signatures mean nothing.

A lot of my users don't really understand what technology is capable of, it's only when you show them a prototype that they start coming up with ideas.

Demanding a spec can be useful though, I have an outstanding request for an urgent report, I asked for a spec and... 2 months later, still waiting. Keeps my To Do list shorter.

KornGeek Hope your meeting tomorrow goes well. Rule 2 is a particularly good one.

(Another previous boss of mine, on being told we needed time for testing and removal of bugs demanded "Why are the programmers writing bugs into the software?&quot

 

[ecobb]

My boss is bad about having private meetings with the dept. heads to discuss what features they want in whatever I'm currently working on....and then forgetting to tell me about it! I don't mean forgetting to tell me about some of the features, he forgets to tell me he even had a meeting, much less what was discussed!

About 3 months ago, he went to one of our remote sites about 200 miles away. He called me up in the middle of the afternoon, wanting to know where our new online Operations Reporting system was and how he could get to it. I told him that, since it wasn't scheduled to be online for several more weeks, and I wasn't finished building it, there was no product online for him to see. He then informed me that "we" had decided to put it online several weeks early so that the district managers could look at it and decided if they wanted to make any changes before it went live. Turns out that him and another dept. head had driven 200 miles just to meet with the district managers to demo this program that did not yet exist. After a few minutes on the phone, he realized that the "we" who had decided this in a meeting did not include "me", and I had no way of knowing that they expected the program to be online because "he" had forgotten to tell "me" what "we" had decided to do.

Looking back on it, it's kinda funny (though it wasn't at the time). Unfortunately, he still forgets to tell me when "we" go to meetings.


Hope This Helps!

Ecobb
- I hate computers!

 

[Onyxpurr]

Usually I try to schedule a meeting with the requestor and I write out the specs. I then send to them for changes, draw up a prototype and send it back again for changes. Then I work up a rough draft, show it to them again for changes. This seems to work best for my customers.

I tried to get all the specs ahead of time, but it didn't work.

The worst is reporting specs. Mot users know how they want to do the data entry but not the reports. I even had a user (manager) tell me, "I trust whatever you create will cover all I need." I guess because I'm an analyst/programmer, but how frustrating!

 

[Sashanan]

I've only done one professional project thus far (and worked a bit on a second one originally made by somebody else), and I already notice very strongly what Onyxpurr mentions: they always know into the smallest details how they want to enter data - and it usually doesn't make sense how - but they know nothing about what's truly important, how the data comes out. You'd think they'd be more interested in what the system does for them than in if you go from one data entry field to the next with Tab or with Enter, and if the background is grey or yellow.

This customer's now seeing the results of their focus on unimportant things and their insistence on changing things that already worked. Not having a formal contract, I've worked here on the premise of "you get me 40 hours a week until the 20th October when my next job starts, and I work on what you want me to work on". And that's what I've done, changing layouts when whole new modules hadn't even been designed yet.


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

 

[flyboytim]

onyxpurr writes:
"The worst is reporting specs. Most users know how they want to do the data entry but not the reports."
This is the most difficult thing, because reporting actually defines the aims of the system. It also defines the table and relationship structure, and the queries needed, and then finally the data entry requirements, which can be made to look like the user wants the front end to look like and operate.
Many users/bosses want a tool like a database application because they think they need one, or someone else has one. Like a Ferrari. The user/boss needs to actually needs to spell out that they want a thing that is red, sexy and flashy and can go up to 160mph, and don't care what's under the bonnet or where to put the petrol and oil.
Defining data entry is useless if half the data entered is irrelevant to the final output. It just adds to the workload of the user and the time taken to run the system. And it will never be feasible to run it at 160mph, but it could...