--Originally published at Debugging My Mind
Today we walk into the next 2 chapters of the Software Survival Guide book, I’ll give a small summary and my thoughts on each of them.
Chapter 3 – The concepts
As the book mentions, even at scholar work level most teams want to avoid the processes and beginning planning that needs to go into a project, due to this, most of those experiences end up being stressful, full of rushing and emergency working, staying up late, stretching schedules and a whole lot of mess in short terms, yet after all of that experience a lot of people just laugh or talk about it as how interesting and strong they are to survive those or even how a new subject will require one of those experiences.
To me, it feels as something inherent, even obvious that something like planning and correct processes at the beginning of the project allow you to avoid incredibly big changes and loss of time, even from my own experience, projects that I haven’t invested careful proper planning end up having what would be a small mistake in the past to be corrected into a huge problem that requires quite some time for fixing.
It is true, having a process is the clear way to fix all of these problems, to make the whole journey easy, but the hardest part is to convince your team and coworkers to go along with this, to invest time into the processes, it always seems like the most boring thing, they just want to get right on the “interesting” part, and the question remains, how do you convince them? telling them of the consequences doesn’t seem to be enough a lot of times until it’s actually happening, the great focus is not only on learning effective processes but also an effective way of relaying them to everyone else and convince them of their use.
Chapter 4 – The skills
We begin with the main topic of the last chapter, planning, in this case the book adresses what I was talking about, trying to convince your team to take planning into account and invest the necessary time into it, talking about hours, hard data, time. It mentions how big the increase in time the projects mistakes upstream cost when you’re downstream, things that can be fixed for so much less if caught early on due to planning.
Not only that but we’re provided with several different examples of planning for software developping, including: the development plan, the project estimates, the revised estimates, a quality assurance plan, a staged delivery plan, and a few others.
One of the examples I have the most experience with is requirements development, identifying the main problem to solve or make a solution for and specify each and one of the many requirementes that it has to achieve by the end of development, be it functional, non functional, interface or business model wise, there are many things that need to be specified. What the system can and cannot do, where it will be supported and any rules from the client themselves that it has to follow for their business. This is something I don’t see a lot of people around me applying yet it’s so important and in my opinion, not difficult to do right.
Another skill talked about is two-phase funding approach. Where you ask for the funding needed for the exploratory phase so you can concretely find out how many resources you’re going to actually need for the project itself, knowing exactly what will be needed and what the client wants.
The planning checkpoint review is a great tool to find out how viable and what changes are required to the project to make it possible, better to have a good control of what needs to be done and how do-able it actually is before asking for funds for impossible tasks, unrealistic deadlines and complex functionality.
An important thing to note, also mentioned after the planning checkpoint is the involvement of the team members, you want them to have a clear vision of what the plan is, make them feel appreciated and actually part of the project, align their interests with the work assignments, in the end the projects isn’t being done only by the managers, but the whole developping team itself, there needs to be a good inclusion and integration from all parties to make all these processes succeed.
After all that, we touch possibly one of the most ignored and most important part in software developping, user involvement. The Chaos theory mentions how lack of user involvement attributes to one of the highest reasons of project failure, if the client doesn’t know what’s going on, isn’t invested and aligned with the project itself, what chances are that it will be deemed sucessful or that it will meet his expectations, when the users and clients themselves are fully involved and constantly being asked for feedback, the project is something deeply connected with them, something they are fully involved and interested in, and more importantly something they perfectly know the state of and have realistic and proper expectations for.
Far too many times teams want to chase for the next biggest idea or the best software ever made, which on one side thinking that big isn’t bad by itself, but keeping the core idea at front at all times and considering its importance is the deal breaker, clients want a software they can use, having differentiating software is very good, but if you can’t even provide the core solution without the polishing, then it’s basically no solution at all. It’s best to keep as minimalistic as possible early on and then add any polishing required should the time be available. It’s not about rushing a product, but focusing on what’s truly important.
