Changing code requires a re-test, doesn't matter whether you have moved a full-stop in a comment or whether you have re-engineered an algorithm. Remember that small changes are often smiple.
It sounds like you have the ability to unit test so forced retests should be complete on a nightly build. It's how I'd do it.
If managers want a measure of progress then the team should know this.
"Percieved" progress and "actual" progress can vary. A prototype can give a lot of percieved progress but no (hopefully) actual progress.
80-20 rule always kicks in when trying to measure progress. I've known developers who manage to keep their project 90% complete (yeah, you know who you are) for a very long time.
I prefer having an almost constantly shippable product from the outset. It's difficult to achieve early on but it can be done very soon with basic functionality.
It also provides a good way to test design and implementation. Aim to get something working within spec. asap and everyone will be pleased.
It also provides a good measure of progress. Ticking features off a list reassures the managers and gives a good boost to the team. Admittedly it's not possible for some projects with lots of core features needed to be built from scratch.
Should the shit hit the fan (like a competitor doing a release) then features can be dropped and the product shipped much quicker. It means renaging on some promises made to customers but if you have been open and honest with them they'll understand, also, if you release early/often they don't mind waiting for X if the have Y.
You've just got to keep an eye on the team, harass them for quality, and reward excellence.
My measure of productivity is based on delivery of code/features that falls within my quality guidelines. This includes lack of bugs, code layout, comments and reuse. e.g. A feature can be 'working to spec.' but if it has no comments in the code then it's not 'finished'.
I also know developers that quickly write the code, do all the testing and then call the feature finished. They then go back and add comments, correct variable naming and touch the code in other ways (adding whitespace, reoganising if's) - they fail to realise that they now need to perform all the same tests again, which of course they never do. This is *low* productivity IMO and is generally poor style.
If their calculation took more than 4 months, and they estimate that a high-end home PC would take 750 years then their machine is only 2250 times more powerful than a home PC.
My PC is dual athlon 1800+ so maybe my PC would do it in 'just' 375 years.
Why don't they use a distributed network like SETI instead. Save millions and get it done quicker.
And share the results so others (Pakistan etc.) can stop their testing.
Thing is that most people e.g. the 'normal' people do not rip MP3s, and even if they do they do it for themselves. But assuming they don't - then having to do phone-jack to input type recordings really takes the fun out of it. I mean; no link to CDDB, no seperate tracks with hassle etc.
Normal people will give up, but nothing will stop the hardcore crews.
But that's what these stoneage businesses rely on. If it's easy then it's a no-no, but if it's hassle then very few will do it. Simple, yet effective.
It's also a good use of their time. If they make it tough for 90% then they have done a good job and they can go home.
First thing I do when I buy (yes buy) a CD is rip it so I can have it at home and work. If they ruin it for me I'll simply stop buying...and that's the potential flaw in their plan I guess.
The *source* is what they created their oh-so-clever obfuscated code from. That's the bit the GPL refers to. Same would be said if they used a fancu GUI tool to generate the code I guess.
Go ahead and let them do it. It would be great to see the GPL virus tested in court for a change.
Slashdot Mirror
Sounds like fun but it sounds right to me.
Changing code requires a re-test, doesn't matter whether you have moved a full-stop in a comment or whether you have re-engineered an algorithm. Remember that small changes are often smiple.
It sounds like you have the ability to unit test so forced retests should be complete on a nightly build. It's how I'd do it.
If managers want a measure of progress then the team should know this.
"Percieved" progress and "actual" progress can vary. A prototype can give a lot of percieved progress but no (hopefully) actual progress.
80-20 rule always kicks in when trying to measure progress. I've known developers who manage to keep their project 90% complete (yeah, you know who you are) for a very long time.
I prefer having an almost constantly shippable product from the outset. It's difficult to achieve early on but it can be done very soon with basic functionality.
It also provides a good way to test design and implementation. Aim to get something working within spec. asap and everyone will be pleased.
It also provides a good measure of progress. Ticking features off a list reassures the managers and gives a good boost to the team. Admittedly it's not possible for some projects with lots of core features needed to be built from scratch.
Should the shit hit the fan (like a competitor doing a release) then features can be dropped and the product shipped much quicker. It means renaging on some promises made to customers but if you have been open and honest with them they'll understand, also, if you release early/often they don't mind waiting for X if the have Y.
You've just got to keep an eye on the team, harass them for quality, and reward excellence.
My measure of productivity is based on delivery of code/features that falls within my quality guidelines. This includes lack of bugs, code layout, comments and reuse. e.g. A feature can be 'working to spec.' but if it has no comments in the code then it's not 'finished'.
I also know developers that quickly write the code, do all the testing and then call the feature finished. They then go back and add comments, correct variable naming and touch the code in other ways (adding whitespace, reoganising if's) - they fail to realise that they now need to perform all the same tests again, which of course they never do. This is *low* productivity IMO and is generally poor style.
Coding *is* art and I am an 'artished'.
I'm sorry but you are nut, don't post without your tinfoil hat.
Was that before or after Mandrake$oft announced their impending demise...
...works a treat on my iPaq and no nasty, crappy old software to install. JUst drop the baby in it's cradle and it's all syned up.
Lurvly.
If their calculation took more than 4 months, and they estimate that a high-end home PC would take 750 years then their machine is only 2250 times more powerful than a home PC.
My PC is dual athlon 1800+ so maybe my PC would do it in 'just' 375 years.
Why don't they use a distributed network like SETI instead. Save millions and get it done quicker.
And share the results so others (Pakistan etc.) can stop their testing.
Thing is that most people e.g. the 'normal' people do not rip MP3s, and even if they do they do it for themselves. But assuming they don't - then having to do phone-jack to input type recordings really takes the fun out of it. I mean; no link to CDDB, no seperate tracks with hassle etc.
Normal people will give up, but nothing will stop the hardcore crews.
But that's what these stoneage businesses rely on. If it's easy then it's a no-no, but if it's hassle then very few will do it. Simple, yet effective.
It's also a good use of their time. If they make it tough for 90% then they have done a good job and they can go home.
First thing I do when I buy (yes buy) a CD is rip it so I can have it at home and work. If they ruin it for me I'll simply stop buying...and that's the potential flaw in their plan I guess.
The *source* is what they created their oh-so-clever obfuscated code from. That's the bit the GPL refers to. Same would be said if they used a fancu GUI tool to generate the code I guess. Go ahead and let them do it. It would be great to see the GPL virus tested in court for a change.