The process of software development is not just about software development (in the code cutting, compiling, debugging sense) the real difficulties are in scoping, estimation, project management, coordination and people alignment.
I say these are real difficulties because they are typically the areas where many software developers throw up their hands and declare their
utter distaste for those parts of the work. However from a business perpsective these are the key parameters.
The average customer of software systems has about as much interest in language wars, the utility of schemas over DTDs, VB vs EJBs, XP and OOP as a car buyer has in the the underlying crystalline structure of the steel in his car.
Ergo, If you want to educate your customer as to the challenges presented by his/her schedule and functional demands couch it in terms that they have some hope of grasping. What is the purpose of the site, what is the impact to first time viewers of untested components, how will it be supported over the long term, what is the expected lifetime, what are the budgetary constraints, what are the resource constraints.
The XP (Extreme Programming not those other guys) have it right here. Programming done right is a task which requires deep concentration for long periods of time and that's just the pure coding part. To actually create and innovate demands that the lateral side of the brain is firing on all channels as well. That just isn't going to happen with permanently exhausted staff. On all the projects I've managed the deal is 40hrs a week max, proper scheduling with serious input from the development team and lets break the bad news early (from the ground up) if there are problems.
Now if we step back from the coal face and take a longer view the question you have to ask is do we expect our programming staff to pull insane hours every project? Hell no, they'll leave or in an even worse scenario they'll stay and their productivity will drop below the Z. Your fella sounds like he's either new to the game or just wrong for the job. Your can't afford to burn out a development team per project even in these down turn days.
Programming is an essentially human activity and to get the best out of your real software (the fleshy pink stuff) you need to take a long term view, but I can understand how their are many managers out there who think productivity = longer hours and thats it.
So use the simple arguments, people who are tired make more mistakes, are less likely to confer with peers, get upset when confronted or corrected, get angry more quickly and generally do a bad job (no surprises here).
Slashdot Mirror
Anything in here that would count as prior art in order to undermine the patent portfolios of Microsoft, IBM, Sun et al?
I say these are real difficulties because they are typically the areas where many software developers throw up their hands and declare their utter distaste for those parts of the work. However from a business perpsective these are the key parameters.
The average customer of software systems has about as much interest in language wars, the utility of schemas over DTDs, VB vs EJBs, XP and OOP as a car buyer has in the the underlying crystalline structure of the steel in his car.
Ergo, If you want to educate your customer as to the challenges presented by his/her schedule and functional demands couch it in terms that they have some hope of grasping. What is the purpose of the site, what is the impact to first time viewers of untested components, how will it be supported over the long term, what is the expected lifetime, what are the budgetary constraints, what are the resource constraints.
Now if we step back from the coal face and take a longer view the question you have to ask is do we expect our programming staff to pull insane hours every project? Hell no, they'll leave or in an even worse scenario they'll stay and their productivity will drop below the Z. Your fella sounds like he's either new to the game or just wrong for the job. Your can't afford to burn out a development team per project even in these down turn days.
Programming is an essentially human activity and to get the best out of your real software (the fleshy pink stuff) you need to take a long term view, but I can understand how their are many managers out there who think productivity = longer hours and thats it.
So use the simple arguments, people who are tired make more mistakes, are less likely to confer with peers, get upset when confronted or corrected, get angry more quickly and generally do a bad job (no surprises here).
Joe.