Quote:
Originally Posted by Shaggy
I assume you're not a programmer?
|
No kidding. "It is just software programming" is probably the worst assumption of the decade from the end-customer.
There are varying degrees of programmer, which will all get work done on different schedules, and the better ones tend to be expensive since they can follow the money easily.
I work for a larger company, and our product tends to run up roughly 50k bugs per major release. That's before the user gets to see anything in their hands, and it does include some pretty silly things that can easily be an hour to fix, but some take up to a week for a dev to fix them depending on how familiar they are with the code the bug is in.
Small projects tend to be very fluid, fixes for simple bugs can be pushed out to customers in days, and so on. This is true especially if the bugs found after a release are small in number (good dev practices). Large projects tend to draw in a lot more time, and iRex is pushing a modified Linux OS on their devices. Their devs are responsible for customizing that OS for their device, in addition to their apps which run on top of it to make the e-reader and actual e-reader.
I'd still be interested to see exactly what caused the delay (miscalculation on the incoming bug count on the beta? Overall schedule slips from bad estimates on how long the work would take?).