Process is the one of the most hated word among hard-core developers. Hard-core developers hate anything besides writing code and they think that software engineering is all about coding. I wish it was so but it isn’t.
Company bosses often don’t bother about technology. They bother about money. Most of the projects fail not because the developers could not code well enough but purely because the project management was not good enough.
Processes help here. They put discipline in all the stake holders of the project and ensure that the learning from mistakes is well absorbed in the organization. The disadvantages are evident. It frustrates the smart guys on the project. It slows down everything. On the brighter side if the processes are well designed it helps the company on a longer run to understand its own capabilities and improve on it in a proactive manner.
A small-sized company with say 2 years experience with good processes can answer following questions more effectively than before:
1. How much time per developer do we take per function point per developer per given programming language?
2. What is over average defect rate for a given programming language?
3. What is the average schedule skew we face for a given size of the project?
4. Which projects are more likely to fail and which aren’t ?
These are just some sample questions I picked up very randomly. They are only illustrative not exhaustive. What they indicate is that after a few years of experience with some good processes, company top brass has matrices that can help them make critical decisions. Very fine-grained processes with effective information management systems they might arrive at following conclusions.
1. One senior software developer is equivalent to 1.3 junior software developer in productivity.
2. Having more senior people on a project in its initial phase is more helpful than having them later.
3. Our effort estimates go wrong at the most by 25%.
4. Month of June is the most unproductive month because several people resign and get promoted (due to appraisals). It takes 2 more months for them to reach average productivity level of the company.
And so on.
Pay very close attentions to these statements. These statements are very important for a company and yet they are very important from an individuals perspective as well isn’t it ?
If I am a developer who has experience of working for say 3 years I should be able to answer following questions with very high accuracy.
1. If I am asked to do efforts estimation for a given task, what is the upper bound of % by which I will miss the real efforts ?
2. How many defects do I leak per thousand lines of code I write?
3. If I am given 10 tasks, on how many tasks I am likely to miss the commitments ?
4. If there is a difference between time I asked to complete a task and the time I was given, can I accurately estimate the effect it will have on the quality of code I deliver?
A software developer who can answer these questions with a good degree of statistical accuracy is certainly a “akhon ka taraa” of his project manager. Such a developer is less likely to fail and when he will fail he is likely to anticipate that failure.
How exactly a developer can answer these questions? It is by keeping a record of every work he does. It’s not enough to keep a record but the developer needs to plan his work, separately but in line with the project plan.
Plan -> Record -> Compare -> Improve -> Plan ->Record … and so on.
This problem is not a new in Software Engineering. Watts Humphrey the famous man, who was also in-charge of SEI (Software Engineering Institute) , responsible for developing standards for CMM levels had also written about PSP (Personal Software Processes, service marks of Carnegie Mellon University).
I am not sure why PSP is not so popular. I think it is more because the hard-core developers are not open to subject their working methods to any process as such. Very likely the smartest of programmers have their on methods designed by themselves. Very likely they have invested a lot of time in developing those.
Ordinary programmers like me can’t waste so much time on arriving a system by trial and error method. I will rather prefer a ready-made solution which is very likely to work for me. I am currently reading “Introduction to the PSP” by Watts Humphrey himself. The whole book seems to be very interesting though I am just half way through.