Making mistakes

A pretty good description of the situation I found myself in a few years
ago. When I look back it is easy to recognize my own lack of experience and
my superior's lack of knowledge of what I am really doing.

We missed on almost everything possible, I was the only one to run and
manage the project, and at the same time I also had to run and manage a
different project going almost as bad.

You have to educate your management of what you are doing, of the
consequences of not doing it right. A failed project cost a lot in bug
fixing, but more interesting are the missed opportunities because of that.

--
/Thomas
thomas.eyde@eunet.no

Brian Copeland <bcopeland@frontlinefocus.com> wrote in message
news:39b94b2a@news.dev-archive.com...
> I have just realized that I am only human and therefore can make mistakes.
>
> In most of the programs I had made over the past year they have been bug
> free (well neglible anyway).
>
> Well the last program I made was during a very stressful time at work,
> things were changing, and chaos reigned. The program went live, and it
ran
> its course, and everything was fine in the land of Oz. However, we are
now
> doing analysis of the data retrieved, and found out due to errors in my
> code, a lot of information was missed and therefore saved the wrong
> information. I admit that I made the mistakes.
>
> However, now, there are many many grumblings from everyone about my
> incompetence, and inability to do a good job anymore. The fact is I work
> very very hard and have (and still do) produced many great easy-to-use
error
> free programs.
>
> What I want to know, does anyone out there make mistakes? No seriously
> though, does every company really expect their programmers to be perfect
100
> percent of the time?
>
> Since I am only human, I can't achieve this lofty goal, does anyone have
any
> advice to make myself as perfect as can be? I wrote this program rather
> quickly, but I did spend a lot of time debugging, correcting, and making
> sure all of the data entered was the same as the data saved, however, I
did
> miss a few things, that in code were very minor, but unfortunatley had
major
> ramifications.
>
> The company budget does not extend enough to hire another programmer to
> assist me (not that these programs are two people jobs anyway), and no one
> has the time to check my work, other than testing the user interface. No
> one wants to look into the databases,other than me. Its always a matter
of
> 'Is it done yet? Then install it and lets get going'. On occasions in
the
> past, with other programs I finish the coding and made to put the software
> live right away, where I am not even given any time to properly check for
> everything still stable and functional. Am I just making excuses about
the
> situation?
>
> What i want to know is for many of you programmers out there, do you have
> people to check your work? check data integrity and quality, etc? Or are
> you all alone on a long and dark highway hoping nothing falls apart when
the
> program goes live?
>
> I guess I am rambling a bit here. I can't achieve perfection, but can I
> expect the world to realize that I am only human?
>
> At wits end,
> Brian
>
>

Brian,

Since you mention that you are doing both the management and development
of the software, as I once have, you may wish to consider fact that you are
also Q/A and may not realize it. If you are not giving yourself adequate
time to audit your own software using a production type scenario then you
are cheating yourself. Don't rely on other people to tell you that your
program worked.

Producing fewer programs of higher quality will earn you the respect of your
peers faster than producing more programs of lesser quality.

Good Luck!
Matthew Jarboe

"Brian Copeland" <bcopeland@frontlinefocus.com> wrote:
>I have just realized that I am only human and therefore can make mistakes.
>
>In most of the programs I had made over the past year they have been bug
>free (well neglible anyway).
>

John,

Now you see the dilemma. I can't make myself perfect, but the company
cannot afford to have a permanent tester person to improve the process. I
realize that there is a problem (although everyone admits the problem is me
hehehe).

What can be done to improve the process? I have read Deborah Kurata's
GUID's plan, and follow it as best as I can but I am only one imperfect
person.

What do other companies do (where there is only one programmer/IT person) to
keep the quality of code high and the number of critical errors low, and
still remain cost effective?

"Strider" <jf_cantley@empowered.com> wrote in message
news:39bfd464$1@news.dev-archive.com...
> Everyone makes mistakes, the companies responsiblity is to provide help
with
> QA. QA, QA,QA, QA. I code and get things to work a certain way, if I
didn't
> have QA or at the very minimum other developers look at the results of
what
> I was doing, then the process is wrong and not the coder.
>
> John C
> Brian Copeland <bcopeland@frontlinefocus.com> wrote in message
> news:39b94b2a@news.dev-archive.com...
> > I have just realized that I am only human and therefore can make
mistakes.
> >
> > In most of the programs I had made over the past year they have been bug
> > free (well neglible anyway).
> >
> > Well the last program I made was during a very stressful time at work,
> > things were changing, and chaos reigned. The program went live, and it
> ran
> > its course, and everything was fine in the land of Oz. However, we are
> now
> > doing analysis of the data retrieved, and found out due to errors in my
> > code, a lot of information was missed and therefore saved the wrong
> > information. I admit that I made the mistakes.
> >
> > However, now, there are many many grumblings from everyone about my
> > incompetence, and inability to do a good job anymore. The fact is I
work
> > very very hard and have (and still do) produced many great easy-to-use
> error
> > free programs.
> >
> > What I want to know, does anyone out there make mistakes? No seriously
> > though, does every company really expect their programmers to be perfect
> 100
> > percent of the time?
> >
> > Since I am only human, I can't achieve this lofty goal, does anyone have
> any
> > advice to make myself as perfect as can be? I wrote this program rather
> > quickly, but I did spend a lot of time debugging, correcting, and making
> > sure all of the data entered was the same as the data saved, however, I
> did
> > miss a few things, that in code were very minor, but unfortunatley had
> major
> > ramifications.
> >
> > The company budget does not extend enough to hire another programmer to
> > assist me (not that these programs are two people jobs anyway), and no
one
> > has the time to check my work, other than testing the user interface.
No
> > one wants to look into the databases,other than me. Its always a matter
> of
> > 'Is it done yet? Then install it and lets get going'. On occasions in
> the
> > past, with other programs I finish the coding and made to put the
software
> > live right away, where I am not even given any time to properly check
for
> > everything still stable and functional. Am I just making excuses about
> the
> > situation?
> >
> > What i want to know is for many of you programmers out there, do you
have
> > people to check your work? check data integrity and quality, etc? Or
are
> > you all alone on a long and dark highway hoping nothing falls apart when
> the
> > program goes live?
> >
> > I guess I am rambling a bit here. I can't achieve perfection, but can I
> > expect the world to realize that I am only human?
> >
> > At wits end,
> > Brian
> >
> >
>
>

> What do other companies do (where there is only one programmer/IT person)
to
> keep the quality of code high and the number of critical errors low, and
> still remain cost effective?

I'm a single programmer ( I wish I had team programming experience :-(... )

Are you using new techniques/technologies in this project?

I try to implement small, low-risk applications with new technologies before
trusting myself with critical applications :-)

Brian,

I have a CYA suggestion that you may or may not already be doing. It sounds
like you thoroughly test your programs but you don't get much help from the
users other than does the screen look appealing. What I would suggest is
you make a thorough test plan consisting of scenarios or test cases. Better
yet sit with the users and come up with scenarios, as many as you can. Along,
with that document what the end results of those scenarios should be in terms
of your softwares output. Once you have the scenarios documented I would
then require that the users sign off on them as they are testing.

Having the scenarios and having your users sign off on them does 2 things.
First, it covers your behind if things go wrong because the users would
be as much to blame as you are. Second, it gives them a sense of ownership
in the application and therefore more at stake. If they are unwilling to
do this I think it may be time to start searching for another job.

I've had similar problems in the past and the best policy for this is to
CYA. I'll finish by saying this is just one of the many techniques I've
picked up in my career. Another is to make abundantly clear to the business
area the implications of doing or not doing something. This includes testing.
What it all boils down to is CYA and a lot of times this means documenting
as much as you can. Often times I will email someone just so I have proof
of what I talked to them about.

Well, that's my 2 cents, I hope it's worth more than that to you.

N. Hanson, MCSD

"Brian Copeland" <bcopeland@frontlinefocus.com> wrote:
>I have just realized that I am only human and therefore can make mistakes.
>
>In most of the programs I had made over the past year they have been bug
>free (well neglible anyway).
>
>Well the last program I made was during a very stressful time at work,
>things were changing, and chaos reigned. The program went live, and it
ran
>its course, and everything was fine in the land of Oz. However, we are
now
>doing analysis of the data retrieved, and found out due to errors in my
>code, a lot of information was missed and therefore saved the wrong
>information. I admit that I made the mistakes.
>
>However, now, there are many many grumblings from everyone about my
>incompetence, and inability to do a good job anymore. The fact is I work
>very very hard and have (and still do) produced many great easy-to-use error
>free programs.
>
>What I want to know, does anyone out there make mistakes? No seriously
>though, does every company really expect their programmers to be perfect
100
>percent of the time?
>
>Since I am only human, I can't achieve this lofty goal, does anyone have
any
>advice to make myself as perfect as can be? I wrote this program rather
>quickly, but I did spend a lot of time debugging, correcting, and making
>sure all of the data entered was the same as the data saved, however, I
did
>miss a few things, that in code were very minor, but unfortunatley had major
>ramifications.
>
>The company budget does not extend enough to hire another programmer to
>assist me (not that these programs are two people jobs anyway), and no one
>has the time to check my work, other than testing the user interface. No
>one wants to look into the databases,other than me. Its always a matter
of
>'Is it done yet? Then install it and lets get going'. On occasions in
the
>past, with other programs I finish the coding and made to put the software
>live right away, where I am not even given any time to properly check for
>everything still stable and functional. Am I just making excuses about
the
>situation?
>
>What i want to know is for many of you programmers out there, do you have
>people to check your work? check data integrity and quality, etc? Or are
>you all alone on a long and dark highway hoping nothing falls apart when
the
>program goes live?
>
>I guess I am rambling a bit here. I can't achieve perfection, but can I
>expect the world to realize that I am only human?
>
>At wits end,
>Brian
>
>

I just love the "secretary beta" idea.

At the last shop I worked at we did pretty much the same thing. I
was the only programmer at the branch and the entire office only
had 4 people (manager, secretary, business developer and me).
When the secretary wasn't "busy" or during a crunch when I really
needed someone to test my app, she would always test it.

This does provide a wonderful means for beta testing, because
secretaries are generally completely out of the loop when it
comes to "what is the application supposed to do" - so you can
find those little bugs that nobody that knew what they were doing
would have found (there's probably a lot of these). But
secretaries are often unfamiliar with the terminology so *you*
have to learn "secretary-speak" in order to figure out what she
means when she thinks there's a bug.

I can't remember how many times she told me to "give her the next
screen" - I was sure this meant she needed screen-shots of the
forms for a brochure/promo. After having to explain to her what
to "do" with a JPG or BMP I tried sending her an EXE once and
suddenly she was satisfied. If she's competent with computers you
probably won't hear a lot of the stuff I did (like "how do I
close the application?" (you could try the "x" in the top right
corner or "File>Exit") and "how do I save" (maybe the button that
says "Save", the big floppy disk on the toolbar or "File>Save")).
She did help me find a few nasty little bugs though. I found
after about 3 months of her "testing" for me, that it was easier
to use a logging system with EXACT date and time of events and
dump ActiveForm properties every "x" seconds than to try to
interpret her very "interesting" descriptions of problems she
found. I made a "bug report" form which I instructed her to
record the exact time (from the system tray) that the error
occured.

Good luck,

Shawn K. Hall
Please post/respond *only* in the newsgroups

"Strider" <jf_cantley@empowered.com> wrote in message
news:39c0f94d$1@news.dev-archive.com...

> My recommendation would be to use other employees to test the
results of
> your coding. I had a secretary I used at one place that was a
world of help.
> She would do my testing for me. Watching the errors she was
making
> strengthened my UI and then she would validate the results for
me. The only
> way to create a bug free application without having a QA person
is to use
> people in the company that will be using the application.
>
> John Cantley

Hi Brian,

I've work as a contractor for a long time now, so I may be a bit more
experienced than most at doing the CYA bit. At the start of the project
I point out to the user that they are the expert in the particular business
area and that they must test and approve the programs before they go
into production (including a formal signing off), if they are not prepared
to do this, then I simply will not get involved!

Regards,

James.

"Brian Copeland" <bcopeland@frontlinefocus.com> wrote in message
news:39b94b2a@news.dev-archive.com...
> I have just realized that I am only human and therefore can make mistakes.
>
> In most of the programs I had made over the past year they have been bug
> free (well neglible anyway).
>
> Well the last program I made was during a very stressful time at work,
> things were changing, and chaos reigned. The program went live, and it
ran
> its course, and everything was fine in the land of Oz. However, we are
now
> doing analysis of the data retrieved, and found out due to errors in my
> code, a lot of information was missed and therefore saved the wrong
> information. I admit that I made the mistakes.
>
> However, now, there are many many grumblings from everyone about my
> incompetence, and inability to do a good job anymore. The fact is I work
> very very hard and have (and still do) produced many great easy-to-use
error
> free programs.
>
> What I want to know, does anyone out there make mistakes? No seriously
> though, does every company really expect their programmers to be perfect
100
> percent of the time?
>
> Since I am only human, I can't achieve this lofty goal, does anyone have
any
> advice to make myself as perfect as can be? I wrote this program rather
> quickly, but I did spend a lot of time debugging, correcting, and making
> sure all of the data entered was the same as the data saved, however, I
did
> miss a few things, that in code were very minor, but unfortunatley had
major
> ramifications.
>
> The company budget does not extend enough to hire another programmer to
> assist me (not that these programs are two people jobs anyway), and no one
> has the time to check my work, other than testing the user interface. No
> one wants to look into the databases,other than me. Its always a matter
of
> 'Is it done yet? Then install it and lets get going'. On occasions in
the
> past, with other programs I finish the coding and made to put the software
> live right away, where I am not even given any time to properly check for
> everything still stable and functional. Am I just making excuses about
the
> situation?
>
> What i want to know is for many of you programmers out there, do you have
> people to check your work? check data integrity and quality, etc? Or are
> you all alone on a long and dark highway hoping nothing falls apart when
the
> program goes live?
>
> I guess I am rambling a bit here. I can't achieve perfection, but can I
> expect the world to realize that I am only human?
>
> At wits end,
> Brian
>
>

Hi Brian,

Even so, your user should be able to take some of this 'manual' data,
calculate
what the expected out put should be and then pump it through your system to
check
that it's producing the right out put..... Users can always come up with a
1000
reasons why they can't test a system - their decision not to test a system
is their
responsibility not yours.

Best Regards,

James.

"Brian Copeland" <bcopeland@frontlinefocus.com> wrote in message
news:39c61b1e@news.dev-archive.com...
> Hi James,
>
> Thanks for the advice...once I figured out what CYA meant heheh.
>
> Seriously though, I understand what you are doing. However, you are
> entering an environment where essentially you are either automating an
> existing system or updating an existing system, hence having experts in
the
> field, as it were.
>
> My place of employ doesn't work that way. I get a copy of the survey and
> have to create a user interface (and database) for the telephone agents to
> use. However, 99/100 times the agent is given the same survey when i
start
> programming the UI. During this time, the survey is done 'manually', and
> kept on paper, until the UI is done and the users then will enter in the
> 'manual' surveys. Then everything goes live on the telephones. There
isn't
> an 'expert' in place to say this is how the program should go, or this is
> what th eprogram should have. I have to program based completely on the
> appearance of the survey given to me.
>
> I can try using the CYA sign off system, so at least if I have to go down
,
> everyone else is coming down with me <G>
>
>
> "James Dooley" <james@siteknowhow.com> wrote in message
> news:39c61029$1@news.dev-archive.com...
> > Hi Brian,
> >
> > I've work as a contractor for a long time now, so I may be a bit more
> > experienced than most at doing the CYA bit. At the start of the project
> > I point out to the user that they are the expert in the particular
> business
> > area and that they must test and approve the programs before they go
> > into production (including a formal signing off), if they are not
prepared
> > to do this, then I simply will not get involved!
> >
> > Regards,
> >
> > James.
> >
> > "Brian Copeland" <bcopeland@frontlinefocus.com> wrote in message
> > news:39b94b2a@news.dev-archive.com...
> > > I have just realized that I am only human and therefore can make
> mistakes.
> > >
> > > In most of the programs I had made over the past year they have been
bug
> > > free (well neglible anyway).
> > >
> > > Well the last program I made was during a very stressful time at work,
> > > things were changing, and chaos reigned. The program went live, and
it
> > ran
> > > its course, and everything was fine in the land of Oz. However, we
are
> > now
> > > doing analysis of the data retrieved, and found out due to errors in
my
> > > code, a lot of information was missed and therefore saved the wrong
> > > information. I admit that I made the mistakes.
> > >
> > > However, now, there are many many grumblings from everyone about my
> > > incompetence, and inability to do a good job anymore. The fact is I
> work
> > > very very hard and have (and still do) produced many great easy-to-use
> > error
> > > free programs.
> > >
> > > What I want to know, does anyone out there make mistakes? No
seriously
> > > though, does every company really expect their programmers to be
perfect
> > 100
> > > percent of the time?
> > >
> > > Since I am only human, I can't achieve this lofty goal, does anyone
have
> > any
> > > advice to make myself as perfect as can be? I wrote this program
rather
> > > quickly, but I did spend a lot of time debugging, correcting, and
making
> > > sure all of the data entered was the same as the data saved, however,
I
> > did
> > > miss a few things, that in code were very minor, but unfortunatley had
> > major
> > > ramifications.
> > >
> > > The company budget does not extend enough to hire another programmer
to
> > > assist me (not that these programs are two people jobs anyway), and no
> one
> > > has the time to check my work, other than testing the user interface.
> No
> > > one wants to look into the databases,other than me. Its always a
matter
> > of
> > > 'Is it done yet? Then install it and lets get going'. On occasions
in
> > the
> > > past, with other programs I finish the coding and made to put the
> software
> > > live right away, where I am not even given any time to properly check
> for
> > > everything still stable and functional. Am I just making excuses
about
> > the
> > > situation?
> > >
> > > What i want to know is for many of you programmers out there, do you
> have
> > > people to check your work? check data integrity and quality, etc? Or
> are
> > > you all alone on a long and dark highway hoping nothing falls apart
when
> > the
> > > program goes live?
> > >
> > > I guess I am rambling a bit here. I can't achieve perfection, but can
I
> > > expect the world to realize that I am only human?
> > >
> > > At wits end,
> > > Brian
> > >
> > >
> >
> >
>
>

Good luck!

James

"Brian Copeland" <bcopeland@frontlinefocus.com> wrote in message
news:39c764f2@news.dev-archive.com...
> "James Dooley" <james@siteknowhow.com> wrote in message
> news:39c6ff7a@news.dev-archive.com...
> > Hi Brian,
> >
> > Even so, your user should be able to take some of this 'manual' data,
> > calculate
> > what the expected out put should be and then pump it through your system
> to
> > check
> > that it's producing the right out put..... Users can always come up
with
> a
> > 1000
> > reasons why they can't test a system - their decision not to test a
system
> > is their
> > responsibility not yours.
>
> Thanks for the advice James...i will implement it on the next project.
>
>

I'm a former long-time contractor. My position has always been to
get a *reasonable* set of requirements and some representative
(e.g. it's the customer's responsibility) test cases. Then we
beta test the system for a set period of time, and I have them
sign off on the system.

It's the customer's responsibility to determine whether the code
is creating *correct* results. I can only test against what I
know, and I'm certainly not the domain expert. It's usually the
fault of over-eager client managers, who are under the gun to
deliver.

I also cover my *** by keeping EVERY bit of email correspondence
between myself and the client. I document EVERY known issue, and
make sure I have multiple emails stating the issue, and what
information they need to supply, and haven't.

doug

"James Dooley" <james@siteknowhow.com> wrote:
>Hi Brian,
>
>I've work as a contractor for a long time now, so I may be a bit more
>experienced than most at doing the CYA bit. At the start of the project
>I point out to the user that they are the expert in the particular business
>area and that they must test and approve the programs before they go
>into production (including a formal signing off), if they are not prepared
>to do this, then I simply will not get involved!
>
>Regards,
>
>James.
>
>"Brian Copeland" <bcopeland@frontlinefocus.com> wrote in message
>news:39b94b2a@news.dev-archive.com...
>> I have just realized that I am only human and therefore can make mistakes.
>>
>> In most of the programs I had made over the past year they have been bug
>> free (well neglible anyway).
>>
>> Well the last program I made was during a very stressful time at work,
>> things were changing, and chaos reigned. The program went live, and it
>ran
>> its course, and everything was fine in the land of Oz. However, we are
>now
>> doing analysis of the data retrieved, and found out due to errors in my
>> code, a lot of information was missed and therefore saved the wrong
>> information. I admit that I made the mistakes.
>>
>> However, now, there are many many grumblings from everyone about my
>> incompetence, and inability to do a good job anymore. The fact is I work
>> very very hard and have (and still do) produced many great easy-to-use
>error
>> free programs.
>>
>> What I want to know, does anyone out there make mistakes? No seriously
>> though, does every company really expect their programmers to be perfect
>100
>> percent of the time?
>>
>> Since I am only human, I can't achieve this lofty goal, does anyone have
>any
>> advice to make myself as perfect as can be? I wrote this program rather
>> quickly, but I did spend a lot of time debugging, correcting, and making
>> sure all of the data entered was the same as the data saved, however,
I
>did
>> miss a few things, that in code were very minor, but unfortunatley had
>major
>> ramifications.
>>
>> The company budget does not extend enough to hire another programmer to
>> assist me (not that these programs are two people jobs anyway), and no
one
>> has the time to check my work, other than testing the user interface.
No
>> one wants to look into the databases,other than me. Its always a matter
>of
>> 'Is it done yet? Then install it and lets get going'. On occasions in
>the
>> past, with other programs I finish the coding and made to put the software
>> live right away, where I am not even given any time to properly check
for
>> everything still stable and functional. Am I just making excuses about
>the
>> situation?
>>
>> What i want to know is for many of you programmers out there, do you have
>> people to check your work? check data integrity and quality, etc? Or
are
>> you all alone on a long and dark highway hoping nothing falls apart when
>the
>> program goes live?
>>
>> I guess I am rambling a bit here. I can't achieve perfection, but can
I
>> expect the world to realize that I am only human?
>>
>> At wits end,
>> Brian
>>
>>
>
>

Brian, you've gotten some good advice so far, but I'd like to add a couple
of points.

You have the right to expect your employer to provide you with clearly defined
specs for input and output. If it doesn't arrive up front, you need to ask
for a meeting to clarify things before you can continue.

(Your employer would probably prefer to dodge this, but this is where you
define your limits as a programmer--that you can climb tall buildings but
you need a rope and tools, you can't simply leap them with a single bound.
If you generally preface your "buts" with a spoken indication that you want
to provide the best possible results for them, you may get a little minor
grumbling, but you should avoid any real annoyance on their part.)

At this meeting, you take the specs and redefine them. To use a biology
example, if your employer says "horse", be sure to rule zebras either in
or out by asking whether it's OK for a "horse" to have stripes.

Your employer will most likely have no idea that there is any other meaning
for the word "horse" than what he/she initially had in mind, so the job of
finding extreme examples to test the limits of the terms falls on you.

If your employer isn't willing to do this, then "just say no". Or try the
gimmick of saying (as often as necessary) that "After we get our terms defined,
I will be able to start."

I am also a lone programmer (although I do get some serious help with the
debug process from users). There is one other (so far) unmentioned hazard
with this, however.

As a physics person programming for the insurance industry, I frequently
need to request definitions of specialized business terms. For example,
the terms "loss pick" and "loss fund" mean absolutely nothing to me. I expect
my employer to have someone generally available to provide me with speedy
definitions of business terms.

The glitch happens when a different group of users, who will also be using
the program, use one of the terms differently. (In the case above, the two
terms have been reversed!!!)

Coleen Christensen

"Brian Copeland" <bcopeland@frontlinefocus.com> wrote:
>I have just realized that I am only human and therefore can make mistakes.
<snip> but can I
>expect the world to realize that I am only human?
>
>At wits end,
>Brian
>
>

"Brian Copeland" <bcopeland@frontlinefocus.com> wrote:
>
>I guess I am rambling a bit here. I can't achieve perfection, but can I
>expect the world to realize that I am only human?
>
>At wits end,
>Brian
>
>

Brian:

I can totally sympathize with your situation. I have been there before it
isn't fun. I have two pieces of advice for you. The first piece of advice
is something I read in a programming book somewhere, but I don't remember
exactly where (possibly _Code Complete_?). The best programmers out there
are humble programmers. That is, they realize that they are far from perfect,
so they go to great lengths to check, double-check, and triple-check themselves.
They comment their code so that they can understand it when they come back
to it in 6 months. They add in extra error checking to catch things that
might go wrong. They retest their code when they make even the smallest
change. They run their code in the debugger so they can make sure everything
gets set the way they expect. Programmers who aren't humble are more likely
to play it "fast and loose" thus they end up with poorly written code that's
filled with bugs. So take heart... realizing that you aren't perfect is
a good step toward becoming a better developer.

Second, your superiors need to be educated in what it takes to write good
software. They need to realize that time and money needs to be devoted to
things like analysis, design, and testing. It's up to you to educate them
that these things are part of the software development process, and not just
afterthoughts. If they expect you to produce bug-free software, you should
expect them give you the tools to make this possible. They may not be "technical"
people, so you may have to educate them on what you need to be successful.
At first, they may balk saying that these things are a waste of time and
money, in which case you can point how how much of time and money was wasted
on buggy software that was rushed into production. If they still don't buy
it...well...there are plenty of employers out there whose environment is
a lot more supportive...

On a more practical note, if you haven't already, you should install some
sort of version control tool like Visual SourceSafe, and some sort of bug
tracking tool. Again, you may need to educate your superiors in the value
of these items, but in the long run, these things will save you a LOT of
time and effort.

"Brian Copeland" <bcopeland@frontlinefocus.com> wrote:
>"David K." <dgkroll@hotmail.comNOSPAM> wrote in message
>news:39de5745$1@news.dev-archive.com...
>> Second, your superiors need to be educated in what it takes to write good
>> software. They need to realize that time and money needs to be devoted
to
>> things like analysis, design, and testing. It's up to you to educate
them
>> that these things are part of the software development process, and not
>just
>> afterthoughts. If they expect you to produce bug-free software, you
>should
>> expect them give you the tools to make this possible. They may not be
>"technical"
>> people, so you may have to educate them on what you need to be successful.
>> At first, they may balk saying that these things are a waste of time
and
>> money, in which case you can point how how much of time and money was
>wasted
>> on buggy software that was rushed into production. If they still don't
>buy
>> it...well...there are plenty of employers out there whose environment
is
>> a lot more supportive...
>>
>
>I had this talk with the powers that be, and they agree...but right now
the
>crunch for a deliverable isn't on. The same thing happened with the project
>I mentioned having the problem. They checked the UI once, said it was
fine
>(and it was), no one would bother to check the database to see if the data
>entered was the same as the data saved. And as I said, I did make a few
>errors, so the data wasn't right. Before the project was launched I said
>this needs to be thorougly (sp?) tested. Everyone agreed. I put the
>program on a few test machines. All of the data for the program was being
>taken manually, on paper until the computerized version was completed.
I
>told them to test it out, use the paper versions, enter them in, and if
what
>comes out is the same as what goes on, we are ready to go. I checked the
>database the next day, not one bit of data was entered, and when approached
>about it, everyone (including my boss) said it was a waste of time entering
>this gathered data, if they were going to have to enter it again anyway,
>when the program is 'live'. So even though everyone was gung ho to get
the
>program going, no one wants to check my work, because basically to everyone
>its _my_ work.
>

One thing has always confused me about managers who say, "Forget testing...
we don't have time for that. Just ship it...". Sure you may put the product
into production sooner, but you end up wasting even more time dealing with
production problems that always crop up due to poor quality. In the end,
you probably end up wasting time by rushing! Besides, as you've seen, when
something doesn't go right, it's YOUR neck, not theirs, so it's worth fighting
for more time and better processes. If they don't give it to you, update
your resume and move on. You don't deserve that kind of treatment.

>> On a more practical note, if you haven't already, you should install some
>> sort of version control tool like Visual SourceSafe, and some sort of
bug
>> tracking tool. Again, you may need to educate your superiors in the value
>> of these items, but in the long run, these things will save you a LOT
of
>> time and effort.
>
>This is a good idea...thanks for the advice. What are some good bug
>tracking tools?
>

I've used TeamTrack which is a highly configurable, web based tracking system.
Also, there's a product that I've started to use called "Bugzilla" which,
I believe, is a free bug tracking tool from Mozilla.

"Brian Copeland" <bcopeland@frontlinefocus.com> wrote:
>
>I went to the Mozilla page and checked out Bugzilla...all I can gather from
>it is that it is a bug report facility for Mozilla products. I can't seem
>to find a downloadable version for non-Mozilla projects.
>
>Where can I find TeamTrack? Do they have an evaulation version?
>
>Brian
>
>

Bugzilla is used for Mozilla products; however, it is open source so you
can download a copy for your own use. Go to www.mozilla.org/bugs/source.html
for info on downloading it.

As far as TeamTrack goes, the name of the company that makes it is called
TeamShare. Again, I dont' have the URL in front of me but I think it's www.teamshare.com.
If that's not it, I'm sure you can find it by doing a web search.