Friday, January 13, 2012

Software Development Process....

Software Development Process in IT Services company 

I do not know how many will agree, but this is what I think!

1) The project manager along with onsite co-ordinator gathers overall requirements from the client.

2) Using some models like COCOMO, the duration for development will be estimated to be around 12 months. ( Note that COCOMO relies heavily of previous projects delivered by the firm) But business managers inform the client that the project will be delivered in 10 months (to prevent competitors from grabbing the project away.)

3) Delivery managers splits the project into 2 parts – 1 to be developed at unit A of the company, and other at unit B.

4) The project managers at Unit A and B will be having an internal competition and so each will try to deliver the project ahead of the other, so givens a time of 9 months to his unit to complete the job!

5) The project begins at both units, and Software Engineers start the development.

6) Since the software service industry is heavily 'process-oriented', the developers are required to submit their 'activity reports' every week. This report will contain, among other things, the duration spend on each specific activity within the software cycle (like designing,test case preparation, reviews,coding etc). 

7) Developers were told this by their managers. “This process is estimated to take 10 hours, so if you want to get a good appraisal next time (Out-performer), you should finish it in 9 hours or less!”. (The original estimate would be definitely above 12 or more hours!)

8) The developers works hard but sees that it is going to take much more than 10 hours. But to get that 'Out-Performer' tag, he decides to work extra hours every day, but while submitting the 'activity report', he says the job was completed in '9 hours', (it actually took 15+ hours ) 

9) Developers themselves will be doing a lot of peer review and testing, and they are supposed to enter the defect information found in deliverable in some internal tracking tool. This internal repository is to be used for training purposes and to prevent the same in future. But most developers will not enter the defects found in peer reviews into this system, but informs the peer (usually his/her friend) about this offline. (in person). This 'mutual-help' habit is followed by all developers to prevent their bugs/defects from being recorded in the system.

10) The entire duration of the project will be like this, with developer submitting 'excellent' activity reports. Finally the project is completed and will be delivered to client and everybody is happy.

11)The end-result : Project will be delivered in time. All the internal systems will show that there weren't any defects/bugs at any point of the process and all jobs were completed well before the estimated times!

12)Now, the next project (very much similar to previous one) comes in, and the estimating models will be giving a much shorter duration for this, because the internal systems says these jobs can be done faster than ever thought of!!!!

13) And now the cycle repeats itself, with developers ending up working late nights/weekends and spoiling the good part of their lives.

"The trouble with the rat race is that even if you win, you're still a rat."


  1. Awesome Sir...:D .. So this is what happens in software companies.... But for me this looks cool , if we work with the same team always , then its kinda like fine... :P

  2. I strongly disagree with your 7th point. I will say the developer should have the guts to convince the manager that the estimate is short if it is so. This will change the flow of the process which falls in your later points. This helps a better quality delivery of the project (because overworking will compromise the quality one or the other way) and helps the client to come back with more projects in future on basis of the quality of delivered project. This is something that I experienced and I practiced in my life at IT. But, I don't really know how many will really accept it. Everyone have their own right and wrong.

  3. @Rino - Even me too agrees with you! But this is what I found in my limited experiece! Just posted what I saw !