Interesting article on the software development process

[gaf at blu.org (Jerry Feldman)]

He's got some good points, but some bad ones also. One point he makes is 
"Only the programmer who is going to write the code can schedule it". From 
years of experience as both a programmer and a manager, this is wrong for 
several reasons:
First, When planning a project, you may not yet have your team on board. 

Secondly, programmers are incurable optimists. A good software manager 
knows how to take a programmer derived schedule and make it realistic. 

Thirdly, there are times when a schedule must be imposed. 


In any case, in any development project there are 3 variables:
1. resources - eg. programmers (skills et. al).
2. time
3. Features. 

When you compress time, you generally drop out features. Resources can be 
addred or subtracted, but it takes time to do this. Some resources are 
available in house, others must be acquired. 

Another issue, which he does mention is "creeping functionality". 
Programmers (me included) love to add nice features to a product. But, 
these features often cause problems, and when unplanned are not tested. 

And, since I mentioned test, programmers are generally not good testers. 
I've worked with programmers who were very productive, but always created 
buggy code. You need a method of testing the code. Much of the time, the 
pressure to ship causes the testing and QA cycles to be compressed. We've 
all use Microsoft Products. 



On 4 Jun 2002 at 14:05, David Kramer wrote:

> 
> http://www.joelonsoftware.com/articles/fog0000000245.html

--
Jerry Feldman <gaf at blu.org>
Associate Director
Boston Linux and Unix user group
http://www.blu.org PGP key id:C5061EA9
PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9