Design of Design - Chapter 20

Brooks opens this chapter by distinguishing two different groups: rationalists and empiricists. He states that rationalists believe that a complex object can be designed by thought alone, but empiricists believe the exact opposite. He states that rationalists would say that you should design software to be correct, and then prove that it's correct. Brooks ends this short chapter by answering a question he posed at the beginning of the chapter. He says that you can't design a complex object just by thinking hard about it, but it does help.

Design of Design - Chapter 19

Brooks opens this chapter talking about constraints. He tells us that constraints can be a good thing that challenge a designer's thinking, or they can be bad things that make a designer's life exceptionally difficult. Different types of constraints have to be identified, so Brooks lists four different types: real, obsolete, incorrectly perceived as real, and intentionally artificial. Two of these are quite obvious, but obsolete and incorrectly perceived constraints are less obvious. Brooks explains obsolete constraints by alluding to old size constraints that programmers had to adhere to in the past. He then explains incorrectly perceived constraints with several figures. Brooks then gives us an interesting idea. He says that specialized designs with tight constraints are easier than general-purpose designs with loose constraints.

Design of Design - Chapter 18

One of many problems with the model is that you're supposed to have a primary objective, but you might not always know what that is when you first start. He said that he began to realize at some point that his real use to his client wasn't for making goals and such, but actually for helping the client to determine what he actually wanted. Another problem with the model is the design tree. Similarly to setting the goals, we don't always know what the design tree looks like when we are first starting out. Furthermore, the design tree is far too simplistic. The nodes don't represent design decisions, but instead complete designs. Also, determining which path is the "best" to take while traversing the design tree is not feasible. Oftentimes, too many variables go into determining what is the best choice that you can't make a good decision by just looking at a design tree. The author also points out that, as the design process carries on, certain things may come to light that warrant a drastic design change.

Design of Design - Chapter 17

Brooks starts this chapter by helping us to see why setting too many requirements early on is a bad thing. If you have many people, all with their own agendas, trying to put their own lists of requirements into a design, the end result will often be bloated and not as functional as they should be. The author explains to us that a designer should start with a few high priority requirements, all with their own "weight," and then break them down into sub-requirements as the project progresses. And, if the focus on requirements starts to drift to other things and the creation of new requirements, usually the urgency of meeting a deadline and keeping to a schedule will help to combat these things. Another solution to "requirement creep" may be to appoint knowledgeable project managers from the very beginning of the project. Also, Brooks points out the necessity of written contracts. The author then closes the chapter by talking about the building designing model and how it separates the contract for design from the contract for construction.

Design of Design - Chapter 16

Brooks starts this chapter by posing a few questions about how to find a better design model, or if it even matters at all. He then introduces us to the Co-Evolution model.With this model, you incrementally evaluate you problems and your solutions. Then, Brooks introduces another alternative model called the Bazaar model. This model deals with open source and using members in the community to help with your design. However, he points out that the results might not be as polished or debugged. Finally, he gives us the last model of the chapter: Boehm's Spiral model. This model emphasizes prototyping and performing user tests very early in development.

Design of Design - Chapter 15

Brooks starts this chapter by describing outlandish design requirements that were thrust upon him by the Marine Corps. By telling us this story, he is helping us to see why setting too many requirements early on is a bad thing. If you have many people, all with their own agendas, trying to put their own lists of requirements into a design, the end result will often be bloated and not as functional as they should be. The author explains to us that a designer should start with a few high priority requirements, all with their own "weight," and then break them down into sub-requirements as the project progresses. And, if the focus on requirements starts to drift to other things and the creation of new requirements, usually the urgency of meeting a deadline and keeping to a schedule will help to combat these things. Another solution to "requirement creep" may be to appoint knowledgeable project managers from the very beginning of the project. Also, Brooks points out the necessity of written contracts. The author then closes the chapter by talking about the building designing model and how it separates the contract for design from the contract for construction.

Design of Design - Chapter 14

This chapter begins with "how engineers think of design." The designer can make a design tree. The design tree is the illustration of the different possible paths created by increasingly narrowing decisions about your design. The author points out that this tree can be operated on in the same way that any other tree data structure can be. The step-by-step design process model was developed in the community of German mechanical engineers. It has since been built upon by people such as Winston Royce, who created the seven-step Waterfall Model. The chapter closes with a paragraph explaining some of the benefits of using the Rational Model.

Design of Design - Chapter 13

Brooks opens this chapter by distinguishing two different groups: rationalists and empiricists. He states that rationalists believe that a complex object can be designed by thought alone, but empiricists believe the exact opposite. He states that rationalists would say that you should design software to be correct, and then prove that it's correct. Brooks ends this short chapter by answering a question he posed at the beginning of the chapter. He says that you can't design a complex object just by thinking hard about it, but it does help.

Design of Design - Chapter 12

Brooks begins this chapter by telling us that wise designers begin designing by writing down everything they know and assume about the user, his or her purposes, and his or her methods of use. He says that it is important to write out an explicit list of assumptions when designing in a team; otherwise, all team members might incorrectly believe they all have the same assumptions. However, the author says that the designers will often not know enough to make a complete model of the user, but it forces the designers to ask questions about the user that they might not have asked otherwise. Brooks says that for any questions that can't be answered about the user with a reasonable about of searching, it's perfectly fine to guess. And with that, he gives us the tagline for the chapter: "Better wrong than vague." By this he means that it is better to be wrong about your user than to simply not have enough information about your user.

Design of Design - Chapter 11

Brooks opens this chapter talking about constraints. He tells us that constraints can be a good thing that challenge a designer's thinking, or they can be bad things that make a designer's life exceptionally difficult. Different types of constraints have to be identified, so Brooks lists four different types: real, obsolete, incorrectly perceived as real, and intentionally artificial. Two of these are quite obvious, but obsolete and incorrectly perceived constraints are less obvious. Brooks explains obsolete constraints by alluding to old size constraints that programmers had to adhere to in the past. He then explains incorrectly perceived constraints with several figures. Brooks then gives us an interesting idea. He says that specialized designs with tight constraints are easier than general-purpose designs with loose constraints.

Design of Design - Chapter 10

This chapter begins by introducing a new term, limiting resource, being any resource that is "scarce" and must be budgeted. Brooks points out that there are many other limiting resources besides money, and the limiting resource is actually not usually money. He says that even when it is money, there are several different ways money can be a limiting resource. And, even when money is the limiting resource, designers will often find another resource that is directly tied to cost and make that the "surrogate" limiting resource. The author also points out that limiting resources are not fixed; they can change. Then, after all this, Brooks closes the chapter by telling us what we should do once we find the limiting resource: identify explicitly, track publicly, and control firmly.

Design of Design - Chapter 9

Brooks begins this chapter by telling us that wise designers begin designing by writing down everything they know and assume about the user, his or her purposes, and his or her methods of use. He says that it is important to write out an explicit list of assumptions when designing in a team; otherwise, all team members might incorrectly believe they all have the same assumptions. However, the author says that the designers will often not know enough to make a complete model of the user, but it forces the designers to ask questions about the user that they might not have asked otherwise. Brooks says that for any questions that can't be answered about the user with a reasonable about of searching, it's perfectly fine to guess. And with that, he gives us the tagline for the chapter: "Better wrong than vague." By this he means that it is better to be wrong about your user than to simply not have enough information about your user.

Design of Design - Chapter 8

Brooks opens this chapter by distinguishing two different groups: rationalists and empiricists. He states that rationalists believe that a complex object can be designed by thought alone, but empiricists believe the exact opposite. He states that rationalists would say that you should design software to be correct, and then prove that it's correct. Brooks ends this short chapter by answering a question he posed at the beginning of the chapter. He says that you can't design a complex object just by thinking hard about it, but it does help.

Conflict of Interests

In this article http://www.guardian.co.uk/business/2012/sep/21/drugs-industry-scandal-ben-goldacre, there is a conflict of interests between the drug manufacturers and the market for the drugs. The article suggests that the manufacturers know everything about their drugs, good and bad, but the doctors and patients do not. This is obviously a conflict of interests because the manufacturers want money no matter what they have to do, and the patients want a drug that works exactly as advertised. The problem here is that the drug manufacturers test their own drugs, so they can say whatever they want about their drugs to make them look more appealing. However, this causes certain important things to be withheld from the patients (such as bad side effects), or just causes a generally misleading advertisement of the drug.

Design of Design - Chapter 7

The author begins this chapter by asking a question: Why do design teams now telecollaborate? He give several reasons for this: skill specialization, different location preferences, time flexibility, low cost, and politics. For the last one, politics, Brooks explains that large international companies often must split up jobs between companies, so this makes telecollaboration practically essential. Brooks then tells us of when he was designing the IBM system/360. He telecollaborated during this time, and though he said it was a lot of work, the effort was highly successful. Brooks tells us two things that will help make telecollaboration work: meeting face-to-face, and designing clean interfaces for remotely designed components. Finally, the author gives a few different means of telecollaboration: simple documents, telephone, videoconferencing, or a combination of the three.

Design of Design - Chapter 6

The author begins this chapter by stating that there are 2 major changes that have happened to design in the last century. These changes are that design is now a team effort, and that designers collaborate with telecommunications. He ponders this as he gives a few examples from designers of past centuries. Many great designs have been done by one mind, or two minds as the exception. He likens the two-mind design to marriage.
Brooks gives two reasons for this shift to multiple designers. First is the increase in technological sophistication. With more sophistication, it becomes more and more difficult for one person to manage all of the design's complexities. The second reason would be to get the designed product out to market faster. A faster product to market means more profit while everyone else catches up.
The author then discusses the costs of collaboration. He says that there is a cost for work partitioning, learning and teaching, communication, and change control. He points out that change control is a substantial cost.
Brooks states that the most important concept in design is integrity, and he again alludes to designs of the past coming from one or two minds. So, he poses the question "How do you get conceptual integrity in a team design?" He says that academic writers suggest that the way to achieve this integrity is by interdisciplinary negotiations. Brooks says that this implies that the team be composed of peers that negotiate until everyone is satisfied. But he quickly shoots this down as the cause of bloated products. He instead suggests that design projects appoint a single system architect to oversee the vision of the design. He also suggests a single user interface designer.

Design of Design - Chapter 5

Brooks starts this chapter by posing a few questions about how to find a better design model, or if it even matters at all. He then introduces us to the Co-Evolution model.With this model, you incrementally evaluate you problems and your solutions. Then, Brooks introduces another alternative model called the Bazaar model. This model deals with open source and using members in the community to help with your design. However, he points out that the results might not be as polished or debugged. Finally, he gives us the last model of the chapter: Boehm's Spiral model. This model emphasizes prototyping and performing user tests very early in development.

Design of Design - Chapter 4

Brooks starts this chapter by describing outlandish design requirements that were thrust upon him by the Marine Corps. By telling us this story, he is helping us to see why setting too many requirements early on is a bad thing. If you have many people, all with their own agendas, trying to put their own lists of requirements into a design, the end result will often be bloated and not as functional as they should be. The author explains to us that a designer should start with a few high priority requirements, all with their own "weight," and then break them down into sub-requirements as the project progresses. And, if the focus on requirements starts to drift to other things and the creation of new requirements, usually the urgency of meeting a deadline and keeping to a schedule will help to combat these things. Another solution to "requirement creep" may be to appoint knowledgeable project managers from the very beginning of the project. Also, Brooks points out the necessity of written contracts. The author then closes the chapter by talking about the building designing model and how it separates the contract for design from the contract for construction.

Design of Design - Chapter 3

Chapter 3 begins with the author stating that the Rational Model is not perfect. He says that it's more of an ideal than something that is true to life. He says that one of many problems with the model is that you're supposed to have a primary objective, but you might not always know what that is when you first start. He said that he began to realize at some point that his real use to his client wasn't for making goals and such, but actually for helping the client to determine what he actually wanted. Another problem with the model is the design tree. Similarly to setting the goals, we don't always know what the design tree looks like when we are first starting out. Furthermore, the design tree is far too simplistic. The nodes don't represent design decisions, but instead complete designs. Also, determining which path is the "best" to take while traversing the design tree is not feasible. Oftentimes, too many variables go into determining what is the best choice that you can't make a good decision by just looking at a design tree. The author also points out that, as the design process carries on, certain things may come to light that warrant a drastic design change. To add to this, the constraints of the project may be fluid as well, causing any number of changes to need to be made. The author suggests a potential solution: working to eliminate the constraints. The author also provides critiques to this model from others. One potentially valid critique is that this model doesn't work at all because experienced designers just don't work well using it. However, even though this model has what appears to be a cornucopia of flaws, it's still somehow stuck around. The author concludes with the statement that not all designers are in agreement about how to design or which model to use.

Design of Design - Chapter 2

Chapter 2 begins with an introduction to what the author calls The Rational Model. He describes this as "how engineers think of design." The Rational Model has several components: a primary goal, secondary goals, optimization, constraints, and resource allocation. Using these components, the designer can make a design tree. The design tree is the illustration of the different possible paths created by increasingly narrowing decisions about your design. The author points out that this tree can be operated on in the same way that any other tree data structure can be. The step-by-step design process model was developed in the community of German mechanical engineers. It has since been built upon by people such as Winston Royce, who created the seven-step Waterfall Model. The chapter closes with a paragraph explaining some of the benefits of using the Rational Model.

Design of Design - Chapter 1

Chapter one opens with quotes from Sir Francis Bacon and Herbert Simon suggesting that two designers in completely different fields can discuss the design of each other's work without particular knowledge of the field it pertains to. The chapter explains that this is a result of the fundamentals of design. Since design is essentially just a plan at its roots, that plan can be constructively criticized by another designer without taking technical details into account. As far as software goes, the author divides the creative process into two tasks: essential and incidental, with essence being the design and incident being implementation. Then, the Design Concept was introduced. The book explains that, if you're designing something, you may not realize that you are actually designing, but the fundamentals of design are all still present whether you know it or not. However, the book notes that recognizing the Design Concept has benefits. By focusing on the Design Concept, it will aid your team in the design process. The chapter tells us that focusing on designs has been around for quite a while, but thinking about the process of design itself is something that is relatively new. The chapter ends by clarifying that this book will be all about original system design rather than redesign or artistic design.

UPenn Projects

• ECar
• 75 - It seems like this kind of thing has been done before and is a little exhausted, and it didn't even look very polished. But, it does function as intended.
• Dance with your Hands!
• 75 - I like that it's using new technology, and it's a good idea, but the implementation looks a little clunky.
• Pokemon Stadium 350
• 90 - Reusing the old technology is a nice touch. The idea is great and could be made into a more polished toy that I could envision making a lot of money, especially if it carried the Pokemon brand.
• Rhex Box
• 80 - This looks surprisingly well constructed, and it's using new technology, but I don't know what you could really use it for.
• Automatic Chess Player
• 95 - I think this could have been implemented with an Arduino or a RaspberryPi instead which would make it more practical. Other than that, this is really cool!
• Sign Master 9000
• 90 - Seems like it could be useful, although it could get frustrating to use.
• Kinecto-Vision
• 95 - With more development, this could be an essential tool for anyone who is vision impaired. It uses inexpensive technology, and it's simple to use. 
• FPS 360
• 85 - It seems to be implemented fairly well. The only downside is that I'd imagine that it could be hazardous to be moving around without looking where you're going.
• Unviersal Glove Controller
• 80 - There seemed to be too much delay and problems with the sensitivity for it to be usable, but with more polish, it could be great.
• Greenengineering (2010-11 Senior Design)
• 70 - I'm sure there was a lot going on in the back-end, but the GUI was lacking too much polish.
• R.A.V.E.N (2010-11 Senior Design)
• 50 - It's a cool idea, but it was all talk. They never demonstrated it.
• High Speed Water Purification System for Developing Countries
• 95 - Seems like a genius idea and implementation, and it really seems like they know what they're doing, but they didn't demonstrate any before and after water purifications.
• Street Solutions
• 95 - I like that this is a mobile app. The website looks fairly polished. This is a great idea.
• Energy Performance Rating of Penn Buildings
• 95 - Great idea, and the GUI was nicely done. Deals with important issues.
• AccuEnergy
• 80 - Good idea and lots of data, but no demonstration.
• Electronic Pitch Trainer
• 100 - Incredibly well-done. Very nice idea with potential to make money, and I can see many other applications for this.
• Stadium Express
• 90 - Good idea, and it seems to work great. Just needs more polish.
• AutoPlug
• 95 - Great idea that scratches the surface of an even greater, bigger idea.
• Urban Energy Consumers as Solar Energy Producers
• 75 - Lots of good information, but no demonstration.
• Economic Network Model
• 80 - There was good information, but they didn't show the GUI that they mentioned.
• Sustainable Rainforest Solutions
• 90 - Lots of research done. Looks promising. Deals with real issues. Nice GUI.
• Spam Detection on Wikipedia
• 80 - Deals with a real problem. Seems well thought out, but there's no demonstration.
• Winds Up!
• 60 - Lots of research, and the GUI was a nice touch, but the GUI didn't look very polished, and it didn't look like many design aspects were demonstrated.
• Detection of Pneumonia by Computer-Aided Auscultation
• 100 - Very well researched. Tons of good information. Great idea that tried to solve a real problem. Incredibly well-polished.
• Intelligent Information Systems for Technical Trading Analysis
• 80 - Useful applications in the real world. Could use more polish, and could be a little more user-friendly.

Design

What is design? Of course, you could simply define it as the Merriam-Webster dictionary defines it: "a particular purpose held in view by an individual or group."
But design is more than that. Design is an idea. It's imagination in the process of becoming reality. It's instructions to create something physical that didn't exist prior to design. It's a determination of a need or a desire and the subsequent challenges overcome to meet those needs and desires. It's the realization of an implementation.

My Major

Computer science has been something dear to my heart since before I even really knew what it was. So, when it came time to choose something to do for the rest of my life, the obvious choice for me was computer science. I started off in middle school programming in some simple scripting languages, and I quickly moved to BASIC and its variants. I continued to hone my skills on my own all the way through high school, but I knew that a college education was going to give me the tools that I couldn't get elsewhere.
After I graduate from UTK, I plan to go to graduate school to get my master's degree; although, I'm not sure where I will go yet.
As far as employment goes, ideally, I'd like to work for Google. But, wherever I work, I'd like to work with some sort of GUI design and implementation. I also have hopes to start my own company some day, but that may be a few more years down the road.
On average, software engineers have many opportunities on the horizon with a bachelor's degree, and potentially even more with a master's. According to research done by the University of Illinois in Chicago, 27% of emerging STEM jobs will be in the field of software engineering, and in 2010, software engineer was ranked the #2 job in America. And the salaries for computing jobs reflect the demand for employees. In 2010, the average salary offered to employees that held a bachelor's degree was $47,673, but computer science majors' offers were $60,426. That's with only a bachelor's degree.
So, as you can see, not only do I enjoying computer science, but I also have a very good chance of building a promising career on it.