--Originally published at Debugging My Mind
The blogging is back once again, this time it will focus on the progress of a book with a very interesting title. The Software Project Survival Guide by Steve McConnell, for now I’ll be focusing on the content in the first two chapters.
Chapter 1 – Getting welcomed to the survival
There’s a common thing I’ve been hearing throughout my software engineering studies and that’s that software development is in crisis, that referring to how so many projects that are started tend to either fail or be challenged (in other words exceding the expected cost and time) which is interesting but not that surprising due to the increasing complexity nature of today’s software needs.
One thing that does stand out is how on one side products are expected to be these perfect, enormous piece of software that can be used with ease and with no errors while projects are expected (hopefully) to just work, to succeed.
To begin with the book gives an analogy of the Marlow pyramid focused on the needs for project developping, how there’s some things we have to fulfill and be addressed before we can even touch anything else.
At first glance the first I thought is “well yeah, this seems like common sense” but it’s surprising how in practice there’s a lot of problems with the base of the pyramid, needs that HAVE to be fulfilled before we can focus on the tip, which adds the quality for the project to stand out, and creating that chance of failure.
Another important thing I agree with the book is how both the client and the team project need to have these set of “rights” or “rules” that they have to respect between each other, things as simple as providing requirements and meeting them that aren’t taken in mind given the proper importance and communication can be fleeting or missing, things like this as told by the Chaos theory are the biggest reason of project failure.
Chapter 2 – Putting yourself to the test
The book provides a simple yet hard to pass test for all project works going on or starting out, even dividing all of these questions in different sections of the project like planning, personnel and project control.
This is really useful and something to take at heart. There are a lot of situations already going on in college where teams decide to skip steps, to avoid documentation, avoid planning, ignore project control. Might it be to skip the “boring” part or to just get the work done for the grade, but it creates this really bad practice that goes out to the field once everyone graduates.
Ever since my engineering fundamentals class I’ve been amazed at how much failure exists for things that to me, start to seem like common sense. So many other engineering or professional areas already use planning as stepping stone for a surefire way to start off correctly, why don’t we?
