You've been asked to do something that's not your job (as others have pointed out, metrics are what MBAs are paid to undestand.) I will warn you that trying to give an "honest" answer can easily create the opposite effect of what's desired. For example, if one of the metrics is "time to close tickets", then there is no incentive to solve pervasive problems that are easy to fix. For example, it takes one line of code to make software understand both upper and lowercase. Fixing a bug where the software doesn't take lowercase is trivial. However, if the metric is "time to close ticket", then fixing the problem would be counter-productive, because such tickets are fast and easy to close.
In fact, if you do your job well and take preventative measures that solve the easy problems, the tickets become progressively more difficult to close, which makes it look like productivity is decreasing, when in fact it is increasing.
This is the same problem as standardized tests in education - teachers teach to the tests, not to a well-rounded education. Similarly, whatever metrics you define, that's what employees will work towards, whether it benefits the company or not. People want to get raises and get promotions, so they'd be foolish to do anything else.
I've worked in several companies that put IT under the bean counters. Without exception, the result was that the competent people left.
Mark me as a troll, but I have to side with Blockbuster on this one. Blockbuster mailed me a complete description of the new program, which outlined in detail how the whole thing worked, including the restocking fee. (I read the whole thing when I got it.) If people didn't read it, tough. Anybody who thinks that they get *anything* for free in this day and age deserves their fate.
Even so, if you go over the week and they sell you the movie, that's not a late fee - you received something tangible in exchange. Worst comes to worst, you return it for $1.50 restocking fee. Under the old scheme, if you returned it three weeks late on a two day rental, the charge would have been over $40. Sounds like a win to the consumer to me.
I own my own business, so any tech support I do takes away from my "real" customers. So I charge $150/hr, which is my normal consulting rate. When people question me, I tell them "Do you want it done right or done cheap?" Inevitably, most of them don't want to pay that price, which is fine with me. I refer them to someone else I know who does a good job and they go away happy.
The only exception to this rule is that I'll fix PCs for friends who have invited my wife and I over to dinner.
I think every one of these points is great advice, but they don't tell you what your job is, they tell you how to do your job.
Your job as a supervisor is very simple: enable everyone under you to do their job. This means that you protect them from political BS, you get them funding/equipment as needed, you make sure communication flows both inside and outside the group, you resolve disputes, and, perhaps most importantly, you set goals, both on a individual and group basis.
Here are the top three mistakes I've seen managers make: 1 The people you are managing are not your friends. Period. If they are, you'll show favoritism, you'll take things personally, and you'll do all sorts of things that aren't professional. You are there to use the resources at hand to best meet the company's goals. This doesn't mean I think that employees should be mistreated - far from it, because a mistreated employees leaves and costs the company money to replace them. This is poor management of corporate resources. Your ability to maintain morale is a key element of resource management.
2. Listen to all feedback, positive or negative, and don't argue. If you are getting negative feedback, then either the person understands something you don't, the person doesn't understand something that you do, or you really are screwing up. Treat the root problem, don't shoot the messenger.
3. Tell people when they do well and tell people when they don't do well. If people don't know you are unhappy, they can't read minds and they won't be able to fix it. A close corollary of this is that people should *never* hear negative feedback for the first time in a review. Give them a chance to correct the problem.
An outsourcing company I used to work for (completely US based) had a standard contract that all bugs found from testing would be fixed before each milestone was delivered. Development wasn't going well, so the project manager simply stopped testing. No bugs found, no bugs fixed! Instead of getting in trouble, the manager was praised for "sticking to the contract" and "increasing profits by not performing unnecessary testing."
I resigned shortly after this happened.
My opinion is that if you are going to hire an outsourcing group, you must have both a contract negotiator and a project manager who know the tricks of outsourcing groups. Otherwise, save yourself a lot of aggravation and just flush the money down the toilet.
At my company, we provide the research time between projects. This allows people to focus on the new activity and to not affect deliverables. Typically people get a one to two weeks of open time between projects.
The vast majority of people can't handle undirected activities, so we enforce some controls over junior people. We require them to learn foundation skills that they don't already know that will benefit both them and the company. For employees who are anywhere from an intern to a software engineer, there is a stock list of topics you can choose from, including langauges, techniques, coding standards, testing, new tools, etc. Unusual topics can be studied with approval. At the end, these employees have a discussion with a technical lead about what was learned (note: not a grilling, but a "fill in the gaps" kind of discussion.) This last bit also forces them to practice their communication and organizational skills.
More senior people, who have demonstrated innate initiative and curiousity, can choose their own research topics, but they have to present their findings to the rest of the senior staff. Therefore there's some peer pressure to pick relevant topics.
A very important additional benefit is that everyone has their own book budget, the size of which is dependent on experience. You can spend the money on any technical book you want without having to get prior approval.
If you try to explain this in technical terms, you've already lost the argument. You're up against the classic case of the engineer against the business person. Although you are both speaking English, neither of you has the faintest understanding of what the other is talking about. You need to discuss this in language your boss understands.
Start by asking your boss how a manager with 10 years experience is different from a manager with 2 years experience. You'll probably get answers about more successful projects, different environments, larger budgetary authority, better political skills, maybe better "instincts", etc. Look for analogies in how those answers apply to developers. I have yet to meet a developer with 2 years experience who has the skills to handle a meeting with marketing, manage a bug review session, negotiate features with clients, or any number of other "soft skills." These are skills your boss will understand.
Also, don't lump programmers in the same bin with architects. I've never met an architect with less than ten years experience who was worth diddily. Programming skills may be there, but people skills, technical writing skills, quality assurance methodology, security concerns, cost vs. feature tradeoffs - all of the skills necessary to be an architect take a *long* time to develop, and many of these skills are similar to what your boss's peers develop between years 2 and 10.
Finally, what the "run of the mill" developer learns between years 2 and 10 depends heavily on training by their employer. If the employer doesn't require them to read books, read magazines, improve code quality and grow beyong the "Year 2" knowledge, than most of them never will.
It's clear you weren't writing code 30 years ago and you have no ideas what it was like back then. I was there. If you had ever tried to write an entire application in 2K, you'd know that every trick Mel played saved precious memory and/or cycles. Back then, hardware was expensive, people were cheap. 4K words of memory cost more than most people made in a year (and no, 4K words was not 4KB) - and that pricing was long after the drums described in this article. The optimizers were interesting toys, but that was about it.
Your talking about documented code makes pretty clear how little you know on the subject. He was writing machine code. Not assembly. Not C. Not Perl. Machine code. There's nowhere to put comments. Even if there were, you'd never waste a machine word on them.
If you've never had to get a forklist to help you lift your computer, you aren't qualified to pass judgment on Mel.
If I go look at benchmark numbers on StorageReview.com, I see that your conclusions are debatable. Let's compare the SATA Barracuda V against the Seagate Cheetah X15-36LP, which is a 36GB 15k RPM drive with a 3.6ms access time.
Price - The Cheetah is $409 on CDW. So the price comparison is 2 for $819 (plus the $150+ SCSI controller), versus $150 total for the SATA drive. So it's a 6X price multiple, not a 2X price multiple.
Transfer Rate - 160MB/sec is just what the interface is capable of, not what the drive routinely does. And where did you come up with 75MB/sec? The SATA interface is rated at 150MB/sec. In practice, the Cheetah has a read transfer rate between 45.0MB/sec and 60.5MB/sec. The SATA Barracuda is 24.7MB/sec to 43.8MB/sec. So the Cheetah has a 30% to 80% faster raw read transfer rate. Let's see if this performance benefit holds up in other benchmarks.
Real World Benchmarks - The Cheetah scores 422 on the SR High End DriveMark 2002. The SATA Barracuda scores 355. About a 19% improvement. In no test that corresponds to typical workstation usage did the Cheetah score more than 30% over the Barracuda, and the Barracuda actually won some tests, including the ZD Business Disk WinMark 99. BUT! For server usage, in the File Server DriveMark, the Cheetah scored an astounding 285% better than the Barracuda.
Conclusion - SCSI drives are a foregone conclusion for a server, but paying six times as much money for a 30% performance improvement doesn't equate to a "better buck/performance value" when building a desktop or workstation.
I wrote Seagate sales an email earlier this month asking why the home page of their web site says, "Available now - The Barracuda ATA V" when it isn't actually possible to purchase one of those drives. They replied that the drives have been shipping to OEMs, but not to the retail channel.
The email also said that SATA Barracuda V drives were supposed to start shipping to the retail channel in late December, but I haven't seen one show up as "in stock" on CDW or pricewatch.com yet.
The review on HEXUS.net left a great deal to be desired. HD Tach and SISandra are interesting numbers, but hardly representative of how the drive will react in the "real world." StorageReview has posted a much more comprehensive set of benchmarks on this drive at StorageReview Although StorageReview does not yet have the formal review posted, some interesting results do emerge. The SATA Barracuda V drive beats the PATA Barracuda V drive in most benchmarks. For instance, the SR High-End DriveMark 2002 goes from 285 for the PATA to 355 for the SATA. However, since the SATA drive has an 8MB cache vs a 2MB cache on the PATA drive, it's not clear how much the improved results are due to the interface versus the cache.
Unfortunately, the numbers are not yet available for the File Server DriveMark test, which might give an indication of how much the drive benefits from support for tagged command queueing like SCSI drives have.
Note that the performance results for the SCSI drives versus the Barracuda V are not a valid indication of the raw capability of the SATA interface. Virtually all of the SCSI drives are 10k and 15k RPM drives, which one would expect to be substantially faster than a 7K RPM drive such as the Barracuda.
Finally, the explanation on HEXUS.net as to why the drive slows down at the end of the HD Tach test is simply wrong. The review says that "[The slowdown] is due to the sectors at the end of the disk being physically further from the drives starting point." The reality is that the drive slows down at the end of the test because the inner rings are smaller and therefore less data passes under the head for each revolution of the disk.
Slashdot Mirror
You've been asked to do something that's not your job (as others have pointed out, metrics are what MBAs are paid to undestand.) I will warn you that trying to give an "honest" answer can easily create the opposite effect of what's desired. For example, if one of the metrics is "time to close tickets", then there is no incentive to solve pervasive problems that are easy to fix. For example, it takes one line of code to make software understand both upper and lowercase. Fixing a bug where the software doesn't take lowercase is trivial. However, if the metric is "time to close ticket", then fixing the problem would be counter-productive, because such tickets are fast and easy to close.
In fact, if you do your job well and take preventative measures that solve the easy problems, the tickets become progressively more difficult to close, which makes it look like productivity is decreasing, when in fact it is increasing.
This is the same problem as standardized tests in education - teachers teach to the tests, not to a well-rounded education. Similarly, whatever metrics you define, that's what employees will work towards, whether it benefits the company or not. People want to get raises and get promotions, so they'd be foolish to do anything else.
I've worked in several companies that put IT under the bean counters. Without exception, the result was that the competent people left.
Mark me as a troll, but I have to side with Blockbuster on this one. Blockbuster mailed me a complete description of the new program, which outlined in detail how the whole thing worked, including the restocking fee. (I read the whole thing when I got it.) If people didn't read it, tough. Anybody who thinks that they get *anything* for free in this day and age deserves their fate.
Even so, if you go over the week and they sell you the movie, that's not a late fee - you received something tangible in exchange. Worst comes to worst, you return it for $1.50 restocking fee. Under the old scheme, if you returned it three weeks late on a two day rental, the charge would have been over $40. Sounds like a win to the consumer to me.
I own my own business, so any tech support I do takes away from my "real" customers. So I charge $150/hr, which is my normal consulting rate. When people question me, I tell them "Do you want it done right or done cheap?" Inevitably, most of them don't want to pay that price, which is fine with me. I refer them to someone else I know who does a good job and they go away happy.
The only exception to this rule is that I'll fix PCs for friends who have invited my wife and I over to dinner.
I think every one of these points is great advice, but they don't tell you what your job is, they tell you how to do your job.
Your job as a supervisor is very simple: enable everyone under you to do their job. This means that you protect them from political BS, you get them funding/equipment as needed, you make sure communication flows both inside and outside the group, you resolve disputes, and, perhaps most importantly, you set goals, both on a individual and group basis.
Here are the top three mistakes I've seen managers make:
1 The people you are managing are not your friends. Period. If they are, you'll show favoritism, you'll take things personally, and you'll do all sorts of things that aren't professional. You are there to use the resources at hand to best meet the company's goals. This doesn't mean I think that employees should be mistreated - far from it, because a mistreated employees leaves and costs the company money to replace them. This is poor management of corporate resources. Your ability to maintain morale is a key element of resource management.
2. Listen to all feedback, positive or negative, and don't argue. If you are getting negative feedback, then either the person understands something you don't, the person doesn't understand something that you do, or you really are screwing up. Treat the root problem, don't shoot the messenger.
3. Tell people when they do well and tell people when they don't do well. If people don't know you are unhappy, they can't read minds and they won't be able to fix it. A close corollary of this is that people should *never* hear negative feedback for the first time in a review. Give them a chance to correct the problem.
An outsourcing company I used to work for (completely US based) had a standard contract that all bugs found from testing would be fixed before each milestone was delivered. Development wasn't going well, so the project manager simply stopped testing. No bugs found, no bugs fixed! Instead of getting in trouble, the manager was praised for "sticking to the contract" and "increasing profits by not performing unnecessary testing."
I resigned shortly after this happened.
My opinion is that if you are going to hire an outsourcing group, you must have both a contract negotiator and a project manager who know the tricks of outsourcing groups. Otherwise, save yourself a lot of aggravation and just flush the money down the toilet.
At my company, we provide the research time between projects. This allows people to focus on the new activity and to not affect deliverables. Typically people get a one to two weeks of open time between projects.
The vast majority of people can't handle undirected activities, so we enforce some controls over junior people. We require them to learn foundation skills that they don't already know that will benefit both them and the company. For employees who are anywhere from an intern to a software engineer, there is a stock list of topics you can choose from, including langauges, techniques, coding standards, testing, new tools, etc. Unusual topics can be studied with approval. At the end, these employees have a discussion with a technical lead about what was learned (note: not a grilling, but a "fill in the gaps" kind of discussion.) This last bit also forces them to practice their communication and organizational skills.
More senior people, who have demonstrated innate initiative and curiousity, can choose their own research topics, but they have to present their findings to the rest of the senior staff. Therefore there's some peer pressure to pick relevant topics.
A very important additional benefit is that everyone has their own book budget, the size of which is dependent on experience. You can spend the money on any technical book you want without having to get prior approval.
If you try to explain this in technical terms, you've already lost the argument. You're up against the classic case of the engineer against the business person. Although you are both speaking English, neither of you has the faintest understanding of what the other is talking about. You need to discuss this in language your boss understands.
Start by asking your boss how a manager with 10 years experience is different from a manager with 2 years experience. You'll probably get answers about more successful projects, different environments, larger budgetary authority, better political skills, maybe better "instincts", etc. Look for analogies in how those answers apply to developers. I have yet to meet a developer with 2 years experience who has the skills to handle a meeting with marketing, manage a bug review session, negotiate features with clients, or any number of other "soft skills." These are skills your boss will understand.
Also, don't lump programmers in the same bin with architects. I've never met an architect with less than ten years experience who was worth diddily. Programming skills may be there, but people skills, technical writing skills, quality assurance methodology, security concerns, cost vs. feature tradeoffs - all of the skills necessary to be an architect take a *long* time to develop, and many of these skills are similar to what your boss's peers develop between years 2 and 10.
Finally, what the "run of the mill" developer learns between years 2 and 10 depends heavily on training by their employer. If the employer doesn't require them to read books, read magazines, improve code quality and grow beyong the "Year 2" knowledge, than most of them never will.
It's clear you weren't writing code 30 years ago and you have no ideas what it was like back then. I was there. If you had ever tried to write an entire application in 2K, you'd know that every trick Mel played saved precious memory and/or cycles. Back then, hardware was expensive, people were cheap. 4K words of memory cost more than most people made in a year (and no, 4K words was not 4KB) - and that pricing was long after the drums described in this article. The optimizers were interesting toys, but that was about it.
Your talking about documented code makes pretty clear how little you know on the subject. He was writing machine code. Not assembly. Not C. Not Perl. Machine code. There's nowhere to put comments. Even if there were, you'd never waste a machine word on them.
If you've never had to get a forklist to help you lift your computer, you aren't qualified to pass judgment on Mel.
If I go look at benchmark numbers on StorageReview.com, I see that your conclusions are debatable. Let's compare the SATA Barracuda V against the Seagate Cheetah X15-36LP, which is a 36GB 15k RPM drive with a 3.6ms access time.
Price - The Cheetah is $409 on CDW. So the price comparison is 2 for $819 (plus the $150+ SCSI controller), versus $150 total for the SATA drive. So it's a 6X price multiple, not a 2X price multiple.
Transfer Rate - 160MB/sec is just what the interface is capable of, not what the drive routinely does. And where did you come up with 75MB/sec? The SATA interface is rated at 150MB/sec. In practice, the Cheetah has a read transfer rate between 45.0MB/sec and 60.5MB/sec. The SATA Barracuda is 24.7MB/sec to 43.8MB/sec. So the Cheetah has a 30% to 80% faster raw read transfer rate. Let's see if this performance benefit holds up in other benchmarks.
Real World Benchmarks - The Cheetah scores 422 on the SR High End DriveMark 2002. The SATA Barracuda scores 355. About a 19% improvement. In no test that corresponds to typical workstation usage did the Cheetah score more than 30% over the Barracuda, and the Barracuda actually won some tests, including the ZD Business Disk WinMark 99. BUT! For server usage, in the File Server DriveMark, the Cheetah scored an astounding 285% better than the Barracuda.
Conclusion - SCSI drives are a foregone conclusion for a server, but paying six times as much money for a 30% performance improvement doesn't equate to a "better buck/performance value" when building a desktop or workstation.
I wrote Seagate sales an email earlier this month asking why the home page of their web site says, "Available now - The Barracuda ATA V" when it isn't actually possible to purchase one of those drives. They replied that the drives have been shipping to OEMs, but not to the retail channel.
The email also said that SATA Barracuda V drives were supposed to start shipping to the retail channel in late December, but I haven't seen one show up as "in stock" on CDW or pricewatch.com yet.
The review on HEXUS.net left a great deal to be desired. HD Tach and SISandra are interesting numbers, but hardly representative of how the drive will react in the "real world." StorageReview has posted a much more comprehensive set of benchmarks on this drive at StorageReview Although StorageReview does not yet have the formal review posted, some interesting results do emerge. The SATA Barracuda V drive beats the PATA Barracuda V drive in most benchmarks. For instance, the SR High-End DriveMark 2002 goes from 285 for the PATA to 355 for the SATA. However, since the SATA drive has an 8MB cache vs a 2MB cache on the PATA drive, it's not clear how much the improved results are due to the interface versus the cache.
Unfortunately, the numbers are not yet available for the File Server DriveMark test, which might give an indication of how much the drive benefits from support for tagged command queueing like SCSI drives have.
Note that the performance results for the SCSI drives versus the Barracuda V are not a valid indication of the raw capability of the SATA interface. Virtually all of the SCSI drives are 10k and 15k RPM drives, which one would expect to be substantially faster than a 7K RPM drive such as the Barracuda.
Finally, the explanation on HEXUS.net as to why the drive slows down at the end of the HD Tach test is simply wrong. The review says that "[The slowdown] is due to the sectors at the end of the disk being physically further from the drives starting point." The reality is that the drive slows down at the end of the test because the inner rings are smaller and therefore less data passes under the head for each revolution of the disk.