Reading Blog - The Mythical Man-Month Ch 16 -17

Summary:
The chapters discuss the complexity of a program and how it can overcome programmers. The importance of working as a team comes into play in able to be able to control the project. If each programmer has their own role, the project will go smoothly.

Discussion:
I feel more examples are needed in these paragraphs to better drive home the idea. I do understand where they are coming from. Never having worked on a large program with that many people working on it, I can not relate.

Reading Blog - The Mythical Man-Month Ch 13 - 15

Summary:

Ch 13
Programs and projects are bound to have bugs. This requires a lot of testing and debugging. Top-down designs will make it easier to fix these issues and make it less time consuming.

Ch 14
Projects must be kept on schedule and have deliverables or goals reached on the road to completion. Estimating the time it will take to complete a project and planning ahead will make it go by a lot easier and finished faster.


Ch 15
Documentation is important especially when trying to explain to the user what it is the program does, how it is run, inputs, and troubleshooting. Programs should have a test program to verify it works correctly before the user gets to use it. It also helps in the future if changes need to be made.

Discussion:
These mostly talk about scheduling and documentation. It seems its important to estimate scheduling of release as well as document it. Also, the documentation of the program will also be needed for users to properly learn the program.

Extreme Programming Installed chapters 22 - 24

Summary:
Ch 22
We want to avoid bugs and defects when programming. We slow down the project and fail tests when these arise. It is very important to keep track of these to reference back and avoiding them in the future for better programming. This will speed up the project as a whole.

Ch 23
XP is meant to be simple with a great emphasis on communication and feedback. The progression of the project depends on these. Goals should also be kept realistic to the point where you can have deliverables weekly.

Ch 24
It is important to properly  deliver a project and estimate its completeness. Having these documented estimates can lead you to push back deadlines and release dates put on by managers. You do not want to release code that is not properly finished.

Discussion:
I am glad to be done with this book! I think I have implemented enough XP into our senior design project and I learned better like that than reading the book

Reading Blog - The Mythical Man-Month Ch 10 - 12

Summary:
Ch 10
Documentation is key for organization in a team project, budget documentation being one of the most important ones. It is important because it drives technical decisions and specifications. This will also aid in the communication process of the project.

Ch 11
the chapter tells us that most first releases are usually never fully correct. Because of this, programs should be designed to make it easier to change or add features later to avoid complete redesign. 

Ch 12
This chapter illustrates the differences between the target machines and vehicle machines. Target machines are those machines for which a program is designed to run on. The vehicle machine is the machine in which the program was built on. It is important top differentiate the two.

Discussion:
I enjoyed chapter 10 the most because it talked about budget and a bit of the business side of programming which I feel I have not seen a lot of. It helps understand real world situations.

Reading Blog - The Mythical Man-Month Ch 7 - 9

Summary:
Ch 7
This chapter deals with the importance of communication. It is key to accomplish the goals of the project. A workbook is an excellent way to keep the communication going by documenting everything needed to get the project finished. It should be distributed and kept up to date.

Ch 8
The chapter focuses more on the productivity of a team. Many times, planned schedules are not always correct because productivity may be slowed by unexpected problems that could not be accounted for. Meeting also play a role in the delayed time.

Ch 9
Space management is an important thing to take into consideration when dealing with projects. It can dictate the direction of your project and may need to take into account various trade offs.

Discussion:
I mostly enjoyed the chapter dealing with productivity. I have often found myself planning but they are always derailed with unexpected problems.

Reading Blog - The Mythical Man-Month Ch 4 -6

Summary:
Ch 4
Design and implementation are two very different things as discussed in the chapter. Architecture is a complete detailed specification of the UI. It must be drafted before implementation.

Ch 5
This chapter does more differentiation. It talks bout the early life of the design and avoiding adding on to it late into the process for second release.

Ch 6
The documentation of instructions describes what the user sees in a program. When the specifications are written up for this, it is important that they be precise and exact. Communication between builders and architects should be kept to avoid mis-communication of specifications and documentation.

Discussion:
This book is helping me understand different roles of programming and what each role entails. I am enjoying learning more about the different roles.

Reading Blog - The Inmates are Running the Asylum Ch 3 -5

Summary:
Ch 3
In most projects, the programmers steer what features will be on the system. Managers give them a list and programmers weed out what they feel will not be done in a realistic time fame. Users do not seem to care much for added features so long as they can accomplish their goals with the product. The goal and use of a product should be the most important thing over release date. It is no good to meet a release date with a unusable product.

Ch 4
This chapter discusses user friendliness. Today's technology, is expected to interact with users in an easy and intuitive way. Preferably the way they interact with other humans. The current software tries to tend to our needs but sometimes doesn't by constraining us into an enclosed state where it thinks it is doing what we need. We need more flexibility in today's software.

Ch 5
The design of a product is the most outstanding part of a project. We must deliver products that encase all the features and design the user wants. It is all about the end product over the release date.

Discussion:
The book is giving good information in my opinion. It is more release driven and gives us advice an topics I feel haven't been covered as much in other books. I look forward to reading more of this.

Reading Blog - The Mythical Man-Month Ch 1 -3

Summary:
Ch 1
The chapter discusses how programming can be enjoyable for some. For example many enjoy the prospect of creating something. Another reason is the joy of making things for people that they find useful. The whole chapter deals with the joys of programming.


Ch 2
The chapter talks about how it is sometime difficult to time a project as we may not know how long it would take. For the most part, programmers are optimists. It describes the title of the book, man-month. This is a unit of measurement for time taken to complete a task.

Ch 3
This chapter discusses that solving a large project doesn't mean throwing more team members on the project. This sometimes will make the process slower. Instead, teams should divide up tasks by having a main programmer, a co programmer, tester and many other jobs in order to avoid confusion and speed up the process.

Discussion:
I'm glad the tile of the book makes sense now. This sounds like another extreme programming book so far. I still don't have an opinion of the book. I will need to read further.

Reading Blog - The Inmates are Running the Asylum Ch 1 -2

Summary:
Ch 1
The book opens up by discussing problems many people face with using computers. The example of a digital that is hard to use due to new features being added is given. The standard functions are hidden under all the new extra added features. Sometimes programmers may make non intuitive programs for the users unintended. Programmers must understand their users and frame of references and step outside of theirs.

Ch 2
This chapter discusses cognitive friction which is intellect engaging in a complex system that changes as the rules change. There are different users that encounter this. The apologist which desire a challenge and the computer illiterate which want ways of doing things easily.

Discussion:
I found this book so far interesting. I agree with the different types of users who encounter cognitive friction. I could be a bit rage educing. I look forward to reading the book further to see other type of computer and system users.

Reading Blog - Extreme Programming Installed Ch19 - 21

Summary:
Ch 19
The chapter discusses unexpected changes that may arise when developing. This may make tasks take longer than expected. It is always important to adjust deadline and charts to make way for the unexpected changes. having leeway for adjustment is always good.

Ch 20
It is important to have stories get completed to the end. It is better to focus on a single story to completion opposed to having several almost completed stories. Also, you must check on members to see their progress on their stories.

Ch 21
When releasing, it is best to check up on your stories and see how much of them have been completed.  The most valuable stories should always be put at the top of the to do list. This will drive better releases.




Discussion:
The chapters are finally slowly starting to focus more on the release. I found these chapter more informative than previous ones.

Reading Blog - Design of Future Things Ch 6

Summary:
Mechanical devices, with their moving parts provide feedback to the user to describe their function and use. These help the user make up a mental model and indicate what the device does/is doing. It should be intuitive and natural.

Discussion:
Signal are important as described in the chapter. They help us by giving us an indicators to whats going on. I know i have relied on my indicators to see what a device is doing, or not doing.

Reading Blog - Design of Future Things Ch 5

Summary:
The chapter starts off with talk of Norman's smart home example. It talks about how the inhabitants of the house take about as much time getting use to the smart house as the house takes in learning the inhabitant's routines. The talk of artificial intelligence come up explaining how if not incorporated, the house may make bad calls and for example shout off lights in the house when users are in the, causing an undesired effect. It is all about the communication between the user and the system.

Discussion:
I like the points he talks about but I feel he needs to get more examples besides cars and houses. I like how he talks about the need for AI in order for systems such as these to work as intended.

Reading Blog - Extreme Programming Installed Ch 16 - 18

Summary:
Ch 16
The chapter talks about how at the end of an extreme programming project, you will end up with a very well designed project that is structured and tested thoroughly. Focus on documentation.

Ch 17
The chapter talks about when tackling a big project, it is always best to break up the problem into smaller manageable parts to solve individually. Estimate the time taken for each sub problem and the time worked on.

Ch 18
The chapter tells programmers to keep track of all their user stories. Graph the number of tests as well as the success rate. Also, track releases and plan out a schedule. 

Discussion:
It seems like it is very repetitive. I have already heard all this in the previous chapter. It is just saying it in a slightly different way. We are implementing this process though with our project.

Reading Blog - Design of Future Things Ch 5

Summary:
This chapter discusses the automation of things. The author starts of with a simple example of a coffee machine. He explains how this has changed the way humans prepare coffee. From this example, he jumps to a more elaborate smart house that is automated to fit you needs based on your physical actions, such as the example of going to bed. The idea of ethnography to do these automatons introduces with a Microsoft teams doing such a study to cater to a family to make a more intelligent living experience. The book then goes back to a simpler example of the refrigerator and introduces the idea of augmentation. This is the idea that a task is not automated but it is smart enough to help you through your task, thus augmenting its function to the user.

Discussion:
I thought it was interesting how they brought up the ethnography research. It makes more sense how ethnography can be applied to computer science and I can see what direction it is heading to. I feel this gave me a better picture of what to do and/or expect from an ethnography for computer science. 

Extreme Programming Installed Ch 13-14

Summary:
The first chapter talks about unit testing. This reiterates the idea of testing early and piece be piece. It is important to do so as the success of the project and customer satisfaction greatly depends on it. The second chapter goes a little bit deeper by emphasizing the writing of little tests first to pace yourself and see where you stand. This makes for more communicative and expressive code. The last chapter discusses releases and getting those changes out. Some of these changes could take some time because of conflicting edits and some are lost all together. IT is important to keep track of all changes and releases. This can be done by avoiding simultaneously editing items.

Dicussion:
I enjoyed in particular the last chapter because I felt the other two were just restating what has been said before about testing early and frequently.  This last chapter discussed how to avoid pitfalls one could run into when releasing code. It is helpful to have these in mind.

Reading Blog - Extreme Programming Installed Ch 10 - 12

Reference Info:
Extreme Programming Installed

Summary:
The first chapter just discusses the necessary task to be done after user stories. It is to sit down with team members and hear out and choose the simplest idea to implement. It is then followed by the concept of paired programming were two people work at one machine on the code. They then integrate it with the full project, test it, then release it. It also asks to keep the design of the code simple and avoid complex algorithms when possible. One could then also re factor in order to fix code and preserve the functions. It is also good to keep with the coding standards to avoid confusion on the code and to avoid overtime. It then finishes off focusing on paired programming where one is the driver while the other overlooks their shoulder and checks code. This produces better code and 2 programmers working together beats working separately.

Discussion:
I enjoyed going further into paired programming. That is one aspect of extreme programming I have not done. I would like to see how the process works first hand. I also enjoyed the statement about not working over 40 hours a week.

Reading Blog - Design of Future Things Ch 4

Reference Info:
Design of Future Things
Donald Norman

Summary:
The chapter talks about autonomy of technology and the question if we are enslaved by it. The chapter begins with some fictional article about a man being stuck in traffic for hours due to the autonomy of a car. It is used to illustrate a future where cars make most of the choices for you and asks the question if humans have become slaves to technology. The author once again uses the car of then future as an example to explain his thoughts. He explains the direction technology could go in, its current limits and trends. He uses cars acting as autonomous swarms in traffic to show where intelligent technology could lead to but also explain the limits when it comes to interacting with humans opposed to objects.

Discussion:
The future car example is getting quite old. It seems this entire book is about futuristic cars more than anything else. I don't know if I would believe such an article ever be published in the future regarding suborn futuristic cars.

Reading Blog - Extreme Programming Installed Ch 7 - 9

Chapter 7

Summary:
This chapter dealt with breaking down larger programs into smaller parts that can be released little by little. It takes the approach of making small releases until the entire system or program has been replaced. This leaves room for change when the customer decides to go in a different direction. The chapter gives several examples in which a legacy system can slowly but surely be replaces in small releases without disturbing the work flow.

Discussion:
I agree that it is best to release in small amounts. This helps avoid programing some large scale project that may need to be modified. If you release it all at the end, then the changes may need to be implemented and you would have to restructure the system potentially. Little by little gives you wiggle room for unexpected changes and to show progress.

Chapter 8
Summary:
This chapter explains to the customer their roles and responsibilities when it comes to releases. The customer has every right to know what can be done in what time and make release decisions based on this information. The customer also has the responsibility to be there for the progrmmers and explore and clear up any questions they may have. Based on the points per each story, customer can set relese dats or schedules imn order to getwhat they feel is more important.

Discussion:
This chapter gives a good explanation of the roles and responsibilities of a customer and it lets me know, as a programmer, what to expect and how some release decisions are made. It is good to know what goes through the customer's head and how they prioritize.

Chapter 9

Summary:
This chapter talks about the iteration meeting and actually delivering and the method that goes behind it. It starts by the customer presenting stories to which programmers assign points to. It begins with brainstorming followed by assigning and picking stories.

Discussion:
This chapter feels like it is the culmination of the last several chapters put together to show the method of extreme programming as a process with customers, managers, and programmers. It helps illustrate how it all comes together to work.

Reading Blog - Design of Future Things Ch 3

Chapter 3

Reference Info:

Summary:
Norman opens up this chapter by reasseting the notion that natural interaction can be rather annoying with todays technologies. He proposes that the future technologies will interact by using natural sounds opposed to machine bleeps and chimes. An example is boiling watter in a kettle. It naturally produces a steady sound until reaches boling point, where it unleashes a whistling sound. This sound is a natural sound in which the user becomes aware that the action is complete opposed to waiting for some electronic beep. Another example is comfort noise, such as the noise made from old telephones to let users know it was dialing. Now, telephones have become so advanced that circuits are noise free. Customers don't like that. They want to hear the noise to know that the action is beinf done or processed. The challenge is to get a sound that is informative yet not annoying. Visual markers are also a great help for users. It is another way to express and not annoy. Affordance comes into play as a form of communication. Visual and audible affordances are key in designs, else they are useless if the user doesnt know it is there or exists. Communication with intelligent devices was then introduced and the variations of strictness or atonomy it can have. The behavior of users can interact and communicate with the technology opposed to a one way conversation. Norman gives the example of the futuristic car than stiffens up so you become more alert and aware. Responsive automation is another example in which human computer symbioses alows both to work together to get a task done. A funner example is the segway, in which both interact to get around.

Discussion:
I would rather much prefer a mechanical sound opposed to a natural sound. It is more controlled and is ghauranyteed not to be confused with any natural occuring sound. Who knows how the design of future thngs will be, but I feel this method is treying to hard using technology to hide technology. It is trying to be integrated into our lives more and more while at the same time trying to seem natural.

Reading Blog - Design of Future Things Ch 2

Summary:
This chapter talks about smart machines and AI. IT speaks of the advancment of technology and how it becoming more and more intelligent. He illustrates different scenarios of where machines could have conversations with us using their intelligence. He then explains the differences between humans and machines and shows the vast gap between us. He explains how computers now have no way of being intelligent enough to hold conversations but makes us think of the future and all its possibilities. He says that by establisging a common ground between humans and computers, this may happen.

Discussion:
I think some of the ideas presented in this book are way out there, but I'm sure many of the new technologies we have today seemed far fetched at some point in the past. The design of future things seem to annoy us if they go the way Norman explains them. Who knows what the future will hold, but I am not going to take any lip from any machine.

Reading Blog - Extreme Programming Installed Ch 4 - 6

Extreme Programming Installed Ch 4 - 6


Summary:
The first chapter dealt with user stories. These stories are a conversations had by the programmers and the customers to see what specifications a system needs. The stories are given in 2 week programmer time and written down on cards. Stories should mainly come from the customer. Chapter 5 deals with testing. It is very important in XP to check test often in order to avoid waiting time later by testing in the end and forgetting the code. This way, bugs are caught much faster. Testing each story is a good way to test the overall program. Another way is to manually compute and check against the software. Chapter 6 discusses the importance of assigning points to each story to come up with solutions to the most important ones first. By doing so, we can choose which stories to do and give an approximation of time. Comparing is a good way to estimate and calling from previous stories implemented. It is good to start early on with intuitive time testing. This helps steer the project. It is best to experiment when dealing with stories never seen before. One will not get the perfect solution the first time around. Keeping records of all this is extremely important. It is the programmers who set the pace of the project.

Discussion:
All these tips seem very crucial and extremely helpful. It can really cut down on time of programming as well as debugging. I will be implementing these methods when it comes to my design project to keep on task and avoid falling behind.

Reading Blog: Design of Future Things Ch 1

Reference:
The Design of Future Things
Donald D. Norman


Summary:
This chapter introduces a problem with machines, their stubbornness. Norman explains that many machines designed to help, assist, or aid users in completing a task do it in such a way that it becomes unclear if the machine is aiding you or telling you what to do. An example of a navigation system is given. The user only has a say in the destination. The technology takes over from there and a user's options is follow the machine or not receive any help at all. There is the improvements of user's choosing a path to follow but how much authority does a child have when a parent gives them options. The user still has no say on how to get there, only how to be told to do something. This causes a problem because machines do not know what users desire, just what they are programmed for(given that they work correctly). The author hints that our lives, although surrounded by technology to control, are controlled ourselves. We are controlled by the need to control. Norman calls for a more symbiotic relation with technology where interaction becomes seamless and natural, but in some instances, just like a relation with a horse and a horseback rider, training is required. The overall vision of this chapter is to illustrate and call the need for natural interaction with machines where the relationship is mutual instead of one telling the other.

Discussion:
The chapter in the book made me reflect on the relationships I share with computers. I sometimes feel tied and constrained to them because I rely on them so much for everyday activities. I see it as a analogy to the same issues raised with televisions. Where users of the TV became so enthralled that it controlled their routine and schedule. I can see a similar path with computers and their users and as Norman explains, its not too late to change it.

Reading Blog: Extreme Programming Installed Ch 1 - 3

Reference Information:
Extreme Programming Installed
Ron Jeffries; Ann Anderson; Chet Hendrickson
Addison-Wesley Professional, October 16, 2000


Summary:
The reading begins by explaining the role of a customer in an XP project and how they decide what is of business value. They inform programmers of the specification with stories- verbal communication explaining how the system needs to work. They also manage the project in respect to the amount of work that can be done by a programmer in a given time. For programmers, the emphasis is on programming. The software is to be built in small releases. This calls for continuous design, rapid feedback, and maintenance of code. Also, sharing the code will be a necessity in XP. The managers role in the XP process is to make the work of the programmers easier by managing anything that may interfere, out of the way, in order for work to get done. Managers also set up meeting before release planning and serve as the middle man for the programmers during the meeting scheduling. Mainly, the manager makes sure everything goes smoothly and stays on track. The reading goes further by explaining the rights of each of the roles. The book explains the "circle of life" in XP by indicating the role of the customer and the role of the programmer in terms of defining and delivering value as well as estimating costs for the customer to choose values. The process is a learning experience for all and leads to success. Customers who are on site provide more value to the project but is understandable that sometimes they can always be there. When this happens the it is best to locate a representative for the company locally for the programming but try to get the real representative there for the meetings. Sending the programmers to the customer is also an excellent way to keep the project flowing. Lastly, if all else fails, make sure the customer can see the released code.

Discussion:
I enjoyed this reading, having done some small extreme programming in another class. It is a different way of programming but I do see the results. These chapters helped me get a better understanding of what I was doing when doing the sample XP. This cleared up some of the roles and responsibilities as well as presented new ones to each of the three groups (customers, programmers, and managers).I know this is only just the tip of the iceberg of XP and look forward to reading more. This will prove extremely helpful in managing our groups for this senior capstone design course.

Introduction Blog

Miguel A Cardenas

I'm still am not sure what I am doing after graduation, even though it is only a couple of months away. There are so many different fields in computer science that it is hard to decide. I enjoy anything having to deal with networks and security and AI as well. I feel those are the two major fields in computer science that peak my interest. I dont feel I am particularly strong in only one field of computer science but rather, I like getting my feet wet and knowing a little bit about different topics so that one the time comes for me to use that knowledge, learning it will not be too difficult since I have a foundation of the material already. I dont know if I have a favorite project over my college career (I do know there are some I hate) so I really can't pin point a single one. There have been many. My least favorite has definatly to be either the Microprocessor out of logic gates or anything using Haskell. I see mobile phones having one of the greatest evolutions over the past five years. THey have come such a long way and keep coming out with new features, functions, and apps. I see the mobile industry booming right now. As for programming style, the only thing that bugs me is sloppy code that's just all over the place. That is my biggest pet peeve.