Computer projects are scary, you involve many people, the mere existence of your project, you reputation, the reputation of your team members and many other aspects are at risk. It is one big boulder you are carrying whenever the client in question comes to you and wants to know the status of the project and with this in mind I have come to the book “software project survival guide” by Steve McConnell not because I personally know the stress that is to work for a big company and have to accommodate to the constant demand of a manager but because I come from an administration background and find a big passion for the techniques that can be applied to the existence and solvability of a computer project. I look myself as someone with a solid administrative background and the mere existence of a book so called “survival guide” intrigues me. As a former international business mayor and current student in computer science its astonish to be part of the creative process that is making software can look at this projects with a strict administrative perspective. Not so long ago I was tough in the craftsmanship that is control, projection administration, organization and control of business but to no surprise I was well far away to what was this whole process, much of what I learned can be applied to a close niche of industries and software projects are a very unique and distinguished kind of industry.
After this brief introduction, I want to summaries some of the key points in “software project survival guide”. First, and most important in my opinion is “the aspect that software projects can survive or die due to the lack of knowledge in a software team to conduct a software project, or the resolve to conduct a project effectively.” (McConnell, 1998) So many projects are not properly taken to an end because the team lacks the administrative knowledge and communication skills to carry said project. As every other project the software must be elaborated with a proper plan or guidelines to keep the project at peace and so a first. The project manager must look for the team as well for the customer and basic understanding of rules from both sides must be set, the customer wants to know what happened with the money he invested and the programmers what to feel safe for them to not lose the job.
The project as a self-sustained entity has its own needs as we can see in the next figure, we have a correlation between the Maslow hierarchy and the project one, in both cases we must first take in account the very first link and climb to at less resolve the safety needs of this entity without safety the programmers can lose focus and feel threatened to be fired, we need the people to feel as they belong in the project, and to climb the ladder to achieve personal satisfaction if we can achieve this, our project can advance and we can then look at accomplishing every task within 10 percent of its schedule and budget targets.
As seen in figure 1.2 of “Software Project Survival Guide”.
The software process
As we mention earlier proper communication between the customer and programmers must be achieved before moving on to the coding stage, the process stage draws the guidelines in which our project should be lead. Processed must be taken in to consideration before codding for many reasons and one of this reasons is to increase the project’s flexibility and efficiency. Many fallacies can be assumed during the process stage, like how it adds more work when code is needed the hasty and close of mind can agree that the most important part of the project is the coding when even most important is to stick to processed that the team can adhere to. Proper software processes make the project nimbler in the following scenarios: Quality assurance, change control, uncontrolled revisions defect tracking system integration. “An investment made in process at the beginning of the project produces larger returns later in the project” (McConnell, 1998) I take from this to never take from granted the processes of a project because they can save you lots of time in a close future and in action can be very useful in the satisfaction of the software team, custom and the project itself.
As seen in figure 1.4 of “Software Project Survival Guide”.
One core concept I found very interesting in the software process is the upstream and downstream, the word upstream refers to the early part of the software process such as the requirements and architecture, the “downstream” refers to the later parts such as construction and system testing. It’s a net idea, we first go upward planning the design and later on we come back from the top to do the job interesting enough is that researchers have found that an error inserted into the project stream early tends to cost 50 to 200 times as much to correct late in the project as it does to correct close to the point where it was originally put into the stream. “successful project teams create their own opportunities to correct upstream problems by conduction through, careful reviews of requirements and architecture.” (McConnell, 1998)
With this I cover Chapters1 through 3 of McConnell’s book, I hope to continue soon with the analysis of the following Chapters.
McConnell, S. (1998). Software Project Survival Guide. Microsoft Press.