|
SortaCore wrote: If the changes they make are under version control the coder could always review them
If the changes are not under version control then that is a problem regardless of who is making the change.
SortaCore wrote: The thing is, if they do break it, they can just hide behind
If they broke it then they broke it. Period.
The choice after that is whether they still get a chance to not break it in the future.
|
|
|
|
|
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
|
|
|
|
|
Actually, I do not have this situation. The QA staff here does not code at all.
I was just stating that putting a process in place that allows this is completely possible.
The result is that the dev manager is ultimately responsible and should be reviewing when/if it happens.
"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: The result is that the dev manager is ultimately responsible and should be reviewing when/if it happens.
I hate to say this, but does the manager understand the intricacies of the code?
If they were managing and not micromanaging then they don't. 
The dev is the only person who knows the code so they should be the one making the changes.
It is alright for the QA person to indicate where they think the changes should be made, but the dev should have final say.
The report of my death was an exaggeration - Mark Twain
Simply Elegant Designs JimmyRopes Designs
I'm on-line therefore I am.
JimmyRopes
|
|
|
|
|
JimmyRopes wrote:
I hate to say this, but does the manager understand the intricacies of the code?
If it were me, the answer would be yes.
"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: JimmyRopes wrote:
I hate to say this, but does the manager understand the intricacies of the code?
If it were me, the answer would be yes.
Then you are not managing. You are a micromanager.
The report of my death was an exaggeration - Mark Twain
Simply Elegant Designs JimmyRopes Designs
I'm on-line therefore I am.
JimmyRopes
|
|
|
|
|
I'm sorry but it won't be faster. If your team is small then your devs probably know the app inside out. Let the QA guy tell the devs where he thinks the change should be made. If he is correct, it will be 2 mins to get it fixed. If there is something else - the hardcoded variable is used elsewhere the QA guy doesn't know about - the dev will know it and fix it properly.
Changes outside of the dev team - especially small one - will make things much slower in future and harder for maintenance.
I know every manager wants to deliver on time and the pesky QA guys just go in the way 
I think it is better to ship with small visible bugs the client knows about (QA reported, but no time to fix), than ship with masked bugs as they will hit you harder later.
--
"My software never has bugs. It just develops random features."
|
|
|
|
|
I am glad that you all have your own processes in place. Please don't believe that EVERYONE else does it the same way.
I do not have this problem - I merely suggested it was manageable and potentially effective.
My QA is made up mostly of analysts who don't want to code - at all.
"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: My QA is made up mostly of analysts who don't want to code - at all.
A blessing in disguise.
The report of my death was an exaggeration - Mark Twain
Simply Elegant Designs JimmyRopes Designs
I'm on-line therefore I am.
JimmyRopes
|
|
|
|
|
As long as it's limited to typo level fixes I don't have a problem with it, provided you have someone reviewing every change the tester makes. I'd be leery of letting someone just brought in to test try to fix anything more complex though; for the same reason I'd be leery about bringing a new dev into the project a week before release. I'm not as dogmatic as Mark is, because real world staffing constraints mean you can't always do things the best way; and it's still a step up from the same group of devs who wrote the app doing all the testing. (Nevermind not actually doing any formal testing before release at all. *shudder* BTDTGTWTF)
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
Enforce Code Review process before any check-ins and then you know whether the fix he made is good or bad. Secondly the bugs that he fixes can be assigned to another tester for second round of testing. ![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
So long as it gets marked as 'submitted for QA review' (or however your process works) and someone else in QA has to review and verify it is fixed, then I don't see any real problem.
Also assumes (ha!) he sticks to what his proficiency allows him to understand.
|
|
|
|
|
Kieryn Phipps wrote: Thoughts?
Who QA tests the QC lead's fixes?
|
|
|
|
|
It's good and bad, it's good because you have an extra set of hands to help you with small tasks, but it's bad because if he breaks something he may simply wash his/her hands and pass the problem to you.
|
|
|
|
|
Kieryn Phipps wrote: Good or bad?
In general, a good thing. But ensure that any check-ins are first reviewed by a senior dev. Over time, some types of fixes may be permitted without review. I would encourage the QC engineer to continue pursuing his/her programming skills (by formal training - by that I don't necessarily mean a degree program).
/ravi
|
|
|
|
|
First it is a bad thing to have hard-code string UI messages as it will make harder to localize the application if the need comes or if the message is used at many locations.
Second, the developer might be better at evaluating the impact of change. Maybe the string is written in a fixed size buffer or is restricted in available UI space or used at more than one location or other similar things for which the tester might not be able to properly evaluate the impact.
Third it might make it harder to follow the history if such changes are made in the middle of other unrelated changes so it might be preferable to review and fix all mistakes at once. It could also help ensure consiostency where all similar errors are corrected at once for example if the same word was always spelled wrong.
Philippe Mori
|
|
|
|
|
If government makes it easy to take house mortgages, do you think it will result in -
GDP increase & inflation increase?
|
|
|
|
|
You're talking about one of the classic causes of housing bubbles. Deregulation and easy access to mortgages leading to increased debt relative to GDP (rather than increasing GDP - increasing GDP does not really relate to easier credit). If you want to see the type of effects I'm talking about, have a read of this[^].
|
|
|
|
|
Quote: increasing GDP does not really relate to easier credit
From what I heard, GDP isn't really a good measure of anything really. As your GDP would increase if Bill Gates would move to the UK, but you wouldn't necessarily be any better off for it. I seem to recall that GDP came into play after WW2 as a measure of how well a country was doing (when it came from nothing really) and was really never intended to be used widely for any economical understanding.
As you quoted statement can be related to GDP if nobody could get any money to invest in new equipment at your workplace etc. But GDP wouldn't tell you if it was a good idea or not.
|
|
|
|
|
Houses are only included in a GDP calculation if they are new builds. Second-hand goods, including the buying and selling of existing housing stock is not included for calculating GDP. Inflation is a different question altogether, and mortgages will have an effect.
modified 1-Aug-19 21:02pm.
|
|
|
|
|
Tying up money in house repayments will of course reduce inflation, unless house prices are included in the calculation.... 
As for GDP, yeah, what the last guy said.
"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
|
|
|
|
|
It will impact inflation yes - but because of the creation of money behind those mortgages will increase the amount of money in the economy.
What happens is - you walk into the bank and borrow £250k. The bank creates an asset (the mortgage) from that and transfers electronic money backed by that asset to you. They have a zero sum (ish) thing going on but £250k that didn't exist in the economy before the transaction has come into being. If everyone does this vast sums of money "just come into being" and more money chasing the same supply of products and services pushes up prices.
Something like 90% of the money in the UK economy came into being this way.
|
|
|
|
|
AndyInUK wrote: Any economist here
No 
The report of my death was an exaggeration - Mark Twain
Simply Elegant Designs JimmyRopes Designs
I'm on-line therefore I am.
JimmyRopes
|
|
|
|
|
Was talking to my Dad about stuff that used to go on in the tool-room he used to work in. If a job went wrong it was thrown in the scrap me.tal bin, the wag pitching it would often say "Oh well, good enough for government". Then he watched a TV programme ("American Chopper", or "Tank Kings") where exactly the same phrase was used.
Is this phrase in common use across the pond? I told my dad I'd ask.
[Edit]
Thanks. And to all those who replied with an explanation, it means the same here (ie shoddy work only the government would accept and pay for). The US may think it leads the world in incompetent government, but by jingo Blighty is more than giving it a run for its money
modified 10-Apr-14 15:20pm.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
