Like the introduction says, the time value of money is a very important factor of the government, corporative and individual finance. Well, everything related to money is. And the concept of “time value of money” results from interest.
What is interest? We all learned. Its the cost of renting money. If you rent a house, your pay a given quantity of money plus maintaining the house in good state. When you rent money, at the end you return it -in good state- and pay a fee for using it. This type of interest is payed for each time the service is required, and its applied to the base cost each time. In more financial words, this is known as simple interest.
And there is also a compound interest. The logic its the same, except that the fee its not applied to the base cost each time the service is required, but its applied to the total cost of the last “iteration”. You borrow $100 with a 10%. First loop, you owe $110 (100+10), second loop $121 (110+11).
This can be represented by a formula: Pn = P0(1 + I)n
Where Pn = Value at n iterations. P0 = Initial value. I = Interest (Not percentile). n = iterations
Modifying this formula can be useful to predict future values, calculate the present value (given a future one at a specific iteration).
Other concepts such as annuity, perpetuity and intra-year compounding were specified in the on-line document.
First: Chapter 3
Well… Chapter three named “Survival concepts”talked all about the software processes. What are software processes, what aren’t and its benefits and costs compared to a project without a good software process. First, lets start with giving a basic definition of a process. A software process is a developed system that by creating a detailed and systematic plan to work, provides an assurance at the end of the project.
The book explains how there is a community that views this way of work as a very costly and inefficient system, when the truth is that having a process provides to the team a better way to find, report, and correct mistakes, in a way that might not change the budget or schedule in a meaningful way.
It is normal, that project that don’t implement a process find out that they are expending a lot of valuable time thrashing (Correcting defects, rather than implementing new stuff), but at this moment, any process implementation won’t be useful, and the project might be canceled.
That is why, at the long term, investing in processes is beneficial, even if at the beginning it might seem that the time dedicated to process designing is consuming valuable time. At the end, the team is working fast, productively and correcting errors immediately, with no cost at large.
Finally, the book also encourages the use of processes because studies have found that they increment the creativity and morale, because a programmer feels best if they feel productive.
This chapter also talked about two main parts of the development: Upstream (Creating the requirements, architecture and development) and downstream (Construction and testing). It focuses on how it is very important to contain the detection and correction of errors in the phase they are created. So that the cost to fix the defect don’t escalate as the project.
And chapter 4:
This chapter talks about two main concepts of the project skills. To plan the project so the project is visible an support the team, and to address the project’s risks by involving the users and maintaining the focus to a minimal feature set.
Lets talk about planning. Well… planning is the capacity of a project to accept small errors (planned) by getting rid of big and costly mistakes. Some ways of planning are: Creating a development plan, to map the course of the project; creating estimates, so the budget, staff and schedule are set adequately; a quality assurance, plan to make several tests and reviews; staging checkpoints and order of deliverables.One big concept of planning is the checkpoint review, where the manager request funds for a “Exploratory Phase” (Where at most 20% of the project is done), and after a meeting where the checkpoint review is shown, a second and final fund is requested. This meeting is made with the objective of showing to the owners prototypes, quality plans, development plans, user manual, style guides, goals and estimates.
Now lets talk about risk management, the second main concept of the chapter. The main risk in every project are: fail to make a plan, fail to follow the plan, and fail to change the plan according to the project. And the main methods to deal with these risks are:
- Control: To control the project (Not the people). Selecting a software cycle, making coding standards and making a plan.
- Visibility: To determine the true status of the project. Planning the checkpoint review, compare performance, hold milestones and revise estimates.
- Peopleware: To maintain the team on board with the development. Align the interests of the developer with the assigned work, show appreciation, provide a good atmosphere for work, and provide privacy to work.
- User involvement: To maintain a constant involvement of the final user, to provide a result they will love. Ask what they want, show what you have, ask if they like it.
- Product minimalism: To make a project as simple as possible. Avoid complications.
- Shipping: To have a clear focus on making the software until the shipping.
First I would like to mention that I also read the introduction (because I’m a cool guy). I liked it. I realized that maybe reading this book won’t be a sacrifice. It just introduces to the reader (Good thing, or it shouldn’t be called introduction) the idea that most of the projects developed right now, fail. Either because the team doesn’t know how to work effectively, or doesn’t know how to solve problems. This all depends if the project was planned and how well was executed.
Then I read chapter 1… Welcome!
Well, basically this chapter, again, gives a little introduction to what is a Software Project and the most general steps on surviving it. Like stating that the first step is to begin the project in a civilized way (I still don’t realize how a project can’t be civilized). The it continues talking about what is a failed project. It focuses on the idea that we are so used to failed projects that we really don’t consider that a project has failed unless it is a true “collapse”. A project can be considered a failure if it didn’t meet its budget, schedule and all of the quality requirements (Considering a margin of accepted error and tolerances). Still, the book assures that every project can be optimized to meet all the goals. Then, the chapter makes the comparison of the Maslow’s Pyramid of Needs to a project, and declares a Pyramid of Software Project Needs, where the base shows the basic things to do before starting the project, while starting, and further development. And finally, it explains that the end-user/owner of the project have the right to request information of the team (It has more rights), and the team has a number of responsibilities to meet.
And chapter 2…
This chapter hasn’t a lot of information. Its just a test you should do before starting every project (Or really early on the development). It has the following categories: Requirements, planning, project control, risk management, personnel and total. And then it provides a table where if you obtain at least 60 points, you have a “good” project. You should aim to more…