reply to the three (3) of classmates' answers with value-added replies (e.g., not just "I agree") Classmate 1 – Brendan: 1. Yes, I think if you've worked in software development for even a few months, you realize that lack of documentation is sometimes a problem. I try to write comments responsibly, but there's certainly nowhere near optimal documentation in much of what I develop, I think primarily because we as developers are under a lot of pressure to produce results as efficiently as possible. When you're working on a project for a company, you're focused on solving problems and producing a viable product. You're not usually too worried about the potential for another developer to come in a year from now, pick up where you left off, and be confused. I also don't think this is the fault of developers, at all. I think companies should place more value on documentation and seek out the proper writing of documentation... IF they think it's necessary. The goal of any business is to make money. And they don't like losing money, so something tells me that if it were necessary, they would already be encouraging the writing of better documentation in order to prevent losing money down the road (and some companies do really prioritize documentation). Outside of business, if a project has poor documentation, I can either accept the risk and the time/effort it may take to understand it, or reject it. The problem solves itself (usually because I reject it and find something better). When I have worked with code w/ poor documentation, it usually takes significantly longer to use the code. But like I said, it's a cost-benefit analysis. If there's a dozen other options, I won't bother trying to understand it. 2. No (to both). If I release absolute garbage code, so be it. Other developers can choose to use that code or not. And a business can choose to fire me if they aren't pleased with my work. To be honest, I'm not really sure how this is an ethical issue. We write code to solve problems. If our code is so terribly written and it falls apart easily under certain conditions, then no one is going to use it. It's the responsibility of the developer who is using that code to determine whether or not they should be using it. And technology moves fast. There's always going to be better implementations of a solution, and the best implementations usually rise to the top. People don't like software that constantly breaks, and developers don't like software they can't understand b/c of poor documentation. I think it fixes itself. 3. I didn't really understand this in the article. Don't people already realize code (and tech in general) can be unreliable? If I'm looking for a package for one of my projects and the first thing I see on the Github page is "This code might be unreliable", I'm closing the page immediately (lol). No one is going to want to use anything that has a warning like that on it. It's like going to a restaurant and them telling you "the food might suck". It's like, yeah, it might -- and I already assume this with any code I use from other developers -- but telling people that is just going to drive them away. Classmate 2 -Cameron: 1. Do you agree with Robin’s initial point that lack of code documentation and quality is an issue in software today? Have you ever worked with a piece of code that had little documentation? If so, how quickly were you able to adapt and effectively use that code? I agree with Robin's initial point completely. I dont know how many times ive looked at code where it would have been 10x easier to read and understand if it was documented correctly. Especially in more functional languages, it would be nice to know what the more functional lines of code since the code is much more complex and condensed than non-functional languages. This is a big issue, and I think everyone needs to learn to effectively and efficiently document their code, whether its while they are developing or after development is done. I have had experiences where i was able to understand undocumented code, but it took way longer than it would of if it was documented. 2. Do you believe that programmers should be more responsible for the code they release, either closed source to a private company or open source to the community? Do you believe that releasing code with a lack of quality violates any ethical principles? I thing programmers should be completely responsible for the code they release, whether it be closed source to a private company or open source to the community. If its your code you should be responsible for it. I know that there are still controversies whether your online data is actually your owned property, but I still think they should be responsible for it. its like driving a car to me, if you hit someone the driver should be responsible, and a programmer is the driver of that project/program. I dont think that releasing code with a lack of quality violates any ethical principles. I think if that code did something unethical or is used to do something unethical, then I think it should violate ethical principles. But just releasing code that isn't very quality should violate any ethical principles in my honest opinion. 3. Do you believe that Robin’s solution of telling people who use certain code that it may be unreliable is a good solution? Do you have any other ideas on how the relationship between the developers who use code and the ones who create it can be improved? I think it is a good solution, whether its the best one could be up for debate. Telling people who use certain code that is may be unreliable is certainly helpful, but unreliable doesn't mean it doesn't work. People may still be inclined to use that code even though it is unreliable. If that code gets the job done 80% of the time why wouldn't they keep using it, until they come up with or find a better solution. The only idea that I can think of on improving developer and creator relations would be to document the code as best as they can. If code is documented correctly the developer should in theory have absolutely no questions about that code at all. They should be able to read the code and figure out what is going on and what the logic and thought process was behind the code. But of course no-one wants to take the time to efficiently document their code. Im not sure whether they just dont have the time, dont want to do it, dont see a need to do it, or are just lazy, but if code was documented the way it should be there should be a great relationship between the developers and the creator/creators of the code. Classmate 3 – Yuhui: Hi Benjamin Whitehead, 1. I have not much working experience, but according to my personal experience, I agree that lack of documentation and quality can be a disturbing issue, especially when the coder has not good coding habits. Different coder thinks in different way, and it takes me a lot of time to understand a disorganized code without any documentation and comment. 2. For the closed source code, I think programmers “must” be responsible for their code, because they usually get payment for that. For the open source code to the community, I think programmers “should” be responsible for it. I think there is a difference because the degree of duty is different. The duty gets bigger if one gets payment. Releasing code with a lack of quality means the coder did not do his duty, and according to Kant, this action has not moral worth. Personally, I agree Kant on this point that it is not moral. Not “immoral”, but “nonmoral”. 3. As what Robin said, it sounds odd. I have no idea whether it is a good situation, but at least it should be helpful. I think have stronger moral education to every coder can be a helpful method, especially to those new coders. Like in UNH, when I was a new coder, my professor asked us to write organized code. Those unorganized part will cause students to lose points. Therefore, until right now, I still have the coding habit I took at that time. 
Purchase answer to see full attachment