Chapter four is about deciding on things which is really important in having a successful program. First, this chapter also converse about knowing first the vision or the purpose of the software that you will implement because sometimes your program contradicts the vision. You need to know this to have a good direction in the group.
Second, this chapter tackles about knowing who your market is. We must know their age, likes, dislikes, and etc for us to adjust with what we will program. I have learned that you can’t please everyone. So, as a programmer, we must not care with those people who really don’t like our software but the people who evangelize our products. You can’t change the opinions of other people in you. We must focus on them because they will be the one who will use it.
Third, this chapter discusses about prioritizing problems which is present. This author suggests not to focus on the problems that will come in the future. According to getting real, the example of this is having 100,000 users in the future, this will eventually create problem because if this things happen, you will have slow connection to the server. I believed that in this situation, you need first to know who your users are at present.Instead of this, try to know if you have hidden problems at present.
Fourth, this chapter want to confer that we as a programmer needs to decide on increasing the features of the software or not. We need to know, if it is really necessary then do the action. It is said that you need to limit your features, but what if it really needs in the business procedure. Some said that it is arrogant to limit the features of the system. These two statements is very ironic, but what getting real suggests for the programmers is to judge it and must be supported with the vision of the company. Also, before adding features, you need to have it approve by your client because they will be the one to use it.
Fifth, this chapter advice us not to measure our users in the future. We must first measure the people who really use our application, but don’t make a prediction of what if it would be successful and many users would use it. Actually that is really a problem. I think there is a maintenance phase in the Rational Unified Procedure because the implementation is not really the end of the process. Programmers need to maintain an application because change is not constant in the real world. Don’t make a prediction because we are not sure if it will really happen
Last, don’t focus much on details. I agree on this statement because we’re not yet professionals who is used in programming. Sometimes, even them, they made mistakes. For example, it is stated in this chapter that the details is about thinking to have four liner codes from a seven liner code. I think the important thing is to let it run because seven liner codes are not that bad.
