Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Sometimes reluctant to put my developments live 1

Status
Not open for further replies.

gdrenfrew

Programmer
Aug 1, 2002
227
GB
The subject pretty much says it all.

I'm a developer with more than two years experience in a pretty solid environment with a small software house. I recently moved upscale to a City financial house and the environment is a shambles (which surprised me), with deadlines ensuring that we're firing out code as quick as possible, with little time to try and get the environment in better shape.

I'm used to having a solid test-bed and users to spend at least a couple of days making sure the software does what tehy want it to do...but in here it goes straight from DEV to LIVE with just a couple of developers giving it the once over.

For the past couple of months I've been working on some stuff that's to go live soon, and I'm petrified it's going to either fall on it's backside, or mess up sensitive financial data. I have no reason to think my code will cause problems, but because my confidence in the environment is low, I've started to have less confidence in the quality of what I'm producing. I try to test, using mirrors of the live data and stuff like that but I still worry.

Any developers/etc use mind-control techniques to keep their confidence up when it feels like they're walking the tightrope?

Test, test and test again?
graeme
 
Can't help you on making sure you sleep better at night, but I would make sure that, if you have expressed concern to your supervisor/manager/team lead about the lack of testing (developers should never test their own code), you have evidence of your expressing those concerns and their replies, if any.
 
You might try taking a break from the development process and create some testing procedures. For example here's is what I did on my current project. I took the back end SQL DB and made a copy and and gave it a new name and deleted all entries from specific tables. Then I wrote a little function that would take the last 20,000 records input and populate my forms one record at a time, then change the connection string to the new DB and fire the update event. After all 20,000 records have been input I have another function that takes and compares the 2 databases for discrepancies and generates a report with these exceptions. This is all done with a click of a button and really gives me some security that I didn't forget something or screw something up. Now this works for me because of the structure of my project, you might want to come up with something similar for yours. Good luck.

"Two strings walk into a bar. The first string says to the bartender: 'Bartender, I'll have a beer. u.5n$x5t?*&4ru!2[sACC~ErJ'. The second string says: 'Pardon my friend, he isn't NULL terminated'."
 
The only thing you can do is cover yourself. Just make sure everyone and their sisters know that you have low confidence in the test bed so you'll be covered if something goes awry.
 
ask the leaders what is the cost of downtime and get some figures from gartner or someone to show how a Model Office reduces downtime by X percent...

Cost of downtime time X percent = $$$$$ you can use to fund your Model office and then buddy you better show the results you promised... ;-)

JTB
Have Certs, Will Travel
"A knight without armour in a [cyber] land."

 
Thanks for the thoughts and advice.

Will flag up the lack of a decent test bed without looking like a spoilsport. And try and implement a better environment in my spare minutes.
 
Late response, I know, but I found the thread interesting.

The only thing you can do is cover yourself. Just make sure everyone and their sisters know that you have low confidence in the test bed so you'll be covered if something goes awry.

I disagree on the method. You cannot inform everyone of their worries because many times, they will change what you said into something that sounds far worse (accidentally or intentionally).

"I don't care for the environment" becomes "[so and so] doesn't like working here."

"I wish there was a better way to do this." becomes "[So and so] doesn't like how things are done here."

"I wish [random person] would help me test." becomes "[So and so] thinks [random person] wastes their time"

Things should always be brought to the bosses attention, first informally, though a verbal discussion... then, if needed, through formal memos such as memos... An informal approach at first is more comfortable.. they won't feel as offended... Directly to formality and they think you don't trust them.

Telling another person that can't help the issue won't solve anything but start a rumor mill. Its a hard learned lesson on how it works.

ALFII.com
---------------------
If this post answered or helped to answer your question, please reply with such so that forum members with a similar question will know to use this advice.
 
webmigit, I agree completely. That's a lesson I learned the hard way as well. Expressing misgivings within the team or to your supervisor is one thing, but never let any of that information out to the end users.

All of us tech-types know that everything has shortcomings, however trying to explain this to the end user to "manage expectations" is very tricky and usually ends up backfiring and making you look like a pessimist, unhelpful, uncooperative, etc. Also, any negative info you put out in advance tends to put people on guard and make them more actively look for flaws and be more critical than they might otherwise have been.


Jeff
The future is already here - it's just not widely distributed yet...
 
I like your signature Jeff.

I work in environments where I'm the sole IT guy.. and its not so bad having complete run of what I do... but as one user said.. Never test your own applications... that's very true.. I know exactly what won't break my applications and its hard to provide the constant conscious effort to ignore how it works and try other ways... see what happens.

Like the guy recently who, when one of my forms asked for a dollar amount he put 704.oo... I couldn't believe that..

And I understand the poster's misery.. It can be hard when you're placed with an unrealistic deadline... placing that application live can be something to dread.. Hackers are bad enough.. they're predictable at least, so you know what to watch for, but stupid people, that's a whole new ballgame, they'll put the wildest things in there.. so rather than any kind of reverse-engineering.. you've got unimaginable things going on.

Then you meet the "smart ones" now these are the guys who believe they're better at it than you are, and then they come up with lines like (referring to a simple function of one site I built.) "Most people aren't as vigilant as me, so they might miss it.".. Referring to something obvious.. What this means is that the person likely missed it the first time and can't believe they actually missed it.

As I said, expressing feelings to someone besides those involved opens you up for twisted words (deliberate or not).. mistrust with your colleagues and suspicion from your superiors.

I worked at a restaurant one time... for no other reason that I liked working there.. and one employee had done something to upset the management so the management took action... and the manager was explaining to someone who asked about how it was none of their business what happened... said person left the room and she started telling the rest of the employees what happend...

She then asked me me (privately), having no restaurant experience beyond.. grunt work.. what to do and I told her "I have an answer for you, but you won't get it out of me.. You lectured your people on what happens in management stays in management between all parties it involves.".

I just liked working up there. Programming by the week... kitchen grunt on the weekends.

ALFII.com
---------------------
If this post answered or helped to answer your question, please reply with such so that forum members with a similar question will know to use this advice.
 
Agree with the softly-softly approach. I don't like moaners who gripe and do nothing to improve the situation either, it just makes them look bad.

I've brought concerns up naturally in conversation about the lack
of any kind of formal spec and a decent test bed, so hopefully we'll get a spare server to use for that. Talking to the contractors at work they (politely and friendly) suggest I'm naive to think that software can be written and tested "the right way" (true OO where suitable etc etc,user testing blah blah).

I try and improve my end of the bargain by writing more robust code if time allows, and getting a colleague to test. I've got better as a designer and developer knowing that if I don't take it by the horns no one will.

Then have my CV all tidy ready to go when the sh1t starts flying!



 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top