I have been at my family's ranch in Wyoming for the past 3 days. I made a stop here to see the family on my way driving home to Minnesota from California (after that I'm going to Cleveland wish me luck). While here my younger brother and two of his friends he brought with him spent quite a bit of time playing Warcraft 3. They all piggy backed on my younger brothers CD key and played LAN games. I showed them the ways of DOTA and they quickly wanted to get on battle.net. My brother wanted me to give his friend my CD key so that they could play together on battle.net. I refused. He was quite upset and did not understand why I would not give up my key to him.
In truth, my reasoning was twofold. First of all, I understand how key sharing spreads; I give it to him and he gives it to his friend to use this time, then he wants another friend playing a month down the road, and before long my key is in the hands of several of his friends and perhaps his friends' friends. I want my copy to remain my own. The second reason was a matter of piracy. Since getting a "real job" and having money I can spend on things, I have not pirated games. It got me thinking about shades of piracy, and the ethics of it.
My main concern with piracy is that it leads to worse and worse DRM being put into software and media. It makes the software/media less usable and can often cause the removal of features.
As I see it there are 6 types of piracy: Operating System, Application, Game, Movie, Music, Television, and book
There are really only two operating systems pirated in the world, Mac and Windows.
Piracy against the Mac operating system is pretty sad because they are trusting enough to not require any keys or validation of their OS and in the scheme of things their OS is pretty inexpensive. That being said, most of their profits do not come from OS sales since it is bundled with their computers. If you are pirating their OS you are likely building a hackintosh, which means you are probably not dying to give Apple your money. However, if Mac OS piracy gets out of control they might start putting DRM in it, and no one wants that.
Piracy against the Windows operating system is also a grey area. The product is usually priced much higher than it is actually worth. A handicapped version of the OS is unfortunately packaged with every PC on the market along with a bunch of useless software (looking at you AOL). Meaning that anyone who actually knows about computers should wipe and reinstall a clean copy of windows onto their new computers. Another issue is license binding to hardware. So you have bought a PC with windows bundled. But now you want to change the parts around, maybe upgrade the processor. Now your bundled copy no longer works because your hardware has been upgraded (this was how it was with XP they may have changed it in vista or 7). You shouldn't need to repurchase the same OS because you wanted to update your computer. Also, Microsoft would rather you pirated their software than learned how to use Linux. So if you are making the choice between ubuntu and a cracked XP copy, Microsoft would rather that you use the cracked XP copy even if they don't get a sale.
Windows is pirated all over the world and there are people who pirate the new Mac versions rather than paying for them. My decision on the subject is that if you are a company or business large or small you MUST buy every copy you use for that business of either OS. If you can easily afford to buy the OS and are a private user you should at least buy 1 copy and use it on all of your and your immediate families' machines. If you are stinking rich you could go the whole nine yards and buy a copy for every machine you put it on (Though honestly the Mac family licenses aren't that bad). If you have a job where you use a computer the OS on that computer MUST have a legal copy of the OS.
Applications I view by use case. If it is an application that is meant to be used by hobbyists or anyone and is priced accordingly you should buy it. If it is a professional piece of software meant for someone who makes money off of its use then as long as you do not make money off of its use you can pirate it. As soon as your use for it moves from simple hobby to moneymaking business then you MUST buy the application. If you are a business small or large you MUST buy every application you use. As an example if you are a college student teaching yourself to make a webpage and you want to use Dreamweaver and Photoshop then as long as you are not making money off of it I think it is fine to pirate them. The moment people start paying you to make websites you need to have legal copies of those programs.
Games are a specific subset of applications. The main use case of games is never one of making money off of it. So ethically if you want to play a game you should buy or rent it. That said if someone lends you a copy of a game that is fine, but with the understanding that there is still only one working license of that game in existence. That is they do not keep the game working on their machine and continue playing it while you have it on yours. I think pirating a game to test run it is fine too, provided you don't play it for more than an hour or so. In gaming, piracy leads to some of the worst DRM in existence (looking at you EA). It also leads to companies removing things that should be part of games. My example is that Starcraft 2 will not have LAN play specifically because of the activities my brother and his friends were doing. They each got at least 7-10 hours of play in over the last 3 days of Warcraft 3. I can understand why they should have had to buy the game. I don't like Blizzard as a company. I really hate WoW and the way they run battle.net. But it is in part the consumer's fault for the success of WoW. If every person on the planet who played a Blizzard game for more than an hour had purchased the game, they would have seen more incentive to make more RTS and Diablo games. Instead they saw a market for the MMO and subscription services and went where the money was. That philosophically is why I refused to give my brother my key. Because I knew the effect that kind of piracy was having on the gaming world.
Music movies and television are each extremely complicated in terms of the ethics of piracy.
The music industry is broken in many ways. As soon as fans start believing that they are hurting the artists by pirating their songs most will stop. Also piracy clearly hasn't killed the music industry. I would say if you want to pirate music make sure you go to concerts of the bands you like, and buy a CD of a band you like every once in a while, even if you already pirated it. Itunes now has DRM free songs, so if you have one stuck in your head that you will listen to for a week straight spend a dollar on it. Basically give the industry feedback on good things because if everyone pirates everything then the good artists wont rise to the top (hahah as if they do now..).
Movies are better in the theater. They just are. Most of the time. When you don't have a bunch of people shouting at the screen... Because of that, I will not watch a camcorder recording of a movie. I will watch a prerelease dvd rip though. I honestly think there are some movies that must be watched in theaters. Then there are some that are crap and aren't worth your money. The term for those movies used to be "its a rental". I think that perhaps movies should be priced not only on more than time of day they show, but also by the demand of the movie. How many people are seeing it should affect its price. But right now prices aren't determined that. So, I say if the movie looks sweet see it in theaters. If you miss it in theaters, get it anyway you can. If you like it buy the DVD. If the movie looks crap, but you still want to watch it, watch it somehow. If it was actually pretty good, buy it or suggest a friend buy or rent it. I have a huge DVD collection. Bigger than anyone I know. I support movies I like and I don't care about movies I don't.
TV is extra tricky because you don't really pay for it outside of your cable bill. You pay for it by watching advertisements. So it feels pretty stupid to be told you are pirating something if you have it on your computer and you would have paid for it by watching a commercial. My thought is, if you liked the show a lot and have the cash, get the DVD box set. If you have the option, which you increasingly do now, watch the show online rather than watching a downloaded copy of it.
Book piracy is an issue that has gotten worse with the advent of the kindle and Ebooks. There are libraries where you can get books freely. So what is really the difference between getting the book from the library and pirating the book to your computer? The only book I have ever pirated was a college textbook. I pirated it because the college bookstore never stocked the damned thing, and I bought it at the end of the semester because I wanted a real book to study for the final with. I think if you like a book or are going to use it a lot buy a copy, digital or hard. I understand college textbooks are a tricky issue because you are poor when you are in college and the textbooks are expensive and pirating is a cheap alternative. I honestly don't know where I stand on that issue. I bought every textbook I have ever used, usually at a price higher than I should have. But I sympathize with people who cannot afford the textbooks. There are several alternatives to piracy for getting cheap textbooks at most colleges though, such as they book swaps or borrowing.
Lastly, my golden rule for piracy is that if you are giving pirated material to someone else and getting money for it, that is WRONG. You should never accept money in exchange for pirated material.
I believe that piracy does not have to be detrimental to any of the systems listed here. It can get people interested or using things that they otherwise would not have spent money on. If you share my views or disagree with them please leave a comment. I would love to hear your opinion.
Monday, August 17, 2009
Standing Up For Best Practices Right Out Of College
This past summer I was employed as an intern for a high profile software company. I must admit I was afraid that I would be unprepared for the real world of Software Engineering. These fears came from many articles I have read in the past, some of which were linked in a previous post here. Basically, I was worried that I didn't feel like I knew anything about unit testing, scrum teams, agile software dev, and many other software development tools/practices that should be taught in schools and aren't.
The one tool/practice I did know about was version control. In my junior year of college I took an advanced game design class where I lead a team of programmers and artists to make a game. Version control was of paramount importance for the success of our team. We used a subversion repository with branches and very regular check ins. You checked your code in the moment you were done working on it and checked it out the moment you started working. If there were conflicts you merged them as well as you could.
Now I felt like I was quite successful in my internship this past summer. I was mostly working on a simple tool for internal use and I was the only developer on that tool. However, there was another project I was also working on. A separate project that I was a small part of. This project was mainly run by a team in China. The source of the project needed serious retooling before I could implement my part. This retooling was not needed because to the current team had coded the software poorly but because the software was the result of several intern projects over several years, and there was a lot of copy/pasted code and a overall lack of design in the source.
I wanted to check up on the source periodically so I could see where it was going, how it was developing, basically get a feel for the new architecture before I had to dive in and code in it. The problem was that the China team refused to check in their code base until it was stable. There was no trunk/branch hierarchy there was one codebase and changes between versions were not a gradual stepwise process but they were sudden and massive. They would go upwards of weeks between check-ins.
I was obviously shocked by this. Good version control practices do not involve weeks between check-ins and everyone working from one branch. I approached my manager with the problem and he understood the situation and wanted to fix it. I was quite fortunate that my manager had a Degree in Computer Science and was not interested in deadlines so much as getting a quality piece of software.
We had a meeting specifically about the process. At this point I would like to take an aside and say that the Chinese-American accent is my least favorite accent in the world. It is extremely difficult for me to understand and I personally dislike listening to it. A lot. In college I had several professors with thick Chinese-American accents and I could not understand them in lecture 90% of the time. It annoyed me more because during the short bits where I was both alert enough to understand them and they were speaking semi-coherently I recognized that they understood the material and were actually making a very decent attempt and using examples and language that put the ideas across well. Understand that I do not have any dislike of the Chinese because of this accent; it just makes the exchange of ideas harder for me personally.
That being said during the meeting we had there were several times where I had no idea what the team from China was saying. Thankfully my manager did. I tried explaining to them that once we have a solid trunk in place that is stable code for our project any changes to be made should be done in separate branches. Those branches should be checked in daily and the modified branch should be fully reviewed by the team before it is merged with the trunk. The branches should be structures in such a way that makes sense to minimize merging issues and makes logical sense with the development going on. This was a process that seemed to me a no brainer and I was shocked that they were not using it.
I then went on leave for a few days. When I got back I had emails in my inbox explaining why these methods did not make sense for the project and why they felt like they should not need to implement them. They also did not seem to understand that I was not the only one who needed to branch when the code was being modified but that no one should be touching the trunk directly. I was again extremely thankful for my manager who insisted that it was a practice that needed to be adopted by our team. He had responded to their emails before I got the chance.
I must put across that I do not believe that this was a regular practice throughout the company. I think most of the major products that we produced used best practices and that this was the exception. It just happened to be the exception that I had to deal with.
I do not honestly believe this to be that uncommon an occurrence especially as more and more software jobs are outsourced to other countries. You may find yourself in a job where you are working with people who through poor teaching or management, or simply through laziness do not follow standard software practices. And your job may get progressively harder because of this. I must admit I do not think that the team would have changed its ways if my manager had not backed me up on the practice. People are just not likely to take advise from the new employee, much less an intern.
This all said I have a few messages for people in the field of Software Engineering.
College students and new hires: learn the best practices for whatever you are working on. Use them, and instruct others to use them. Stand up for them at work if you see they are not being followed. It will make your job easier in the long run, and make a better product because of it.
Older software developers (some of this goes for new guys too): don't get lazy. Many of you know the best practices but choose to ignore them. Take pride in your work and do things right. Test your code, do personal reviews on your code, do peer reviews on your code, write your code so when someone else looks at it they will be impressed by how readable and elegant it is. Use version control. Follow the practices your company has decided you should use, and if you feel like there is a better practice or a better way to do something bring it up and suggest it.
Managers: read up on the best software practices. Buy books. Listen to your employees. Push them and encourage them to do better but don't have them working so hard they need to cut corners to make deadlines. If you can learn anything from Windows Vista and peoples unwillingness to upgrade from XP, learn that no matter how many new features and how shiny you make software, if it is poor quality software people wont buy it or upgrade to it.
The one tool/practice I did know about was version control. In my junior year of college I took an advanced game design class where I lead a team of programmers and artists to make a game. Version control was of paramount importance for the success of our team. We used a subversion repository with branches and very regular check ins. You checked your code in the moment you were done working on it and checked it out the moment you started working. If there were conflicts you merged them as well as you could.
Now I felt like I was quite successful in my internship this past summer. I was mostly working on a simple tool for internal use and I was the only developer on that tool. However, there was another project I was also working on. A separate project that I was a small part of. This project was mainly run by a team in China. The source of the project needed serious retooling before I could implement my part. This retooling was not needed because to the current team had coded the software poorly but because the software was the result of several intern projects over several years, and there was a lot of copy/pasted code and a overall lack of design in the source.
I wanted to check up on the source periodically so I could see where it was going, how it was developing, basically get a feel for the new architecture before I had to dive in and code in it. The problem was that the China team refused to check in their code base until it was stable. There was no trunk/branch hierarchy there was one codebase and changes between versions were not a gradual stepwise process but they were sudden and massive. They would go upwards of weeks between check-ins.
I was obviously shocked by this. Good version control practices do not involve weeks between check-ins and everyone working from one branch. I approached my manager with the problem and he understood the situation and wanted to fix it. I was quite fortunate that my manager had a Degree in Computer Science and was not interested in deadlines so much as getting a quality piece of software.
We had a meeting specifically about the process. At this point I would like to take an aside and say that the Chinese-American accent is my least favorite accent in the world. It is extremely difficult for me to understand and I personally dislike listening to it. A lot. In college I had several professors with thick Chinese-American accents and I could not understand them in lecture 90% of the time. It annoyed me more because during the short bits where I was both alert enough to understand them and they were speaking semi-coherently I recognized that they understood the material and were actually making a very decent attempt and using examples and language that put the ideas across well. Understand that I do not have any dislike of the Chinese because of this accent; it just makes the exchange of ideas harder for me personally.
That being said during the meeting we had there were several times where I had no idea what the team from China was saying. Thankfully my manager did. I tried explaining to them that once we have a solid trunk in place that is stable code for our project any changes to be made should be done in separate branches. Those branches should be checked in daily and the modified branch should be fully reviewed by the team before it is merged with the trunk. The branches should be structures in such a way that makes sense to minimize merging issues and makes logical sense with the development going on. This was a process that seemed to me a no brainer and I was shocked that they were not using it.
I then went on leave for a few days. When I got back I had emails in my inbox explaining why these methods did not make sense for the project and why they felt like they should not need to implement them. They also did not seem to understand that I was not the only one who needed to branch when the code was being modified but that no one should be touching the trunk directly. I was again extremely thankful for my manager who insisted that it was a practice that needed to be adopted by our team. He had responded to their emails before I got the chance.
I must put across that I do not believe that this was a regular practice throughout the company. I think most of the major products that we produced used best practices and that this was the exception. It just happened to be the exception that I had to deal with.
I do not honestly believe this to be that uncommon an occurrence especially as more and more software jobs are outsourced to other countries. You may find yourself in a job where you are working with people who through poor teaching or management, or simply through laziness do not follow standard software practices. And your job may get progressively harder because of this. I must admit I do not think that the team would have changed its ways if my manager had not backed me up on the practice. People are just not likely to take advise from the new employee, much less an intern.
This all said I have a few messages for people in the field of Software Engineering.
College students and new hires: learn the best practices for whatever you are working on. Use them, and instruct others to use them. Stand up for them at work if you see they are not being followed. It will make your job easier in the long run, and make a better product because of it.
Older software developers (some of this goes for new guys too): don't get lazy. Many of you know the best practices but choose to ignore them. Take pride in your work and do things right. Test your code, do personal reviews on your code, do peer reviews on your code, write your code so when someone else looks at it they will be impressed by how readable and elegant it is. Use version control. Follow the practices your company has decided you should use, and if you feel like there is a better practice or a better way to do something bring it up and suggest it.
Managers: read up on the best software practices. Buy books. Listen to your employees. Push them and encourage them to do better but don't have them working so hard they need to cut corners to make deadlines. If you can learn anything from Windows Vista and peoples unwillingness to upgrade from XP, learn that no matter how many new features and how shiny you make software, if it is poor quality software people wont buy it or upgrade to it.
Subscribe to:
Comments (Atom)