Homework #3 - 8/27

Problem set:

10.6) A multimedia virtual museum system offering virtual experiences of ancient Greece is to be developed for a consortium of European museums. The system should provide users with the facility to view 3-D models of ancient Greece through a standard web browser and should also support an immersive virtual reality experience. What political and organizational difficulties might arise when the system is installed in the museums that make up the consortium?

The fact that the system would be used across multiple countries in Europe brings up several problems. The system would have to comply to several different governmental regulations and standards. Where would the data be hosted? Which country should have the database of the models? Which country should pay to develop the system? Who should be in charge of maintenance? Should the responsibility be divided across multiple countries? Would it make intercommunication more difficult? It would need to support multiple languages. The list could go on...

10.10) You are an engineer involved in the development of a financial system. During installation, you discover that this system will make a significant number of people redundant. The people in the environment deny you access to essential information to complete the system installation. To what extent should you, as a systems engineer, become involved in this situation? Is it your professional responsibility to complete the installation as contracted? Should you simply abandon the work until the procuring organization has sorted out the problem?

I would advise my managers of the situation as needed, but otherwise, stay out of it. Sure, it is my professional responsibility to complete the installation, but if someone is denying me essential information, I obviously cannot continue, and I obviously am not going to escalate things by attempting to force it from them.

Homework #2 - 8/27

Responses for "No Silver Bullet", "Kode Vicious", and "Software Analytics: So What?":

     First of all, "No Silver Bullet" was probably my favorite article of the three because the author made his case in such a systematic and thorough fashion. He begins with talking about the growth and advancement of computer hardware in tandem with its reduction in cost during the past few decades and how the transistor along with other electronics and organizational methods made that progress possible. It was the one thing that solved all of the problems, a kind of "silver bullet" for the obstacles of growth at the time. He then points out that there is no such silver bullet for software development progress and likely will not be in the future. There are many reasons that he points out, but the main one that stuck with me was complexity. He says "Software entities are more complex for their size than perhaps any other human construct...". I always thought this was the case, somehow, but now seeing someone else point it out, and give reason why totally validates what I thought, sometimes, to be self-pity. The author has several other attributes of software that make it unlikely to see the same progress as hardware, such as there not being any good way to visualize your product, unlike anything made in the physical world, where you can have blueprints, measurements, and scale prototypes. He then goes on to talk about how the progress software development has seen is due to the solving of the "accidental difficulties". This includes the advent of the high-level programming language, saving time and increasing productivity by abstracting the language from the machine instructions. Of course, with most things in this article, there is a negative side to the subject, as the author points out the limits of the different strategies of increasing productivity.

     The amazing thing about this article is that in spite of all of these difficulties and the limits of the past breakthroughs, the author hold out hope for progress. He says that creating a kind of software development repository, where programmers can reuse code from other projects to apply to theirs. This kind of situation would require the collaboration of many companies and government departments to pitch in and add to the bank of code. While I do think this would greatly increase programmers' productivity, I don't see it happening for a while. To a degree, I'm glad though, because it would mean less programming jobs and probably reduced pay as well. Another strategy that the author points out would be to grow code instead of building it. This entails building small portions at a time to get them working and tested, then add to it incrementally, making sure each part is working as you go. I really like this idea, and am going to try and employ it as much as I can while coding, as it prevents you from doing a bunch of coding and having to track down the bug when finally testing it. Finally, the author says that we must find a way to turn any software designer into a great software designer, as the difference between the two is a big one, and if it were possible to make all designers great ones, we would significantly increase our overall productivity. He points out that great programmers and managers are equally rare, but, amusingly, he doesn't see companies spending as near as much effort in finding and cultivating great programmers.  I'm all for this one as well, it makes a lot of since to strive towards this goal. There may be no "silver bullet", but I agree with everything professor Brooks has presented in this essay and am looking forward to the bumpy road ahead. 

     Well, there's 500 words already....but we'll continue on. The next article, "Kode Vicious", is more of an editorial response to readers' questions. The author points out some great practices to use while programming, though. The first is about knowing when to just quit and instead do something else, which may be any number of things. I have run into this feeling several times over my scholastic career, and the most common thing I do is to start fresh, or reconsider my approach to the problem. Hopefully, after taking this course, I will have become better at taking the right approach from the start. The other programming practice the author points out is to use the scientific method while fixing bugs. Document each bug, give a theory of why you think it is happening, possible solutions, and whether or not the theory was proved, or disproved after the fix was applied. While this sounds like a great idea to use when programming in the workforce, I don't see myself using it as a student. The programs we write are usually too small or simple to require such meticulous practices. I just hope I can remember and utilize it after I graduate.

     The final article, "Software Analytics: So What?", seems a little more abstracted than the others and is a little harder to grasp. From what I understand, software analytics is basically the process of mining software development data, either past or present, to improve the quality of the software currently being developed. This means things like looking at patterns in old projects to see obstacles they encountered and how they solved them. This is very similar to one of the proposed solutions from the first article on how to increase software development productivity, a sort of global repository on solutions to common problems. One of the easier points to understand that the article makes is that if you have a commonly asked question, you should build a toolkit to address it; If you have an infrequent question, you should deploy a data scientist before deploying any toolkit. I will be interested to see what software analytics evolves into and how it will aid software development in the future.

Homework #1 - 8/22

Problem set:

1.3) What are the four important attributes that all professional software should have? Suggest four other attributes that may sometimes be significant.

The four main attributes all professional software should have are:

• Maintainability - The software should be written in a fashion that it may be easily modified to meet any future needs.
• Dependability and security - This software should not cause any physical or economic damage in the event of a failure and it should not allow malicious users to access or damage the system.
• Efficiency - The software should not waste system resources and should be responsive.
• Acceptability - The software has to be accepted by the customer for which it was designed.

1.8) Discuss whether professional engineers should be certified in the same way as doctors or lawyers.

I am somewhat torn on this subject, but I think I'm leaning towards no. The reason being, is that lawyers or doctors don't really do much testing in their related fields. Software engineers provide their skills to build a product, but then they must rigorously test and debug it. The medication strategies that doctors use to treat patients are surely not experimental. Nor are the rules a lawyer must follow in order to have a valid case. This means that software engineers are really kind of the researchers that precede the medication strategies, or the senate and congressman who pass laws before they are in use. I may be wrong here, but I don't think congressman are certified to do their job.

1.9) For each of the clauses in the ACM/IEEE Code of Ethics shown in Figure 1.3, suggest an appropriate example that illustrates that clause.

• Public - An example of this clause would be a software engineer pointing out flaws that would allow malicious users to infiltrate a camera system to monitor traffic.
• Client and employer - A software engineer, say for a health monitoring system, will not publish or take the patient data for personal use.
•  Product - The software engineer should not skip any testing or release an unstable version of the product.
• Judgment - If the engineer thinks they see a design flaw in the product, they should bring it up with the supervisors early instead of later in the development process.
• Management - Team leaders should not encourage engineers to cut corners and sacrifice performance or security in order to meet a deadline.
• Profession - If an engineer were to intently submit a program with a bug in it that caused significant repercussions, imagine the distrust it would create for other clients looking to hire a developer.
• Colleagues - If a colleague were to suggest a solution to a problem, or offer a piece of code, the software engineer should recognize them instead of taking credit for it.
• Self - As new hardware, technologies, and developing methods become available, the developer should try and learn and familiarize themselves with it. They should also keep any certifications they do have up to date.

1.10) To help counter terrorism, many countries are planning or have developed computer systems that track large numbers of their citizens and their actions. Clearly this has privacy implications. Discuss the ethics of working on the development of this type of system.

This scares me a lot. If you're on the development team, it's not a matter of just collecting statistical data and keeping the user specifics hidden like in, say, obesity in children. The whole point of a project like this would be to know exactly who is doing what kind of activities. I think there is a lot of room for error in a project like this. I feel it would lead to even more racial and economical profiling. What happens if they're wrong when they call someone a terrorist? That person goes to prison for nothing? Or perhaps they send them to a secret "correctional" facility? There has to be some other way of preventing terrorism that doesn't invade our privacy so much. After all, what good is a right to privacy if we don't exercise it? We almost may as well not have one.

Introduction

Hello world, and welcome to my blog! Well, let's be honest, at most maybe my classmates will view this... but maybe it will be of some help to you. This is going to be my blog for CSCI 362 - Software Engineering. Here I will post things related to the course from the reading, homework, and occasionally other random things I find interesting.

Let me introduce myself before starting the first homework, though. My name is Justin and I've been attending the college since 2009, and plan on graduating in the Spring of 2014. The five year plan isn't too uncommon, right? Like most of you, I am majoring in Computer Science, and am aiming for a Bachelor of Science with a lab science focus in physics. My interests include cars, computers, music, some games, and being a generally handy kind of guy. I like to take stuff apart, and build other stuff, and fix broken stuff. I also have hermit crabs. I think we should end it there.