Testers coding bug fixes directly?
-
mark merrens wrote:
One day he'll fix something he really doesn't understand.
"So far it's restricted to typos/grammar mistakes in hard-coded string UI messages and that type of thing" Plain English? Come on. Don't be silly.
"The whole idea that carbon dioxide is the main cause of the recent global warming is based on a guess that was proved false by empirical evidence during the 1990s." climate-models-go-cold
-
I have to agree with Mark Merrens on this one, nothing good can come of this. As this person gets more confident they'll try and tackle bigger problems which brings greater risks. It could be just as easy as documenting what he thinks should be changed and give it to you, then you could dole the work out after aa number on them have been received. If the fixes are indeed easy, it should just take a couple of minutes for the dev team (the people who could perhaps see the bigger picture) to fix.
jeron1 wrote:
If the fixes are indeed easy, it should just take a couple of minutes for the dev team (the people who could perhaps see the bigger picture) to fix.
And probably an order of magnitude more minutes in people's time to assign a ticket number, approve it into a development cycle, estimate it and account for it in the project plan, etc.
-
So I'm a dev manager and our QC lead who is gaining proficiency in coding, though is by no means even a junior programmer has taken it upon himself to directly fix some easy bugs. This is certainly a faster way to get things fixed as our dev resources are severely limited. So far it's restricted to typos/grammar mistakes in hard-coded string UI messages and that type of thing. Good or bad? Thoughts?
-
I think it's okay as long as the bug fix is not signed off by the person that fixes it, and the tester knows his limits when it comes to coding.
BobJanova wrote:
and the tester knows his limits when it comes to coding.
What coder knows his limits? :~
The report of my death was an exaggeration - Mark Twain
Simply Elegant Designs JimmyRopes Designs
I'm on-line therefore I am. JimmyRopes -
So I'm a dev manager and our QC lead who is gaining proficiency in coding, though is by no means even a junior programmer has taken it upon himself to directly fix some easy bugs. This is certainly a faster way to get things fixed as our dev resources are severely limited. So far it's restricted to typos/grammar mistakes in hard-coded string UI messages and that type of thing. Good or bad? Thoughts?
It should be fine if it's only UI messages - if they're kept outside of variables. Such as a messagebox with a fixed caption, or a constant variable. Otherwise you risk coding problems such as "I'll just change the text that's passed to this strcpy()... oops." "I'll just change the text in this char[26]... oops." If the changes they make are under version control the coder could always review them. The thing is, if they do break it, they can just hide behind "I'm not a programmer"... quite legitimately.
-
Quid arsos qual arsolium It roughly translates to "which arse let him touch the code"?
"Benefits of a classical education." - Hans Gruber
Software Zen:
delete this; -
"Benefits of a classical education." - Hans Gruber
Software Zen:
delete this;Gary Wheeler wrote:
"Benefits of a classical education."
You can converse in a dead language. :~
The report of my death was an exaggeration - Mark Twain
Simply Elegant Designs JimmyRopes Designs
I'm on-line therefore I am. JimmyRopes -
It should be fine if it's only UI messages - if they're kept outside of variables. Such as a messagebox with a fixed caption, or a constant variable. Otherwise you risk coding problems such as "I'll just change the text that's passed to this strcpy()... oops." "I'll just change the text in this char[26]... oops." If the changes they make are under version control the coder could always review them. The thing is, if they do break it, they can just hide behind "I'm not a programmer"... quite legitimately.
SortaCore wrote:
if they do break it, they can just hide behind "I'm not a programmer
When you change code you have just become a programmer. Alternatively, if you are not a programmer why did you change the code?
The report of my death was an exaggeration - Mark Twain
Simply Elegant Designs JimmyRopes Designs
I'm on-line therefore I am. JimmyRopes -
Gary Wheeler wrote:
"Benefits of a classical education."
You can converse in a dead language. :~
The report of my death was an exaggeration - Mark Twain
Simply Elegant Designs JimmyRopes Designs
I'm on-line therefore I am. JimmyRopes -
SortaCore wrote:
if they do break it, they can just hide behind "I'm not a programmer
When you change code you have just become a programmer. Alternatively, if you are not a programmer why did you change the code?
The report of my death was an exaggeration - Mark Twain
Simply Elegant Designs JimmyRopes Designs
I'm on-line therefore I am. JimmyRopesJimmyRopes wrote:
When you change code you have just become a programmer.
Not something I agree with. I might be able to fix a car, but I don't become a mechanic from doing that. Or whack a nail into a plank of wood and become a "DIY guy". Code to me is the mechanics of the program, not the UI wording. When a program goes multi-language, it'll probably end up with separate language files anyway, which don't contain any code, just variants of UI text; so surely changing that text would make you a programmer, since it affected the program? Heck, you could draw a new icon file and change the program. And if it's embedded into the application, you've just changed the machine code. Congrats on your new job title.
-
JimmyRopes wrote:
When you change code you have just become a programmer.
Not something I agree with. I might be able to fix a car, but I don't become a mechanic from doing that. Or whack a nail into a plank of wood and become a "DIY guy". Code to me is the mechanics of the program, not the UI wording. When a program goes multi-language, it'll probably end up with separate language files anyway, which don't contain any code, just variants of UI text; so surely changing that text would make you a programmer, since it affected the program? Heck, you could draw a new icon file and change the program. And if it's embedded into the application, you've just changed the machine code. Congrats on your new job title.
If you are not a programmer why did you change the code? :doh:
The report of my death was an exaggeration - Mark Twain
Simply Elegant Designs JimmyRopes Designs
I'm on-line therefore I am. JimmyRopes -
But can you say "Yippee-ki-yay, mother
fucker!" in Latin? :-DThe report of my death was an exaggeration - Mark Twain
Simply Elegant Designs JimmyRopes Designs
I'm on-line therefore I am. JimmyRopes -
But can you say "Yippee-ki-yay, mother
fucker!" in Latin? :-DThe report of my death was an exaggeration - Mark Twain
Simply Elegant Designs JimmyRopes Designs
I'm on-line therefore I am. JimmyRopesAccording to Google translate: Yippee KI videri enim dicuntur haec matris fututor :laugh:
Software Zen:
delete this; -
If you are not a programmer why did you change the code? :doh:
The report of my death was an exaggeration - Mark Twain
Simply Elegant Designs JimmyRopes Designs
I'm on-line therefore I am. JimmyRopesChanging the interface, not the code. As in my example, if there was an icon file separate in the project, but embedded when the program was produced, a graphics designer could freely change the icon without being told he "changed the code" or that he's a coder.
-
Changing the interface, not the code. As in my example, if there was an icon file separate in the project, but embedded when the program was produced, a graphics designer could freely change the icon without being told he "changed the code" or that he's a coder.
Apparently the QA person is taking more liberty than just changing icons. (S)he is changing variables, albeit hard coded ones that probably should not have been, which can have unexpected consequences.
The report of my death was an exaggeration - Mark Twain
Simply Elegant Designs JimmyRopes Designs
I'm on-line therefore I am. JimmyRopes -
According to Google translate: Yippee KI videri enim dicuntur haec matris fututor :laugh:
Software Zen:
delete this;You "matris fututor" you. :-D
The report of my death was an exaggeration - Mark Twain
Simply Elegant Designs JimmyRopes Designs
I'm on-line therefore I am. JimmyRopes -
Apparently the QA person is taking more liberty than just changing icons. (S)he is changing variables, albeit hard coded ones that probably should not have been, which can have unexpected consequences.
The report of my death was an exaggeration - Mark Twain
Simply Elegant Designs JimmyRopes Designs
I'm on-line therefore I am. JimmyRopes -
So I'm a dev manager and our QC lead who is gaining proficiency in coding, though is by no means even a junior programmer has taken it upon himself to directly fix some easy bugs. This is certainly a faster way to get things fixed as our dev resources are severely limited. So far it's restricted to typos/grammar mistakes in hard-coded string UI messages and that type of thing. Good or bad? Thoughts?
Everyone's responses against so far have been a bunch of "What Ifs" (or clever cliches in Latin). What if allowing the QA to fix a typo brings the project in a day early, and the Dev Manager gets a nice huge bonus? What if a developer changes something he/she really doesn't understand and delays the project for weeks? Separation of responsibility is a nice guideline, but exceptions almost always prove the rule. Who's QA'ing the QA? Hopefully, the dev manager is. You may have guessed that I am a dev manager. "I am rarely happier than when spending entire day programming my computer to perform automatically a task that it would otherwise take me a good ten seconds to do by hand." - Douglas Adams
-
Ah, I did say "outside of variables" in my post. Changing variables is definitely inviting trouble. I agree with you on that point.
That is just it. The poster said they were changing variables, albeit hard coded ones.
The report of my death was an exaggeration - Mark Twain
Simply Elegant Designs JimmyRopes Designs
I'm on-line therefore I am. JimmyRopes -
Everyone's responses against so far have been a bunch of "What Ifs" (or clever cliches in Latin). What if allowing the QA to fix a typo brings the project in a day early, and the Dev Manager gets a nice huge bonus? What if a developer changes something he/she really doesn't understand and delays the project for weeks? Separation of responsibility is a nice guideline, but exceptions almost always prove the rule. Who's QA'ing the QA? Hopefully, the dev manager is. You may have guessed that I am a dev manager. "I am rarely happier than when spending entire day programming my computer to perform automatically a task that it would otherwise take me a good ten seconds to do by hand." - Douglas Adams
Michael Haines wrote:
You may have guessed that I am a dev manager.
Then you are asking for trouble. Any changes "out of band" should not be done. There is a process in place to insure that casual changes do not take place. It is there for a very good reason. Regardless of all good intentions people will make mistakes. Sorry if your bonus is not as big, but the process has to be followed if consistency is to be maintained.
The report of my death was an exaggeration - Mark Twain
Simply Elegant Designs JimmyRopes Designs
I'm on-line therefore I am. JimmyRopes