Keyvan Nayyeri

Two weeks ago I started a new thread as an analysis of the influence of hiring a good developer/architect on software projects and the reasons to support that hiring such employees can reduce the project costs, guarantee its success, and improve its quality in comparison with hiring lower level of developers.

Following that thread, I said I’m going to write a series of posts on this topic that cover the impact of such skillful people on each stage of the software development. Of course, it’s obvious that each stage of software development is important for its own and all these stages are related to each others, so weakness or strengths of one stage can directly have the same effect on other stages.

But I want to start with planning as one of the early stages in software development. Of course, there are many classifications of these steps but I want to get a regular classification and expand my discussion.

As someone who works in software industry, you would know that planning is one of the main stages of software development that typically includes the definition of the project, estimating its requirements, gathering a team of project members, defining a strategy, and estimating the roadmap and future requirements to implement the project.

Having this perspective, you can believe that how this stage can affect other stages significantly, and any mistake in this stage has a very bad result in the end, so all the investments and resources for a project may be lost if a good planning doesn’t support the whole project from infancy to the end.

Having a good analyzer, team leader, and architect with a good level of experience can guarantee the accuracy of your planning stage. Whatever you do, there is always the potential of failure for a software project in all stages, and it’s inevitable but the goal is to minimize this potential as much as possible. Here comes the power of knowledge and experience.

Suppose that you have hired some employees with different positions all working on the planning stage, and all with a mediocre level of knowledge and experience. The past history of software industry and software projects has proven that the quantity doesn’t matter here because it’s nothing but the level. The higher level of knowledge, the higher level of guarantee, even if you hire a dozen of those mediocre employees and only hire one adept worker.

Chapter 3 of software development bible, Code Complete, goes over the construction requirements as one of the early tasks to be done with special care in software development. This chapter cites existing researches and statistics that imply the role of knowledge and skill (that directly yield the attention and consideration) in the success of construction.

Going back and forth, you would know that there are many classified methods for software construction planning and estimation, so this stage can be done with a good quality if you know more about these scientific methods and strategies. Obviously, a knowledgeable person knows more about such stuff than a mediocre or amateur one. Honestly, it seems that many projects lack a scientific planning and rely solely on experience.

Taking another point of view, suppose that you’re going to invest $10X in a project which has a good potential for failure. Advisors tell you that you have two options to reduce this risk: hire someone with a normal level of skill for X dollars to analyze the project and advise you with all the weaknesses and risks, or hire someone with $2X to do the same job with higher level of skills and experience in many projects. Also suppose that you can earn $5X profit in the end. Now which one do you choose? Do you prefer to waste the whole $10X with a failure, or you try to earn less profit but earn it?

The role of the knowledge and skill is very similar to this story, and can be applied to software development and planning very well. The past history has proven the direct influence on this fact on the success and failure of software projects. If you interview the managers of many failed projects, they all will tell you that we had some mistakes in our planning and estimation.

Besides, there is another advantage of higher level of skills when planning for a software project. Usually planning and finding the requirements of a project ends up with an estimation of project costs that will be used in the business plans. I think we all have seen the guys who have failed to estimate many aspects of the project costs, and after a while whole the project could fall in troubles with these wrong estimations. At this point, business men may be compelled to neglect a part of the profit, or project managers may decide to lower the quality, and this if of course, a choice between bad and worse!

I didn’t want to step in statistics and evidence, but you can check out the third chapter of Code Complete for good resources that can support abovementioned assertions.