Re: man i hate punkbuster
We'll get something out of the way quickly: it's impossible for a program of today's magnitude to be completely bug-free. One can take steps to reduce the likelihood of bugs and help avoid the "fixing one thing breaks another thing" situation but no matter how skilled you are, you have no hope of erasing the problem completely, and the best you can do is program with rigor to keep the code tight and clear. This is before one factors in other people's software and hardware.
Following that, it is impossible to make a program work on every machine. There are simply too many hardware and software combinations out there. Product testing is done in a standardized manner: a freshly formatted box with a handful of stock components and some current edition of Windows the product is intended for. I, as the developer/publisher of a software, choose my target OS and my target hardware. I could release a game with zero support for ATI cards if I so wished, and put a notice in small characters about that fact, and I'd be in my perfect legal right to do it of course.
Now to approach the grey line: I, as a software development company, am told a customer on a particular software/hardware combination cannot run my software. I have three options:
1) I fix the bug.
2) I offer the customer a replacement software.
3) I reimburse the customer.
Option 1 will cost a programmer some time to find, fix and test the bug. Say the customer paid 50$ for the software and my programmer's paid 14$ an hour. My programmer has a little more than 3.5 hours to fix the bug completely before I get past my break-even point. The major problem is that this option is a blind gamble: in most cases, the bug implies other layers of code that must also be tested, and some bugs in particular can take a programmer up to a week or even more to properly diagnose and repair. If that happens, 14 * 40 - 50 = I just ran 510$ in the red. Unless the problem is very widespread and/or I am certain after a quick look that the bug can very easily be fixed, it is not in my financial interest to fix this bug, and I will only fix it if a customer offers to pay me for the cost of doing this.
Option 2 is feasible if I have similar software to offer or something comparable - it's quite easy in the case of games, less so for workstation software and other more specific things. And it's becoming much less popular due to widespread concerns about pirating and the abuse that such a system would ensue.
Option 3 is what's left. I, the software company, tell my customer this bug will not be fixed or that this bug is really one rare case, and I tell him "OK, we cancel everything, just relinquish the software, I'll give you back your 50$, and we'll go our separate ways." The quickest and easiest solution for me, and with the least possibility of headaches - and even then, somewhat an iffy situation due to pirating again. I must remind you that you do not buy the physical code written on your CD, but for the license, the privilege to use this software; a privilege which the software company may deny to me at any time if they deem it necessary.
In truth, I might have some obligation to make an effort to care about the customer and offer him some sort of escape clause, but I get the privilege of dictating the rules of the game. And for my own protection, it is in my interest to make the rules as advantageous to me as possible.
I must reiterate this: I am under no obligation to make my software work on every machine. If this was the case, legally developing a software would be impossible unless every computer in the world ran the exact same configuration or one where the modularity of computers would be heavily restricted.
On to some more meat and potatoes. I buy a car with an engine missing. That is a defective product, and it's quite likely I'll get a replacement for it for two reasons: primo, the car company wants me coming back and buying another car from them when I decide I want another one. Secundo, it is in their interest to replace the product as a token sign that they care about the customer. In short: happy customer = money. Iffy customer = no money immediately. Scandal = no money in the long run.
Now. I buy a car only to find out that my legs are too short to reach the pedals. This is a user configuration problem. The product in itself is functional when used by someone else, but it cannot fit in the parameters set by this one customer that is myself. The car company will simply not make it so the seat can move even further ahead so I can reach the pedals. 25,000$ car versus hundreds of thousands of dollars of engineering, research & development, safety and crash testing. The car company will tell me that there is nothing they can do and that I simply cannot use this car the way I am right now.
Computer version:
I buy a software with a corrupt file on the CD. That is a defective product, and it's quite likely I'll get a replacement for it for two reasons: primo, the software company wants me coming back and buying more software from them when I decide I want more. Secundo, it is in their interest to replace the product as a token sign that they care about the customer. In short: happy customer = money. Iffy customer = no money immediately. Scandal = no money in the long run.
Now. I buy a software only to find out that there's a rare system conflict between my motherboard+video card and the software's API version and thus the software cannot run. This is a user configuration problem. The product in itself is functional when used by someone else, but it cannot fit in the parameters set by this one customer that is myself. The software company will simply not make it so it can run on my own special machine. 50$ car versus thousands of dollars of diagnostics, bugfixing, and testing on both my machine and the stock machines. The software company will tell me that there is nothing they can do and that I simply cannot use this software the way my computer is set up right now.
You can go ahead and class-action until you are blue in the face, I am fairly certain that the ratio of working versus non working in terms of BF2142's PunkBuster is adequately high. Starforce Protection, which had a much larger backlash, did not even get a lawsuit despite talks about it - I saw a few threads mentioning that but nothing further. The plan must've died on its own. Instead, the customers deciding not to buy Starforce-shielded products convinced some software companies to let go of the protection. That did the trick. The software company decided it would lose more cash from lost sales due to the protection than from pirating due to the lack of protection. Money, money, money. Class-action lawsuits are for products that are worth thousands of dollars apiece. For a 50$ software, you are going to need a frightening amount of people to hop in with you and push that suit to prove the problem is extremely widespread. And if the problem really was as bad at that, then I'd see far more threads on forums specifically talking about PB not making the game work and there not being a fix to it. In reality, what I see is the usual convo: "It doesn't work." "Update PB." "Yes, that did the trick." From what I have seen so far, very few players find themselves completely, utterly unable to play the game.
Making a new feature for a software, whether by the addition of a module, a functionality, or to support a new OS, takes far, far more than 30 minutes. In the programming world, the simplest of things can take hundreds of man-hours to accomplish. You pass by my workplace, I'll show you the contents of my hard drive. I have two gigabytes of raw code sitting on my workstation. In Java. Two gigabytes of code without the headaches associated with being compatible on the OSes we want to run our software on. Programming is not easy. It's not as easy as the movies make it. It's not as easy as anyone outside the programming world might believe. Programming is a serious and careful process, and one where you type very little and test a lot. You spend your day testing. Whenever you make a modification, you test it. You try to break it. You make sure it works under all conditions you can think of. You protect it, you stabilize it, you do whatever you can to make it so your own tiny little modification doesn't open up a hole elsewhere in the program. It sounds stupid, but that's the reality of it. There's no other way I can put it. Not even college education gives an accurate depiction of programming in a professional environment. The average programming school project is a featherweight in comparison to the monsters you'll find in enterprises. It's a meager asteroid compared to the sun itself.
Now to expand on the beta problem. In practice, EvenBalance is probably testing its software on beta versions of Windows 7 in order to save a bit of time, and they'll release their W7-compatible version of PunkBuster within a few weeks or months of Windows 7's own after testing on the finished, released product. It's very unlikely Microsoft will pull the plug on its own OS out of nowhere, so EvenBalance can be fairly confident that things will work out as usual, yaddah yaddah.
In theory, however, things can possibly take a radical turn. There can be a change in the core features. There can be a re-run of tests and development and a second (or even third) beta. There can be additions and subtractions to the underlying structure of the OS such that my own software no longer works on it and forces me to rework the code I have done to comply with the new way things have to go. And in the case of PunkBuster, this is extremely important since it has to examine other processes the user is running. I don't want to pay programmers to redo work over and over again just to follow the fluctuations of a beta and satisfy gamers who run said beta OS - and I must remind that during this entire development process, I am not making money. It is not worth it. A beta OS is sent out for testing of its core features. It's not for one to install every one of his programs on and use it as his mainstream OS - it'd be like taking a concept car out for a rally. I'd only be asking for trouble if I did that.
Here's how things will play out: Microsoft will release Windows 7. EvenBalance will make final preparations to PunkBuster and make it ready for all W7-compatible games. You will install Windows 7, Battlefield 2142, and update PunkBuster to make it compatible on your machine. You will play Battlefield 2142, PunkBuster will statistically stay put and behave itself, and that'll be the end of the story.
And now, the tl;dr version:
Why would I fix a bug? To make money.
Why would I not fix a bug? To save money.
Why would I help this customer? To increase my chances of making more money off him.
Why would I not help this customer? Because it will cost too much money.
Why do I need to show like I care? Because customers will think I care, and they will give me money to buy my stuff.
Why would I develop this new feature? Because I'll make more money from customers being interested and buying my software for that feature, than I will lose money from developing that feature.
Why is EvenBalance most likely preparing PunkBuster for Windows 7? To be on more new games and make more money.
Why is EvenBalance not releasing a stable version of PunkBuster for a beta OS? Because it costs too much money.
Stay put, remain patient, and hang on to your current OS. If you can't play the game on the beta of Windows 7, then play it on your other stable Windows.
We'll get something out of the way quickly: it's impossible for a program of today's magnitude to be completely bug-free. One can take steps to reduce the likelihood of bugs and help avoid the "fixing one thing breaks another thing" situation but no matter how skilled you are, you have no hope of erasing the problem completely, and the best you can do is program with rigor to keep the code tight and clear. This is before one factors in other people's software and hardware.
Following that, it is impossible to make a program work on every machine. There are simply too many hardware and software combinations out there. Product testing is done in a standardized manner: a freshly formatted box with a handful of stock components and some current edition of Windows the product is intended for. I, as the developer/publisher of a software, choose my target OS and my target hardware. I could release a game with zero support for ATI cards if I so wished, and put a notice in small characters about that fact, and I'd be in my perfect legal right to do it of course.
Now to approach the grey line: I, as a software development company, am told a customer on a particular software/hardware combination cannot run my software. I have three options:
1) I fix the bug.
2) I offer the customer a replacement software.
3) I reimburse the customer.
Option 1 will cost a programmer some time to find, fix and test the bug. Say the customer paid 50$ for the software and my programmer's paid 14$ an hour. My programmer has a little more than 3.5 hours to fix the bug completely before I get past my break-even point. The major problem is that this option is a blind gamble: in most cases, the bug implies other layers of code that must also be tested, and some bugs in particular can take a programmer up to a week or even more to properly diagnose and repair. If that happens, 14 * 40 - 50 = I just ran 510$ in the red. Unless the problem is very widespread and/or I am certain after a quick look that the bug can very easily be fixed, it is not in my financial interest to fix this bug, and I will only fix it if a customer offers to pay me for the cost of doing this.
Option 2 is feasible if I have similar software to offer or something comparable - it's quite easy in the case of games, less so for workstation software and other more specific things. And it's becoming much less popular due to widespread concerns about pirating and the abuse that such a system would ensue.
Option 3 is what's left. I, the software company, tell my customer this bug will not be fixed or that this bug is really one rare case, and I tell him "OK, we cancel everything, just relinquish the software, I'll give you back your 50$, and we'll go our separate ways." The quickest and easiest solution for me, and with the least possibility of headaches - and even then, somewhat an iffy situation due to pirating again. I must remind you that you do not buy the physical code written on your CD, but for the license, the privilege to use this software; a privilege which the software company may deny to me at any time if they deem it necessary.
In truth, I might have some obligation to make an effort to care about the customer and offer him some sort of escape clause, but I get the privilege of dictating the rules of the game. And for my own protection, it is in my interest to make the rules as advantageous to me as possible.
I must reiterate this: I am under no obligation to make my software work on every machine. If this was the case, legally developing a software would be impossible unless every computer in the world ran the exact same configuration or one where the modularity of computers would be heavily restricted.
On to some more meat and potatoes. I buy a car with an engine missing. That is a defective product, and it's quite likely I'll get a replacement for it for two reasons: primo, the car company wants me coming back and buying another car from them when I decide I want another one. Secundo, it is in their interest to replace the product as a token sign that they care about the customer. In short: happy customer = money. Iffy customer = no money immediately. Scandal = no money in the long run.
Now. I buy a car only to find out that my legs are too short to reach the pedals. This is a user configuration problem. The product in itself is functional when used by someone else, but it cannot fit in the parameters set by this one customer that is myself. The car company will simply not make it so the seat can move even further ahead so I can reach the pedals. 25,000$ car versus hundreds of thousands of dollars of engineering, research & development, safety and crash testing. The car company will tell me that there is nothing they can do and that I simply cannot use this car the way I am right now.
Computer version:
I buy a software with a corrupt file on the CD. That is a defective product, and it's quite likely I'll get a replacement for it for two reasons: primo, the software company wants me coming back and buying more software from them when I decide I want more. Secundo, it is in their interest to replace the product as a token sign that they care about the customer. In short: happy customer = money. Iffy customer = no money immediately. Scandal = no money in the long run.
Now. I buy a software only to find out that there's a rare system conflict between my motherboard+video card and the software's API version and thus the software cannot run. This is a user configuration problem. The product in itself is functional when used by someone else, but it cannot fit in the parameters set by this one customer that is myself. The software company will simply not make it so it can run on my own special machine. 50$ car versus thousands of dollars of diagnostics, bugfixing, and testing on both my machine and the stock machines. The software company will tell me that there is nothing they can do and that I simply cannot use this software the way my computer is set up right now.
You can go ahead and class-action until you are blue in the face, I am fairly certain that the ratio of working versus non working in terms of BF2142's PunkBuster is adequately high. Starforce Protection, which had a much larger backlash, did not even get a lawsuit despite talks about it - I saw a few threads mentioning that but nothing further. The plan must've died on its own. Instead, the customers deciding not to buy Starforce-shielded products convinced some software companies to let go of the protection. That did the trick. The software company decided it would lose more cash from lost sales due to the protection than from pirating due to the lack of protection. Money, money, money. Class-action lawsuits are for products that are worth thousands of dollars apiece. For a 50$ software, you are going to need a frightening amount of people to hop in with you and push that suit to prove the problem is extremely widespread. And if the problem really was as bad at that, then I'd see far more threads on forums specifically talking about PB not making the game work and there not being a fix to it. In reality, what I see is the usual convo: "It doesn't work." "Update PB." "Yes, that did the trick." From what I have seen so far, very few players find themselves completely, utterly unable to play the game.
Making a new feature for a software, whether by the addition of a module, a functionality, or to support a new OS, takes far, far more than 30 minutes. In the programming world, the simplest of things can take hundreds of man-hours to accomplish. You pass by my workplace, I'll show you the contents of my hard drive. I have two gigabytes of raw code sitting on my workstation. In Java. Two gigabytes of code without the headaches associated with being compatible on the OSes we want to run our software on. Programming is not easy. It's not as easy as the movies make it. It's not as easy as anyone outside the programming world might believe. Programming is a serious and careful process, and one where you type very little and test a lot. You spend your day testing. Whenever you make a modification, you test it. You try to break it. You make sure it works under all conditions you can think of. You protect it, you stabilize it, you do whatever you can to make it so your own tiny little modification doesn't open up a hole elsewhere in the program. It sounds stupid, but that's the reality of it. There's no other way I can put it. Not even college education gives an accurate depiction of programming in a professional environment. The average programming school project is a featherweight in comparison to the monsters you'll find in enterprises. It's a meager asteroid compared to the sun itself.
Now to expand on the beta problem. In practice, EvenBalance is probably testing its software on beta versions of Windows 7 in order to save a bit of time, and they'll release their W7-compatible version of PunkBuster within a few weeks or months of Windows 7's own after testing on the finished, released product. It's very unlikely Microsoft will pull the plug on its own OS out of nowhere, so EvenBalance can be fairly confident that things will work out as usual, yaddah yaddah.
In theory, however, things can possibly take a radical turn. There can be a change in the core features. There can be a re-run of tests and development and a second (or even third) beta. There can be additions and subtractions to the underlying structure of the OS such that my own software no longer works on it and forces me to rework the code I have done to comply with the new way things have to go. And in the case of PunkBuster, this is extremely important since it has to examine other processes the user is running. I don't want to pay programmers to redo work over and over again just to follow the fluctuations of a beta and satisfy gamers who run said beta OS - and I must remind that during this entire development process, I am not making money. It is not worth it. A beta OS is sent out for testing of its core features. It's not for one to install every one of his programs on and use it as his mainstream OS - it'd be like taking a concept car out for a rally. I'd only be asking for trouble if I did that.
Here's how things will play out: Microsoft will release Windows 7. EvenBalance will make final preparations to PunkBuster and make it ready for all W7-compatible games. You will install Windows 7, Battlefield 2142, and update PunkBuster to make it compatible on your machine. You will play Battlefield 2142, PunkBuster will statistically stay put and behave itself, and that'll be the end of the story.
And now, the tl;dr version:
Why would I fix a bug? To make money.
Why would I not fix a bug? To save money.
Why would I help this customer? To increase my chances of making more money off him.
Why would I not help this customer? Because it will cost too much money.
Why do I need to show like I care? Because customers will think I care, and they will give me money to buy my stuff.
Why would I develop this new feature? Because I'll make more money from customers being interested and buying my software for that feature, than I will lose money from developing that feature.
Why is EvenBalance most likely preparing PunkBuster for Windows 7? To be on more new games and make more money.
Why is EvenBalance not releasing a stable version of PunkBuster for a beta OS? Because it costs too much money.
Stay put, remain patient, and hang on to your current OS. If you can't play the game on the beta of Windows 7, then play it on your other stable Windows.
,But admin are hacks to the clans they like and kick you too so they get top:shock:
Comment