On 1/16/06, Sean Stickle <[EMAIL PROTECTED]> wrote: > Unless you are going to pay your developers less if they get things done > quicker, then training them quicker isn't going to save you any money.
If they get stuff done quicker you are getting a result for less money. If you keep them busy with projects, you will get more projects done per year therefore the cost-per-project is lower. Throughput has value. > Automakers spent money to install robots to > increase efficiency, but if the robots weren't on the system constraint, > they actually cost money, and there was no savings at all (except > fictional cost accounting savings). Actually there were lots of reasons for replacing low-skill manual workers with automated systems. Efficiency was a factor (but mostly because you could then run a factory 24x7 with far fewer staff). Consistency was a big factor (probably a bigger factor). > Raw materials -> A(10) -> B(5) -> C(7) -> Market > > Where A can process 10 units of output per hour, B can do 5 per hour, > and C can do 7 per hour. Efficiency of scale. Double your raw materials, double the A process, quadruple the B process and triple the C process. 2 x raw -> 2 x A(2x10=20) -> 4 x B(4x5=20) -> 3 x C(3x7=21) -> 2 x market Now all of your processes are matched and you can maintain optimum pipeline efficiency. The real throughput of your initial system was 5 per hour (since B was the bottleneck). Just doubling up B would have gotten you to 7 per hour (not much of an improvement). Note: If the cost of 2A + 4B + 3C is too high to sustain 20 units/hour then your original model (producing only 5/hour) would also have had too high a cost to be sustainable. > This is standard operations management, which is a good field of study > for programmers, actually. Not really. Programmers are not factory assembly workers. -- Sean A Corfield -- http://corfield.org/ Got frameworks? "If you're not annoying somebody, you're not really alive." -- Margaret Atwood ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
