Response to Mythical Man Month (Ch 1-4):
Tonight's reading was quite interesting to say the least. It touched on many different aspects of the development life cycle of a programming project. For one, when a project is falling behind schedule, a natural reaction is to add more man-power in order to get it back on track. However, adding men to the project, in fact, has the opposite effect. Time for training the newcomers in the language, environment, and the current system design must be accounted for. Then there's the time it takes to devise a new delegation of the tasks involved in the project, so that the new people have something to do. And finally, you must include the time it takes to re-write the schedule with the new man-power included in the projection. So overall, the trade-off for adding more people to a project to get the job done faster is negative.
I like the idea that the author credited Harlan Mills for: making programming teams that resemble surgical teams. Several small groups of people working on the same project, or component of a project, with each member having a very specific role within the group that supports the effort of the group as a whole. Only one or two main programmers and designers, and several other supporting roles are needed. This idea of a surgical team reminded me of a pair-programming video that Dr. Starr showed our CSCI 230 class several semesters ago. It stated that using pair-programming increases productivity, quality of code, and the learning and enjoyment of the programmers involved, and although I cannot say I've had much experience with pair-programming, I am inclined to agree heavily.
Another part of this article was talking about how most programming projects are divided among developers, and each developer is also in charge of the design of his or her specific component. The author says that this is dangerous because the overall design of the system is no longer unified, and can have many parts that, while they may be well designed in themselves, are not designed to work with the other components as well. Therefore, again, the solution is to divide the design of the project from the implementation of the project. Hence where the term, code monkey, comes from. A small team of the "creative" and "elite" programmers get to have all the fun designing the system, then pass off the frustrating part of implementation to the "lesser" programmers. This idea in itself seems backwards to me as well. Why would you want the elite programmers to just design it, if they aren't going to the skills that classify them as "elite" to actually code it? Even though it may be well designed, the code would not be as efficient and reliable as it would had the elite programmers been the ones coding it in the first place. Perhaps I'm thinking about it in the wrong way. The author did say that this team architechture should only be used for large scale programming projects.
I enjoyed this read a lot and have definitely taken away from it, at the very least, that adding more people to a project that is running behind schedule is the wrong move. One cannot conquer the Mythical Man-Month because it is just that - mythical and imaginary.
Saturday, November 30, 2013
Homework #8 - 9/10 (Makeup)
Response to The Future of Programming:
I personally don't see this getting very far. They advertise programming from the browser and therefore being able to program on any device that can run a browser, or more specifically, Chrome. Sure, programming on Chromebooks might be useful, but there's no real difference to doing that compared to programming on any other conventional laptop. The other possibility that they say opens up is that you'd be able to program on your iPad! Are you kidding? I can't think of anything worse than trying to write a program on any sort of touchscreen device - unless - we're talking about drag and drop snippets of code to create a larger program, Which is what I think is the real future of programming. Before I talk about that, I want to finish with Cloud9, though. One of their other main selling points is that you can "zoom" in and out of your code to have a better idea of where you are within it. This is pretty cool, but it isn't novel by any means. It is probably something that will be a standard of any future IDE's that come out. Ian showed me the Sublime text editor, which I have fallen in love with this semester. It more or less does the same thing. Another selling point of Cloud9 would be to access your code anywhere online, but again, this isn't a very novel technology, nor does it really meet any new needs. Over the semester, we've learned how to use version control repository programs, such as Subversion, and Git. These programs, in my opinion, provide the same services that Cloud9 does and more. Not only can you save your code online, and re-download it from any other machine (although perhaps not as easily), but you can also revert to older versions of the code if you accidentally broke something, then committed it to the repository. In the end, Cloud9 to me is mainly just a kind of over-the-top showcase of what an IDE should be. It looks pretty, but doesn't provide any new functionality that previous IDEs haven't before.
Now, where I think the real future of programming is headed is graphical programming interfaces. Much like how developing websites has become nowadays compared to when the world wide web still had its baby teeth. Before, you had to know HTML and even then, you had to spend a lot of time and effort to make a website that looked more than pathetic. Nowadays, you click on a theme, and boom, it formats your entire page for you. Adding pictures and tables? No problem, just click here. Don't like it over there? No problem, just drag it over here. The most comparable thing that is in use today that I can envision the future of programming to be like, is developing apps for Android. The Android SDK implements drag-and-drop programming with certain elements, such as radio buttons, check-boxes, and lists. All you have to do is click which type you want to insert and its done, no writing Java code necessary. The other thing that leads me to believe that this is the future of programming is how much more abstracted our languages have gotten. If you think about the progression throughout the decades it makes a lot of sense. Machine language deals with literal machine hardware instructions, with C, you can directly access memory elements at a specified location, then you move to Python or other similar languages, where you can dynamically specify the type of a variable, it is no longer static. It won't be long before languages are abstracted further to be able to accept "ideas" of how the program should work as the input, and the environment or language will translate it further for you as necessary. It's only a small step from this to graphical programming, in my opinion.
I personally don't see this getting very far. They advertise programming from the browser and therefore being able to program on any device that can run a browser, or more specifically, Chrome. Sure, programming on Chromebooks might be useful, but there's no real difference to doing that compared to programming on any other conventional laptop. The other possibility that they say opens up is that you'd be able to program on your iPad! Are you kidding? I can't think of anything worse than trying to write a program on any sort of touchscreen device - unless - we're talking about drag and drop snippets of code to create a larger program, Which is what I think is the real future of programming. Before I talk about that, I want to finish with Cloud9, though. One of their other main selling points is that you can "zoom" in and out of your code to have a better idea of where you are within it. This is pretty cool, but it isn't novel by any means. It is probably something that will be a standard of any future IDE's that come out. Ian showed me the Sublime text editor, which I have fallen in love with this semester. It more or less does the same thing. Another selling point of Cloud9 would be to access your code anywhere online, but again, this isn't a very novel technology, nor does it really meet any new needs. Over the semester, we've learned how to use version control repository programs, such as Subversion, and Git. These programs, in my opinion, provide the same services that Cloud9 does and more. Not only can you save your code online, and re-download it from any other machine (although perhaps not as easily), but you can also revert to older versions of the code if you accidentally broke something, then committed it to the repository. In the end, Cloud9 to me is mainly just a kind of over-the-top showcase of what an IDE should be. It looks pretty, but doesn't provide any new functionality that previous IDEs haven't before.
Now, where I think the real future of programming is headed is graphical programming interfaces. Much like how developing websites has become nowadays compared to when the world wide web still had its baby teeth. Before, you had to know HTML and even then, you had to spend a lot of time and effort to make a website that looked more than pathetic. Nowadays, you click on a theme, and boom, it formats your entire page for you. Adding pictures and tables? No problem, just click here. Don't like it over there? No problem, just drag it over here. The most comparable thing that is in use today that I can envision the future of programming to be like, is developing apps for Android. The Android SDK implements drag-and-drop programming with certain elements, such as radio buttons, check-boxes, and lists. All you have to do is click which type you want to insert and its done, no writing Java code necessary. The other thing that leads me to believe that this is the future of programming is how much more abstracted our languages have gotten. If you think about the progression throughout the decades it makes a lot of sense. Machine language deals with literal machine hardware instructions, with C, you can directly access memory elements at a specified location, then you move to Python or other similar languages, where you can dynamically specify the type of a variable, it is no longer static. It won't be long before languages are abstracted further to be able to accept "ideas" of how the program should work as the input, and the environment or language will translate it further for you as necessary. It's only a small step from this to graphical programming, in my opinion.
Homework #7 - 9/5 (Makeup)
Response to readings:
I was already familiar with the first reading assigned for today, The Magical Number Seven. Dr. Manaris spoke of it often in the classes I took with him. I remember him saying, "If you have more than 7, plus or minus 2, lines of code in your method, you are probably doing it wrong! Split it up into multiple methods!" Since learning of it, I find myself thinking of it every now and then in everyday life. For example, if I'm to grocery shopping, I won't even try to remember the list of things to get in my head if it's around that magical 7 ± 2 number. Sometimes I wonder if computer science students from other schools learn of this principle. I don't spend that much time reading other people's code, but I wonder if I did, how much of it would I find that could be broken up as Dr. Manaris said?
The second reading for today was a study done on wireless tire pressure monitor systems (TPMS) used in passenger vehicles today. These little devices are very nifty in that they alert you of low tire pressure without you having to consistently check it yourself. They're really a neat little invention - the scary part of them that this paper reveals, is that so far, there has been little to no security measures taken to prevent 1 - the eavesdropping of signals and 2 - differentiate between fake and legitimate signal packets. The engine's computer failed in several respects in that there were several ways to tell that a packet was false. For one, you could send a packet to the ECU stating that the tire pressure is low, but at the same time, give a pressure value that is acceptable. This is a little surprising that software was developed to alert for low tire pressure, but it can't even tell what low vs normal tire pressure is! Another flaw in the ECU is that it doesn't validate authenticate messages. In other words, one could continuously bombard the ECU with signals with mixed messages until finally one gets through that would turn the light on. At first, finding out that this system wasn't very secure didn't seem like that big of a deal, but imagine that you are travelling long distance at night on a small two-lane interstate. If there are thieves following in a car behind you that have this signal replicating device, they could send a packet to your car causing the low tire pressure light to become illuminated. Now personally, if my tires were a little low on pressure, I'd probably just wait until I got to the next rest stop or gas station, but there are probably some people out there who would pull off the side of the road and bust out their little 12V air pump - game over! I can't imagine that this issue will go unchecked as the technology further develops. Eventually there will be some industry standard of security measures to be taken in terms of TPM systems.
The final reading for the night was planning for failure in the coming (or perhaps already here!) age of cloud computing. I really enjoyed this article, it read as if it were advice from an older brother or something. The author gives great advice on how to handle failure in general. When your service fails, what do you do? Does your browser display an http error, or does the application crash and freeze the browser? Do you have a backup page to display in the event of a failure? Some of this advice seemed like common since, but some of it not so much. For example, I don't know if I would have thought to use request buffering to reduce bottlenecks in the system, or to include little "retry" segments into the parts of my code that rely on retrieving data from a foreign source. In the case the source has a hiccup, it might not serve the data when first requested, but the retry statement would allow it to get the data the second time instead of passing an error to the client application. I think I'll save this article to my bookmarks as all-around good programming advice and practices to employ when I'm employed.
I was already familiar with the first reading assigned for today, The Magical Number Seven. Dr. Manaris spoke of it often in the classes I took with him. I remember him saying, "If you have more than 7, plus or minus 2, lines of code in your method, you are probably doing it wrong! Split it up into multiple methods!" Since learning of it, I find myself thinking of it every now and then in everyday life. For example, if I'm to grocery shopping, I won't even try to remember the list of things to get in my head if it's around that magical 7 ± 2 number. Sometimes I wonder if computer science students from other schools learn of this principle. I don't spend that much time reading other people's code, but I wonder if I did, how much of it would I find that could be broken up as Dr. Manaris said?
The second reading for today was a study done on wireless tire pressure monitor systems (TPMS) used in passenger vehicles today. These little devices are very nifty in that they alert you of low tire pressure without you having to consistently check it yourself. They're really a neat little invention - the scary part of them that this paper reveals, is that so far, there has been little to no security measures taken to prevent 1 - the eavesdropping of signals and 2 - differentiate between fake and legitimate signal packets. The engine's computer failed in several respects in that there were several ways to tell that a packet was false. For one, you could send a packet to the ECU stating that the tire pressure is low, but at the same time, give a pressure value that is acceptable. This is a little surprising that software was developed to alert for low tire pressure, but it can't even tell what low vs normal tire pressure is! Another flaw in the ECU is that it doesn't validate authenticate messages. In other words, one could continuously bombard the ECU with signals with mixed messages until finally one gets through that would turn the light on. At first, finding out that this system wasn't very secure didn't seem like that big of a deal, but imagine that you are travelling long distance at night on a small two-lane interstate. If there are thieves following in a car behind you that have this signal replicating device, they could send a packet to your car causing the low tire pressure light to become illuminated. Now personally, if my tires were a little low on pressure, I'd probably just wait until I got to the next rest stop or gas station, but there are probably some people out there who would pull off the side of the road and bust out their little 12V air pump - game over! I can't imagine that this issue will go unchecked as the technology further develops. Eventually there will be some industry standard of security measures to be taken in terms of TPM systems.
The final reading for the night was planning for failure in the coming (or perhaps already here!) age of cloud computing. I really enjoyed this article, it read as if it were advice from an older brother or something. The author gives great advice on how to handle failure in general. When your service fails, what do you do? Does your browser display an http error, or does the application crash and freeze the browser? Do you have a backup page to display in the event of a failure? Some of this advice seemed like common since, but some of it not so much. For example, I don't know if I would have thought to use request buffering to reduce bottlenecks in the system, or to include little "retry" segments into the parts of my code that rely on retrieving data from a foreign source. In the case the source has a hiccup, it might not serve the data when first requested, but the retry statement would allow it to get the data the second time instead of passing an error to the client application. I think I'll save this article to my bookmarks as all-around good programming advice and practices to employ when I'm employed.
Homework #4 - 8/29 (Makeup)
Problem set:
11.4)
*The homework states to do exercise 11.9, but there is no such problem listed in the back of the chapter.*
11.4)
The project manager chose to use the sandwich testing method. This method is good for testing the top and bottom layers of the system in parallel. Also, there is no need to write test drivers or test stubs, since the actual system components in the top and bottom layers are being tested. The weakness of sandwich testing is that there is no unit tests for the target layer, in this case, layer II. The only times the middle layer components are tested is during the integration tests with the other subsystems.
11.7) Apply the software engineering and testing terminology from this chapter to the following terms used in Feynman's article mentioned in the introduction:
- What is a "crack"?
- What is "crack initiation"?
- What is "high engine reliability"?
- What is a "design aim"?
- What is a "mission equivalent"?
- What does "10 percent of the original specification" mean?
- How is Feynman using the term "vericfication," when he says that "As deficiencies and design errors are noted they are corrected and verified with further testing"?
- A "crack" in the turbine blade of the shuttle turbopump is called a "failure" in testing terminology. It is a deviation of the observed behavior from the specified behavior.
- "Crack initiation" is an erroneous state - continued operation will lead to a failure.
- Reliability is a measure of how the observed behavior compares to the specified behavior. High reliability means that the system performs how it was specified to. When he says "high engine reliability", he is talking about the engine performing as it was specified, with very low failure rate.
- The "design aim" is the desired reliability that is specified during the design phase of development.
- Again, the "mission equivalent" is the specified reliability. They wanted the engine to operate without failure for an amount of time that was equal to 55 missions, or "mission equivalent" of 55. In this case, that turned out to be 27,000 seconds of operation.
- This is talking about the observed reliability. Instead of being able to operate for a total of 55 missions without failure, some parts had to be replaced every 3 or 4 missions, and others every 5 or 6. This is where 10% comes from - on average, every 4 missions (4/55 ≈ 7%, which is why he said "at most, 10%") the engine had to be repaired.
- Feynman is describing "fault detection", which is the process of identifying erroneous states and their underlying faults. When he says the errors are "corrected and verified" he means the faults have been repaired and the new expected behavior has been tested again and proven to be sufficient.
*The homework states to do exercise 11.9, but there is no such problem listed in the back of the chapter.*
Monday, October 21, 2013
Project Update 10/21/13
We haven't had a group chat in a while and the fact that I've missed some classes recently doesn't help either, but last time we spoke, I mentioned that I'd work on the script and webpage for the groups test results. It turns out, the only thing I had to write in the script (at least for a Windows command line script) was
start groupwebpage.html
This automatically starts whatever default browser is set on the clients computer, and loads the specified html file. Of course, the file has to be local for this to work, but you could do it with any website as well. E.g.
start http://www.google.com
This works the same way. I think it recognizes the http tag and automatically starts whatever program is associated with the protocol, or at least this is what I have read online. So after realizing that the script itself was very easy, I decided to go ahead and work on the webpage. I don't have much yet, but I'm going to be using css styling and hopefully some cool HTML 5 elements as well. We'll see what I can incorporate. I'm thinking something like, if all test cases are successful, display some silly .gif and play victory music in the background or something.
start groupwebpage.html
This automatically starts whatever default browser is set on the clients computer, and loads the specified html file. Of course, the file has to be local for this to work, but you could do it with any website as well. E.g.
start http://www.google.com
This works the same way. I think it recognizes the http tag and automatically starts whatever program is associated with the protocol, or at least this is what I have read online. So after realizing that the script itself was very easy, I decided to go ahead and work on the webpage. I don't have much yet, but I'm going to be using css styling and hopefully some cool HTML 5 elements as well. We'll see what I can incorporate. I'm thinking something like, if all test cases are successful, display some silly .gif and play victory music in the background or something.
Tuesday, October 8, 2013
Homework #15 - 10/8 - Deliverable 2 Reflections
Well here I am at 6:15am writing a post about my night of fun. It started out simple enough. I was just going to continue where I left off after building the project in Ubuntu. I was going to run it, see how SugarLabs looked, try and find the source code, etc. I decided, however, that running a VM inside of Windows 7 to run Ubuntu, then building a whole OS (SugarLabs) and running that inside of Ubuntu was just a little too much abstraction and my poor 3gb laptop was struggling to say the least. So Tan suggested that I just install Mint alongside Windows 7 and go from there, which I thought was a good idea. Well, hours later, after battling with my boot options trying to figure out why my computer refused to boot from any usb device, I had to break down and go to wal-mart and buy some blank discs. At about 3am I had finally finished burning an install disc and it worked like a charm. So I finish installing Mint and do all the things that I had done in Ubuntu to download Sugar and build it. Yay, success!
Running Sugar is interesting, the mouse pointer is gigantic and the buttons are massive as well, but it is surprisingly smooth and modern, for a kids OS. When you move the pointer to any of the screen corners, it brings up borders with options, just like a Mac does - pretty nifty. The navigation and interface of SugarLabs, though, could really use some more focus on design - it's not very intuitive, and things aren't given very meaningful names. For example, I could not find the list of Activities (SugarLabs version of programs, or apps) anywhere because they were ended up being in a directory called "Pippy" with a big snake icon. I guess that's kind of fun and interesting for kids, but man is it confusing.
Thank god for my teammates on this one, Tan was well ahead of us finding the code, etc, and Andrew was able to put together a very good looking deliverable, and although I wish I had been able to get some sleep, the night was not wasted as I learned a lot, got even more acclimated to linux and the command line, and was able to play around in our target project a little, and as a result, I feel a lot more prepared for our future endeavors.
Running Sugar is interesting, the mouse pointer is gigantic and the buttons are massive as well, but it is surprisingly smooth and modern, for a kids OS. When you move the pointer to any of the screen corners, it brings up borders with options, just like a Mac does - pretty nifty. The navigation and interface of SugarLabs, though, could really use some more focus on design - it's not very intuitive, and things aren't given very meaningful names. For example, I could not find the list of Activities (SugarLabs version of programs, or apps) anywhere because they were ended up being in a directory called "Pippy" with a big snake icon. I guess that's kind of fun and interesting for kids, but man is it confusing.
Thank god for my teammates on this one, Tan was well ahead of us finding the code, etc, and Andrew was able to put together a very good looking deliverable, and although I wish I had been able to get some sleep, the night was not wasted as I learned a lot, got even more acclimated to linux and the command line, and was able to play around in our target project a little, and as a result, I feel a lot more prepared for our future endeavors.
Thursday, October 3, 2013
Homework #14 - 10/3
The article we were to read for today was all about legacy systems and how to go about transferring from their use to a new system. Some of the reasons for transferring include being able to take advantage of new technologies that the legacy system cannot incorporate, high costs of maintaining the legacy system, and investing in the business. This whole article has much familiarity in my life. The reason being, one of my jobs is being a pizza driver, and the system we use to take orders is incredibly old. I'm not talking windows 95 old, I'm talking green-screen-monitor-and-tower-combined-with-only-keyboard-input old. This consistently blows me away, why are we stuck in the 80s? Don't ask me how they replace these dinosaurs, because they have broken before and we end up getting "new" ones, which are the exact same model. It's also strange, because this isn't some local small business either, this is an international chain corporation! That being said, the store I work for is franchise-owned, and so it may be possible that only the franchise has yet to update its technology, and the corporate stores already have. Either way, the franchise isn't that small either, so you'd think they could benefit from upgrading.
I've often thought about how I would program a new system to take orders for our store, and what kinds of things I would do differently and/or inherit from the old system. Upgrading the legacy system for me, seems like an easy enough task, but then when you read this article and actually imagine everything involved with the legacy system and all of its different components, it quickly becomes a daunting task and I can now understand why the pizza joint has yet to upgrade. I was trying to imagine how I would go about doing it if somehow they ended up hiring me to do the job, and I would definitely prefer to use the butterfly method discussed in the article rather than the chicken little method. All the extra complexity of writing components to make the new and legacy systems able to interact just doesn't seem worth it. I wonder, though, if there are other methods not discussed in this article as it was published in 1999. They speak toward the end of the paper about the research field of migrating legacy systems and I find myself curious if there has been any and what the results of it were.
I've often thought about how I would program a new system to take orders for our store, and what kinds of things I would do differently and/or inherit from the old system. Upgrading the legacy system for me, seems like an easy enough task, but then when you read this article and actually imagine everything involved with the legacy system and all of its different components, it quickly becomes a daunting task and I can now understand why the pizza joint has yet to upgrade. I was trying to imagine how I would go about doing it if somehow they ended up hiring me to do the job, and I would definitely prefer to use the butterfly method discussed in the article rather than the chicken little method. All the extra complexity of writing components to make the new and legacy systems able to interact just doesn't seem worth it. I wonder, though, if there are other methods not discussed in this article as it was published in 1999. They speak toward the end of the paper about the research field of migrating legacy systems and I find myself curious if there has been any and what the results of it were.
Subscribe to:
Posts (Atom)