April 30, 2012 at 9:01 am
I don't really see the issue as whether to use metrics, but WHICH metrics to use. On this particular example, we had something similar but it had to do with checking in busted code: since we were a sizeable dev shop, it was your job to ensure that your code didn't "break" the build. So you had to "refresh" your dev copy, then compile and run the smoke test and standard test cases BEFORE checking in. The FB case kind of sounds that way (if they're talking production then shame on them).
That said - any metric you introduce will tend to push whatever is being monitored in a specific direction, so you need multiple metrics which are balanced to "send the right message". It's also a reasonably ugly scenario if the metrics are completely handed down from above with no discussion with the team. A given metric might sound good form the top of the ivory tower, but be completely unrealistic at trench level. I've also witnessed the metrics cycling in and out of relevance, so a periodic review and reassement would be beneficial to both employee and management.
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
April 30, 2012 at 9:09 am
Here's an article from the Chicago Tribune that describes an entirely different viewpoint at Facebook:
Facebook's rite of passage into the 'Hacker Way'
The money quote
Beyond all else, Facebook executives say, employees have not just the freedom but the obligation to try new things and fail, because "shipping code" — adding new software that runs the website — as quickly as possible is crucial to the company's success.
No QA testing at Facebook according to this article. Code it, ship it and move along. Done is better than good.
What other Silicon Valley companies "don't do is let their employees take risks and have failure be OK," said Jocelyn Goldfein, a Facebook director of engineering. "I think that is part of the secret sauce at Facebook. I didn't understand this one until after I got here, that the tolerance for failure, that 'Move Fast and Break Things,' is actually what keeps us open to continue to innovate."
April 30, 2012 at 9:20 am
Perhaps I don't know enough about it but I don't find FB technology all that fascinating and based on comments from executives I'm somewhat surprised the site works as often as it does.
April 30, 2012 at 9:31 am
I've seen both ends of this one as a developer and as a DBA who has to run hundreds of data fix scripts a week. The pressures of management and the marketplace has become so extreme that companies are releasing major versions of software faster than ever. To me, it seems like the quality of software has been in decline because it has become so complex, that testing has become almost impossible. It's hard to innovate without making mistakes.
April 30, 2012 at 9:51 am
One of the biggest issues in the workplace today is that the best employees are not rewarded, the worst employees get the same raises, bonuses as everyone else. The reason is companies are afraid of lawsuits and don't want to manage their workforce. They may claim they do, evidence shows not.
This is particularly true in the government sector.:-D
"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"
April 30, 2012 at 10:18 am
I'll jump on the 'be careful what you measure' bandwagon.
I wrote my response then stopped to read the whole article before submitting - I have to admit that I erased the post I had written (except the first line).
With daily deploys and a weekly major release schedule I don't think you can penalize the QA people for the problems - I think you do have to drop it straight in the developers laps.
Also note (from page two of the article) that before they release version x of the code, it has already been tested by a subset of end users (without their knowledge - which as a FB user I totally believe)
FWIW,
-Chris C.
April 30, 2012 at 10:24 am
Chris.C-977504 (4/30/2012)
With daily deploys and a weekly major release schedule I don't think you can penalize the QA people for the problems - I think you do have to drop it straight in the developers laps.
I have not read the article, but I am aware of the pressure the QA dept often gets in many shops. This is exactly why I wrote, in my first message in this topic, that the blame falls on either the QA dept, or management.
I still disagree with blaming the devs. Even if all designs are perfect, seperate testing is always required. You need a second set of eyes to guaurd agains misinterpretation of the design document.
April 30, 2012 at 10:46 am
What a radical idea.... holding someone accountable.
The probability of survival is inversely proportional to the angle of arrival.
April 30, 2012 at 11:01 am
tcorrigan5 (4/30/2012)
Here's an article from the Chicago Tribune that describes an entirely different viewpoint at Facebook:Facebook's rite of passage into the 'Hacker Way'
The money quote
What other Silicon Valley companies "don't do is let their employees take risks and have failure be OK," said Jocelyn Goldfein, a Facebook director of engineering. "I think that is part of the secret sauce at Facebook. I didn't understand this one until after I got here, that the tolerance for failure, that 'Move Fast and Break Things,' is actually what keeps us open to continue to innovate."
WT_?? new age BS. Failure is not OK and any company that embraces failure is not one I'd want to invest in.
And besides... engineers know how to mitigate risks whether they be software or hardware related. It involves following good engineering principles in the design & development phases of the product cycle. That's what they get paid to do and it isn't rocket science.
The probability of survival is inversely proportional to the angle of arrival.
April 30, 2012 at 11:12 am
Matt Miller (#4) (4/30/2012)
A given metric might sound good form the top of the ivory tower, but be completely unrealistic at trench level.
And sometimes metrics become the end-all; for example, the duration of the call being more important than whether or not the customer's problem is fixed.
April 30, 2012 at 11:18 am
If 'tracked and factored into the assessment' means, "the coder knows what they did wrong, and got training so it won't happen again", then that could be a good thing.
If it means, "kept a list of this person's screw-ups, so they can be knocked down at review time", then not so much.
April 30, 2012 at 12:29 pm
sturner (4/30/2012)
What a radical idea.... holding someone accountable.
I know this is tongue in cheek, and I do think that people are held somewhat accountable, though not consistently
What is seems is that there isn't a good process for tracking this and working on improving things at many companies. It's easy to complain about developers, or QA, or management, but there ought to be a process that doesn't just penalize people, but tries to improve the process, educate people and build better skills over time.
I do want all these people to have some accountability for their work, but not just with sticks used to beat them.
April 30, 2012 at 12:40 pm
Peter Maloof (4/30/2012)
If 'tracked and factored into the assessment' means, "the coder knows what they did wrong, and got training so it won't happen again", then that could be a good thing.If it means, "kept a list of this person's screw-ups, so they can be knocked down at review time", then not so much.
Well put. This should be a learning opportunity and tracked. If someone doesn't improve, that's a problem and perhaps they do need another job/position. And someone that succeeds wildly ought to get some rewards.
As I mentioned, bugs/issues should be a part of your review, just not sure they should be a large part.
April 30, 2012 at 12:55 pm
Steve Jones - SSC Editor (4/30/2012)
What is seems is that there isn't a good process for tracking this and working on improving things at many companies... there ought to be a process that... tries to improve the process, educate people and build better skills over time...
So, call me cynical, but...
People that want to do better don't need a formal process to help them.
People that don't want to get better, get good at gaming the system.
Many people that want to do better will score worse than those that don't, under the mistaken belief that their actual improvement is more important than their score.
I've made that mistake before and it bit me, but in hindsight I was better for the choice I made to disregard the scoring.
The problem starts at the beginning. Front line managers should have the freedom and resources to help people who want to improve. Front line managers should have the both the freedom and the guts to fire someone that doesn't.
Real life, of course, is more complex than that.
April 30, 2012 at 2:48 pm
The problem starts at the beginning. Front line managers should have the freedom and resources to help people who want to improve. Front line managers should have the both the freedom and the guts to fire someone that doesn't.
Real life, of course, is more complex than that.
Well said. 😀
"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"
Viewing 15 posts - 16 through 30 (of 34 total)
You must be logged in to reply to this topic. Login to reply