Productivity for a sysadmin is almost impossible to measure. Whatever metrics you come up with are likely to only capture very specific types of workflows or problems: when the set of issues changes (as it most certainly will), the metrics become useless. It's easy to measure the productivity of a knowledge worker, a little harder that of a sales person, but still doable. But for a knowledge worker like a sysadmin, it is impossible.
You should convince your boss that you will not measure productivity; if that fails, start looking for a new job.
Here's what's gonna happen if you do come up with some productivity metrics. Your boss will probably give incentives (bonus) or disincentives (lose job) based on the productivity. Things will be dandy for a bit until the problems you deal with start changing in nature, and your productivity metrics will start going down. At this point, you will have a choice between actually doing what's good for the company or trying to maintain your productivity metric at the expense of the company. With a boss like yours, the former spells bonus loss or job loss. Do you want to be in this situation? If not, don't measure productivity.
How dare you use reason and how dare you know what you're talking about? You're undermining all those 5+ Insightful posts complaining about how they just want to e-mail.
What is the point of the kids being able to replace the motherboard? That's about as bad of a metric of usefulness of a computer as you can get. What if they couldn't at all figure out how to do it? Would that make for a bad OLPC?
What I want to know is whether kids can actually do anything useful/interesting on these laptops.
As you have noticed, I never claimed to limit the refactoring to a small-scale. You're right that large-scale refactoring or a new approach is often the right solution, and, when you're at that point, it's often a most helpful approach. However, it's exactly at that point that typical software management throws up their hands and says we ain't gonna touch existing code.
And so the other part is that I never mentioned restricting testing to developer/unit tests only. Having full integration/functional tests is essential as well. These tests require nontrivial infrastructure (specific setups and test beds), and also take much much longer to execute. However, they tend to be significantly more static and are the key to helping you ensure success of large-scale refactorings.
Is the concern overblown? Maybe not with 128kbps mp3s (as opposed to say 256kbs ABR kind).
However, these same producers compress the living bejeezus out of their music during the production, killing all the dynamics. So frankly, the effect of a lower-bitrate mp3 isn't quite the castration of full-on sonic fidelity that's portrayed in the TFA.
10% of original music is an overblown claim, because the music is not just filtered down, but is also compressed. In truth, the article should be comparing against equivalent lossless audio compression formats, which yield about 60-70% of the original size (so does that mean that a FLAC file contains 60-70% of the original music? No!)
The bit about the compressed music affecting the perception in a different manner is an interesting one, but I really struggle to see how the difference can come through the average consumer equipment. It just doesn't. For example, things such as SACDs or high-quality vinyl records allow the recording to retain a lot of the "air," ambience of the room, which gives a perception of larger-than-life sound, makes it sound more full, gives it an impression of better dimensionality, really puts you there. But shit, you can only hear that on high-end equipment with the entire signal chain made out of quality components, and you sure as hell won't hear the difference on a consumer system.
Most people also do not listen to the music in an environment that allows for such an engaging listening experience.
I too am sad to see the consumers ignore higher-quality audio (as I want that higher quality for myself, being an audio geek of sorts), but I completely understand where they are coming from.
We need responsibility in DUI Laws. Drunk driving is a terrible problem, but the way the states are dealing with it is not good. The BAC limits have been creeping ever so lower, as to raise the revenue from someone having a glass of wine after dinner when stopped at a roadblock. This is not actually helpful in impacting road safety.
Ignition interlocks have a.02 BAC margin of error, so they are set to legal_limit - 0.02, so in a 0.05BAC state, they are set to 0.03. Go on a date and take the girl home on a bus. This is why you should not support mandatory ignition interlocks.
We need to deal with the drunk driving problem responsibly: provide good public transportation options (Boston, extend trains until after 2am, you listening?), encourage designated drivers, and provide massive roaming police enforcement, looking for erratic driving and dangerous behavior (substantially more effective than roadblocks).
I wanted to add that this is why many people become jaded in one direction or another.
For myself, the learning curve went something like this:
1) Was tight on time, decided to copy/paste code and not design in flexibility for things I thought could probably use it. Ended up taking more time than I probably would have otherwise and turning out some poor inflexible code. At this point, I swore to design everything up-front first.
2) Next time around decided that I will design, design and design. End up spending a ton of time designing with all sorts of flexibility in place, so much time that the project never got finished or really gotten anywhere. At this point, I am scarred and have no idea what the right answer is.
3) Spend the rest of the time being afraid of underdesign, and yet also being afraid of overdesign. Due to time pressure, was afraid to revisit poor design decisions (poor in retrospect), and end up churning out mediocre code that you see in your everyday company.
This is where most programmers are. They know that underdesign is bad and they can't spend all the time overdesigning, so anything that gives the impression of either is bad, even if it's the right thing. Under time pressure, most people gravitate into underdesign, writing hacky code and never coming back around to fix it.
When you're done designing your application in a way that it will grow gracefully and stay beautifully, come see me, because you'll be out of a job for not shipping the product on time.
You say that knowing the future requirements is difficult. That's the key insight: you just don't know. And unless you know, or have a good likely-to-happen general idea, you should not design it in any way other than as simple as it needs to be for right now. And if you guess, you are likely to end up with flexibility in all the wrong places.
The trick is to design simple for what you need now (easy), and then be able to expand your design to stay simple (hard).
This is difficult to accomplish because changing existing code is a no-no in software dev corps. "If it ain't broke, don't fix it" mentality dooms your project and causes you to accumulate massive design debt because of the hacks and not-simple solutions that do not touch existing code.
This design debt grows to mountain proportions, at which point everyone throws their hands up and assert that a complete rewrite is required.
The cure is to perform test-driven development, so that you are not afraid to change existing code. I can't emphasize how liberating it is to be able to come in and uproot some inflexible crap (which was good enough for a long time, but is not anymore), put in an improved design, and then know that you didn't break anything. You can roll with the punches and not waste your time designing in unnecessary flexibility.
Sub-standard programmers drag down the efficiency of your other developers with beginner questions, poor comments/documentation, and bad code that someone else will later be forced to spend time fixing.
That is exactly correct. This article is exactly right.
The number of poor developers out there is staggering. I left a previous team not because the work wasn't particularly appealing, but because the people on the team were poor and I didn't want to deal with crappy code anymore.
This is also why software goes to die at companies like CA or other large software companies. Developers who have developed for 20+ years are set in their ways and are unwilling to learn new techniques. We have developers that completely disregard the notion of unit testing (and are unwilling to recognize the value). Sheeit, we have devs who we couldn't convince to use smart pointers on a regular basis in our C++ code. Yet, these are principal-level software engineers getting paid in excess of 100K a year, just because they have the "industry experience".
The actual contribution of these software engineers' skills has decreased over time (and much more so in comparison with the state of the art), yet their salaries keep increasing over time.
One company I know hired devs with a certain keyword on their resume, passing over another candidate with a lot less experience. I guarantee 5000 that the person they passed over would've learned all the material related to that keyword and would've put out higher quality software in less time.
SMS is done on the same protocol layer as calls
on
All Things iPhone
·
· Score: 1
An AC posted this the other day:
SMS transfers are done on the same protocol layer as the call connections. That's why they're limited & more expensive. That's also why they're so limited in length.
The memo is wrong about private office space. Microsofties are used to it because they all have private offices (with doors and all), which is far better than cubes, but his dismissal of shared working spaces comes with no backup arguments (other than a link to a JoelOnSoftware article that talks about them expanding space--how is that a backup argument?)
I used to work in a team room environment, where all the developers sat together in one room (there were 10-15 of us or so), working on the same product. I loved working in that environment. You could talk to anyone just like that right away. Not having to walk for a minute or half a minute makes quite a difference, believe it or not. Since the barrier for asking someone for help or ideas is so low (lean over and speak), it's much easier to quickly bounce off ideas without having to interrupt your own flow. Also, you overhear others' problems and ideas, and pitch in with your own. Countless times I've heard someone lamenting some problem and was able to chip in with "oh I just solved the same issue."
Yes, you must have headphones in the team room, because sometimes you just need to concentrate and headphones are essential to drown out the noise.
Unfortunately, I am back to working in a cube and I miss the team room days.
Compare this to my Cingular $40/mo for 450 mins, then $40/mo for unlimited data and 1500 text messages for my Blackberry Pearl. That's $80/mo for a Blackberry user. (OK, I get a corp discount, so it's really $68/mo for me).
With Cingular's rollover feature, 450 minutes is plenty... I have some several thousand rollover minutes.
Maybe Google can turn Doubleclick into a better company--who knows? I am not drawing any conclusions yet, I want to see what they do with it.
Microsoft can be dethroned
on
100 Million iPods
·
· Score: 5, Insightful
You're so right on the money.
This is the reason that Microsoft can be dethroned--when you have good design, you can beat the giants. When you have shitty design and you are a giant, your product doesn't sell (Zune, case in point).
This is why Apple is sending shivers through the phone industry with the iPhone.
I predict that 2008 will be the year of actually easy to use phones, because of the well-designed competition by the iPhone.
The software this is affecting is loading key DLLs in the wrong order.
Whoa, since when is loading DLLs in wrong order been a problem? Any DLL that needs another DLL as a dependency will load that other DLL. So the order of loading doesn't matter, as it works out in the end.
Except that in this case, Microsoft screwed up and released the file with a conflicting base address! Hell, I don't even know why this problem even exists anymore! It's a shame that in 2007, such a problem occurs. Why would Microsoft have changed the original base addresses?
I agree with your sentiments. Especially, when I was younger, I had a much harder time understanding any lyrics.. and hell, with many of the vocals, you had to strain to comprehend. So I didn't care what the lyrics were, all I knew is that the music was heavy and angry. There was a lot of energy in it, and being a stuck-behind-the-computer-all-day nerd during highschool, I needed a way to cope with the lack of social status and social (physical) activity.
I wanted to rock out, because there was nowhere else to do it.
Alkonost is a Russian folk black metal band I've been recently listening too. It's quite good: melodic Russian folk music tunage, set against powerchords and death grunts. (*makes deathgrunt sound*)
Hey, I am not defending Vista at all, and these metrics do say something in terms of how "polished" the interface is, but give me a fucking break -- latency of menus? What a bullshit metric that is!
When was the last time you wanted to throw a shoe into the monitor because the menu had messed up latency?
I know it was long long long before yesterday, when I wanted to throw a shoe into the monitor because Windows Update rebooted my machine without saving my open documents. Now that's the kind of shit that matters.
These metrics are a bunch of self-important wankery. I bet I can come up with a set of metrics that will highlight the Windows Vista interface and make it seem better than the Apple interface (amount of fully obscured background information anyone? yeah, transparenty helps this metric)
I ran up my credit card debt because I spent without budgeting properly. I am paying things off now, on my road to positive net worth. However, I have to watch my credit card statements like a hawk, because they sneak in various APR increases and B.S. things quite often.
Predatory banking is bad, but, it only works on ignorant people.
This is a false impression. The problem with predatory lending is that people who should not be lent money are given that money. This is irresponsible because the bank well knows that the borrower is in a high risk area.
So what happens is that when payments are missed, the APR shoots up from 15-some % to 25, 30%. Now, it's that much more difficult to get out of this debt (that should not have been provided in the first place). Add on top the overcharge fees, late fees and others, and you're looking at easily over 40% effective APR. It becomes a downward spiral. If the borrower eventually defaults on that loan, the credit card company gets a big tax write-off, so they don't lose all that money. If the credit card company is lucky, the borrower signs up to a debt repayment program (often credit card company backed), and diligently repays the balance with all the fees and interest charges. $$$ profit all around.
Now, this is orthogonal to the reason why people get subprime credit cards. Half of bankruptcy is due to medical bills--so many of these cards are run up for that reason.
Here is another tidbit to consider:
The fact is 40 percent of credit card holders pay off their debt every month; 40 percent make only the minimum payment; and 20 percent are kind of 50/50 in that category. For those 60 percent who are generally people who are not as informed, not as able to pay back their bill, who may have one, two, three, four, five, six different credit cards, because this is a credit economy, credit card companies have been able, with very little notice to the payer of the debt, to solicit huge fees, penalties, and interest rates.
Slashdot Mirror
Productivity for a sysadmin is almost impossible to measure. Whatever metrics you come up with are likely to only capture very specific types of workflows or problems: when the set of issues changes (as it most certainly will), the metrics become useless. It's easy to measure the productivity of a knowledge worker, a little harder that of a sales person, but still doable. But for a knowledge worker like a sysadmin, it is impossible.
You should convince your boss that you will not measure productivity; if that fails, start looking for a new job.
Here's what's gonna happen if you do come up with some productivity metrics. Your boss will probably give incentives (bonus) or disincentives (lose job) based on the productivity. Things will be dandy for a bit until the problems you deal with start changing in nature, and your productivity metrics will start going down. At this point, you will have a choice between actually doing what's good for the company or trying to maintain your productivity metric at the expense of the company. With a boss like yours, the former spells bonus loss or job loss. Do you want to be in this situation? If not, don't measure productivity.
How dare you use reason and how dare you know what you're talking about? You're undermining all those 5+ Insightful posts complaining about how they just want to e-mail.
What is the point of the kids being able to replace the motherboard? That's about as bad of a metric of usefulness of a computer as you can get. What if they couldn't at all figure out how to do it? Would that make for a bad OLPC?
What I want to know is whether kids can actually do anything useful/interesting on these laptops.
As you have noticed, I never claimed to limit the refactoring to a small-scale. You're right that large-scale refactoring or a new approach is often the right solution, and, when you're at that point, it's often a most helpful approach. However, it's exactly at that point that typical software management throws up their hands and says we ain't gonna touch existing code.
And so the other part is that I never mentioned restricting testing to developer/unit tests only. Having full integration/functional tests is essential as well. These tests require nontrivial infrastructure (specific setups and test beds), and also take much much longer to execute. However, they tend to be significantly more static and are the key to helping you ensure success of large-scale refactorings.
Is the concern overblown? Maybe not with 128kbps mp3s (as opposed to say 256kbs ABR kind).
However, these same producers compress the living bejeezus out of their music during the production, killing all the dynamics. So frankly, the effect of a lower-bitrate mp3 isn't quite the castration of full-on sonic fidelity that's portrayed in the TFA.
10% of original music is an overblown claim, because the music is not just filtered down, but is also compressed. In truth, the article should be comparing against equivalent lossless audio compression formats, which yield about 60-70% of the original size (so does that mean that a FLAC file contains 60-70% of the original music? No!)
The bit about the compressed music affecting the perception in a different manner is an interesting one, but I really struggle to see how the difference can come through the average consumer equipment. It just doesn't. For example, things such as SACDs or high-quality vinyl records allow the recording to retain a lot of the "air," ambience of the room, which gives a perception of larger-than-life sound, makes it sound more full, gives it an impression of better dimensionality, really puts you there. But shit, you can only hear that on high-end equipment with the entire signal chain made out of quality components, and you sure as hell won't hear the difference on a consumer system.
Most people also do not listen to the music in an environment that allows for such an engaging listening experience.
I too am sad to see the consumers ignore higher-quality audio (as I want that higher quality for myself, being an audio geek of sorts), but I completely understand where they are coming from.
We need responsibility in DUI Laws. Drunk driving is a terrible problem, but the way the states are dealing with it is not good. The BAC limits have been creeping ever so lower, as to raise the revenue from someone having a glass of wine after dinner when stopped at a roadblock. This is not actually helpful in impacting road safety.
.02 BAC margin of error, so they are set to legal_limit - 0.02, so in a 0.05BAC state, they are set to 0.03. Go on a date and take the girl home on a bus. This is why you should not support mandatory ignition interlocks.
Also, breathalyzers have a +/- 20% error, which is rather unfortunate.
Ignition interlocks have a
We need to deal with the drunk driving problem responsibly: provide good public transportation options (Boston, extend trains until after 2am, you listening?), encourage designated drivers, and provide massive roaming police enforcement, looking for erratic driving and dangerous behavior (substantially more effective than roadblocks).
I wanted to add that this is why many people become jaded in one direction or another.
For myself, the learning curve went something like this:
1) Was tight on time, decided to copy/paste code and not design in flexibility for things I thought could probably use it. Ended up taking more time than I probably would have otherwise and turning out some poor inflexible code. At this point, I swore to design everything up-front first.
2) Next time around decided that I will design, design and design. End up spending a ton of time designing with all sorts of flexibility in place, so much time that the project never got finished or really gotten anywhere. At this point, I am scarred and have no idea what the right answer is.
3) Spend the rest of the time being afraid of underdesign, and yet also being afraid of overdesign. Due to time pressure, was afraid to revisit poor design decisions (poor in retrospect), and end up churning out mediocre code that you see in your everyday company.
This is where most programmers are. They know that underdesign is bad and they can't spend all the time overdesigning, so anything that gives the impression of either is bad, even if it's the right thing. Under time pressure, most people gravitate into underdesign, writing hacky code and never coming back around to fix it.
When you're done designing your application in a way that it will grow gracefully and stay beautifully, come see me, because you'll be out of a job for not shipping the product on time.
You say that knowing the future requirements is difficult. That's the key insight: you just don't know. And unless you know, or have a good likely-to-happen general idea, you should not design it in any way other than as simple as it needs to be for right now. And if you guess, you are likely to end up with flexibility in all the wrong places.
The trick is to design simple for what you need now (easy), and then be able to expand your design to stay simple (hard).
This is difficult to accomplish because changing existing code is a no-no in software dev corps. "If it ain't broke, don't fix it" mentality dooms your project and causes you to accumulate massive design debt because of the hacks and not-simple solutions that do not touch existing code.
This design debt grows to mountain proportions, at which point everyone throws their hands up and assert that a complete rewrite is required.
The cure is to perform test-driven development, so that you are not afraid to change existing code. I can't emphasize how liberating it is to be able to come in and uproot some inflexible crap (which was good enough for a long time, but is not anymore), put in an improved design, and then know that you didn't break anything. You can roll with the punches and not waste your time designing in unnecessary flexibility.
That is exactly correct. This article is exactly right.
The number of poor developers out there is staggering. I left a previous team not because the work wasn't particularly appealing, but because the people on the team were poor and I didn't want to deal with crappy code anymore.
This is also why software goes to die at companies like CA or other large software companies. Developers who have developed for 20+ years are set in their ways and are unwilling to learn new techniques. We have developers that completely disregard the notion of unit testing (and are unwilling to recognize the value). Sheeit, we have devs who we couldn't convince to use smart pointers on a regular basis in our C++ code. Yet, these are principal-level software engineers getting paid in excess of 100K a year, just because they have the "industry experience".
The actual contribution of these software engineers' skills has decreased over time (and much more so in comparison with the state of the art), yet their salaries keep increasing over time.
One company I know hired devs with a certain keyword on their resume, passing over another candidate with a lot less experience. I guarantee 5000 that the person they passed over would've learned all the material related to that keyword and would've put out higher quality software in less time.
The memo is wrong about private office space. Microsofties are used to it because they all have private offices (with doors and all), which is far better than cubes, but his dismissal of shared working spaces comes with no backup arguments (other than a link to a JoelOnSoftware article that talks about them expanding space--how is that a backup argument?)
I used to work in a team room environment, where all the developers sat together in one room (there were 10-15 of us or so), working on the same product. I loved working in that environment. You could talk to anyone just like that right away. Not having to walk for a minute or half a minute makes quite a difference, believe it or not. Since the barrier for asking someone for help or ideas is so low (lean over and speak), it's much easier to quickly bounce off ideas without having to interrupt your own flow. Also, you overhear others' problems and ideas, and pitch in with your own. Countless times I've heard someone lamenting some problem and was able to chip in with "oh I just solved the same issue."
Yes, you must have headphones in the team room, because sometimes you just need to concentrate and headphones are essential to drown out the noise.
Unfortunately, I am back to working in a cube and I miss the team room days.
someone who knows what's up
Core 450 minute plan is $40/mo, so the $20/mo extra is unlimited data + 200 SMS. I recently was paying $10/mo for 1MB data and 400 SMS.
This is indeed a pretty good plan.
Compare this to my Cingular $40/mo for 450 mins, then $40/mo for unlimited data and 1500 text messages for my Blackberry Pearl. That's $80/mo for a Blackberry user. (OK, I get a corp discount, so it's really $68/mo for me).
With Cingular's rollover feature, 450 minutes is plenty... I have some several thousand rollover minutes.
and this is why you should not be using C. (what)
You have gotta be kidding me, article is posted and there are no best compression test results! Lame!
Maybe Google can turn Doubleclick into a better company--who knows? I am not drawing any conclusions yet, I want to see what they do with it.
You're so right on the money.
This is the reason that Microsoft can be dethroned--when you have good design, you can beat the giants. When you have shitty design and you are a giant, your product doesn't sell (Zune, case in point).
This is why Apple is sending shivers through the phone industry with the iPhone.
I predict that 2008 will be the year of actually easy to use phones, because of the well-designed competition by the iPhone.
Thank you Apple for raising the bar.
Interesting older article on supernova burps.
The software this is affecting is loading key DLLs in the wrong order.
Whoa, since when is loading DLLs in wrong order been a problem? Any DLL that needs another DLL as a dependency will load that other DLL. So the order of loading doesn't matter, as it works out in the end.
Except that in this case, Microsoft screwed up and released the file with a conflicting base address! Hell, I don't even know why this problem even exists anymore! It's a shame that in 2007, such a problem occurs. Why would Microsoft have changed the original base addresses?
I agree with your sentiments. Especially, when I was younger, I had a much harder time understanding any lyrics.. and hell, with many of the vocals, you had to strain to comprehend. So I didn't care what the lyrics were, all I knew is that the music was heavy and angry. There was a lot of energy in it, and being a stuck-behind-the-computer-all-day nerd during highschool, I needed a way to cope with the lack of social status and social (physical) activity.
I wanted to rock out, because there was nowhere else to do it.
Alkonost is a Russian folk black metal band I've been recently listening too. It's quite good: melodic Russian folk music tunage, set against powerchords and death grunts. (*makes deathgrunt sound*)
Hey, I am not defending Vista at all, and these metrics do say something in terms of how "polished" the interface is, but give me a fucking break -- latency of menus? What a bullshit metric that is!
When was the last time you wanted to throw a shoe into the monitor because the menu had messed up latency?
I know it was long long long before yesterday, when I wanted to throw a shoe into the monitor because Windows Update rebooted my machine without saving my open documents. Now that's the kind of shit that matters.
These metrics are a bunch of self-important wankery. I bet I can come up with a set of metrics that will highlight the Windows Vista interface and make it seem better than the Apple interface (amount of fully obscured background information anyone? yeah, transparenty helps this metric)
I hear ya there.
Predatory banking is bad, but, it only works on ignorant people.
This is a false impression. The problem with predatory lending is that people who should not be lent money are given that money. This is irresponsible because the bank well knows that the borrower is in a high risk area.
So what happens is that when payments are missed, the APR shoots up from 15-some % to 25, 30%. Now, it's that much more difficult to get out of this debt (that should not have been provided in the first place). Add on top the overcharge fees, late fees and others, and you're looking at easily over 40% effective APR. It becomes a downward spiral. If the borrower eventually defaults on that loan, the credit card company gets a big tax write-off, so they don't lose all that money. If the credit card company is lucky, the borrower signs up to a debt repayment program (often credit card company backed), and diligently repays the balance with all the fees and interest charges. $$$ profit all around.
Now, this is orthogonal to the reason why people get subprime credit cards. Half of bankruptcy is due to medical bills--so many of these cards are run up for that reason.
Here is another tidbit to consider:
Big business profits motivate Bush administration's every single action:
* ignoring BofA bruhaha
* encouraging "guest worker status" to permit legal under-minimum-wage labor
* signing the bankruptcy bill
* pushing ethanol fuel (big ethanol lobby)
* against discount drugs from Canada
* crazy cronyism in Iraq (KBR, Halliburton)
I mean, there is very little that's not big business motivated.