|
It's called "random features"! 
Why can't I be applicable like John? - Me, April 2011
-----
Beidh ceol, caint agus craic againn - Seán Bán Breathnach
-----
Da mihi sis crustum Etruscum cum omnibus in eo!
-----
Just because a thing is new don’t mean that it’s better - Will Rogers, September 4, 1932
|
|
|
|
|
Johnny J. wrote: It's called "random features"!
Unknown Features or Hidden Features
Silverlight 5 Tutorials : 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9
|
|
|
|
|
|
Since my company is under FDA regulation all of our software needs to be reviewed tested and verified before release to customers.
However the bug fixes don’t necessarily mean that unforeseen bugs or that new bugs aren’t introduced. But good coding practices can mitigate a lot of those.
It also helps to have a good team where everyone looks out for the other team members. I am very fortunate to be a part of such a group. 
It was broke, so I fixed it.
|
|
|
|
|
|
without testing...on need basis.
if customer in hurry and want bug fix right away, and if developer is confident (developers always confident  ) on code, then we take risk of sending patch.
read some funny chat
Question: How many testers does it take to change a light bulb?
Answer: None. Testers do not fix problems; they just find them.
Question: How many programmers does it take to change a light bulb?
Answer1: What’s the problem? The bulb at my desk works fine!
Answer2: None. That’s a hardware problem.
Rating always..... WELCOME
The only reason people get lost in thought is because it's unfamiliar territory.
|
|
|
|
|
1) If it compiles, it must logically be perfect! -- Never.
2) Try it out... Yep, works... Too simple to break anything else. -- Often
3) Try it out a few different ways, and make sure it's as isolated as possible (To limit the damage if it breaks) -- Often
3) Run it through detailed tests, trying out every possible situation. -- Only if it's critical, and only if such tests are possible
Gotta face the fact that as a lone developer on a tight release cycle (Everything needs to be done yesterday), I can't possibly catch everything. But since only #4 is really proper "testing", I guess it's "Often" for me.
|
|
|
|
|
I agree, 5!
Its the man, not the machine - Chuck Yeager
If at first you don't succeed... get a better publicist
If the final destination is death, then we should enjoy every second of the journey.
|
|
|
|
|
Which one is #4? 
|
|
|
|
|
Uh, the one that came after #3... Err... The first #3... Apparently there was a distortion in the space-time continuum, and #3 looped back on itself... or something... Either that, or I've been watching too much Star Trek TNG on Netflix.
|
|
|
|
|
Ian Shlasko wrote: too much Star Trek TNG on Netflix
I've been watching the original series that way for the last few weeks. 
|
|
|
|
|
|
At my previous employer, I was 'the' programmer. Even though they finally understand that it's not enough for me to test it [i.e., they understood that "it works on my machine" isn't enough since my development machine worked differently than theirs], they sent out bug-fixes and upgrades without testing them on a system that was similar to what their customers were using.
They were, as the owners, very busy. After all, they put in an office network so that they could play Worlds of Warcraft all day long. No time to waste on testing their only product.
Back when most of our clients had phone-modems, at best, this damage was truly a joy to undue.
Well, it was their business. I guess they knew best.
<pre>
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "As far as we know, our computer has never had an undetected error." - Weisert | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Of course we run unit tests against any changes and the code is tested by the team (e.g looking out for any UI weirdness that may hav been introduced)
We don't go through a full UAT process for minor bugs and fixes though, that's only for 'significant work \ changes' where we require business users to sign off that all work is to their satisfaction.
Pretty standard really...
|
|
|
|
|
these days when we get bugs they are in Bugzilla and have a budget attached. So there is time to test and document (though we still have a few idiots who don't bother).
It is very hard to tell the project leader to wait two more days till it's tested properly, if the customer is waiting with 200 men for permission to start working. I can understand that the younger engineers are tempted to give way. But I have learned the hard way...
------------------<;,><-------------------
|
|
|
|
|
The real problem is owning up to it, usually we blame others for our sloppy practices, but more often than not we get burned so we start testing as a precaution against being beat up again by the customer than for our software quality.
Writing programs is easy if you don't have to make UI, document, test, fix bugs ...
Sad really...
Its the man, not the machine - Chuck Yeager
If at first you don't succeed... get a better publicist
|
|
|
|
|
Not guilty, ever. In some industries, a bad fix could lose enough money to put your company out of business. I've never released without testing.
"I have a theory that the truth is never told during the nine-to-five hours. "
— Hunter S. Thompson
My comedy.
|
|
|
|
|
Good for you, it's great when customers keep you honest, and in business.
Its the man, not the machine - Chuck Yeager
If at first you don't succeed... get a better publicist
If the final destination is death, then we should enjoy every second of the journey.
|
|
|
|
|
The operations director was pressing me to release some software I was working on. I told him I hadn't tested it yet but he was adamant that it be released despite my protests. It cost the company circa £2 million and lost a lot of goodwill. In the meeting he arranged to discuss the issue I explained why it had been released and allied with the fact the problems it caused weren't noticed sooner by his team he was asked to leave the business that day.
|
|
|
|
|
More than once...
The project leader was one of those guys who think even testing their code is an insult. So he would deliver stuff that was catastrophic (and in image processing it's sort of obvious). Since he seemed to be in bed with the dept head he got away with it. He always blamed it on the rest of us. Most of us left the dept. After a while there was a reorganisation and the brown stuff hit the fan - our customers are not stupid, though he always said they were - and he was demoted so fast he got the bends.
------------------<;,><-------------------
|
|
|
|
|
When your software is connected to an industrial hardware (sometimes 100K$ or more) and you do not have it physically at your office, you can only release a beta... we call them xx.yy.h# where h is for hope number #..
Sometimes a remote COM interface connected via internet can help, but few customers open their firewalls.
|
|
|
|
|
Davide Zaccanti wrote: where h is for hope number
Brilliant
cheers,
Chris Maunder
The Code Project | Co-founder
Microsoft C++ MVP
|
|
|
|
|
At a previous job someone had done something (I honestly cannot remember who and what but many stupid things were done by many stupid people) that caused a problem on Linux servers at many remote sites.
The only person with the skills to quickly write the script to put things right was the IT Director who wrote it with a .fu suffix and gave it to me to send out.
When I asked what the .fu stood for he said it was for f*** up.
Every man can tell how many goats or sheep he possesses, but not how many friends.
|
|
|
|
|
I am with you there. Happens to me much more than I would like to admit.
Doug Joseph (Engineering Guy)
|
|
|
|
|
Davide Zaccanti wrote: connected to an industrial hardware (sometimes 100K$ or more)
Right, that's why two places I worked had no test systems. Once the first version was done, it was put into production and from then on I had to develop and test on the production systems.
That sort of thing likely happens quite often, probably only with in-house software fortunately. In my case I was the only developer of the software in question and I think that's the only way it can possibly work; I certainly wouldn't want to consider doing that with a team.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
