> 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.
(1) Unless you are paying them less, you are not getting a result for less money. If you pay your programmers by the hour, then you're right. But I'll warrant that most programmers are salaried, so the company pays them the same $$ whether they do X or X+1. The savings you are talking about are accounting fictions, not real cost reductions. It is an increase in Throughput, not a decrease in Operating Expense. This is a non-trivial difference, because depending on which one you focus on, you will make different decisions. (2) Cost-per-project is a cost accounting fiction. Just like cost-per-unit. Unless you pay people on a unit basis and therefore pay less when less is made, the operating expenses of the company don't change. You are talking fictional accounting costs, not real operational costs. Cost-per-project, just like cost-per-unit, is a great way to screw over a company. You keep trying to reduce cost-per-unit (or cost-per-project) and all you manage to do is drive up a local optima and the global system suffers. This is not exactly news, Goldratt/Deming/et alia have been writing about this stuff for years. But it doesn't get into software shops for some reason. (Probably because of the "we're not factory workers, we're *special* and the rules don't apply to us" attitude that prevails in many software departments). > 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). If you look at the justifications in the Ford, GM and other car company annual reports in the 80s, they all talk about increasing efficiency and "reducing unit-cost". Cost accounting screwed them over while Toyota was outperforming them based on constraints-based manufacturing. > Efficiency of scale. Double your raw materials, > double the A process, quadruple the B process > and triple the C process. Oh, well, if we are imagining that someone can just walk into the company and scale up the processes that easily, then that's fine. It's a magical world of unicorns and rainbows, but fine. I was talking about more of the actual world, where process change is hard and politically difficult. If you know some training I can send the company to that will allow us to arbitrarily multiply the throughput of all our processes and let use buy twice as many raw materials with our available cash, then sign me up! > Not really. Programmers are not factory assembly workers. In many cases, yes they are. Glorified factory workers in some cases, but most ColdFusion programming is for the same old CRUD forms that differ only in the words on the form. And most of the ones who aren't doing this are still a part of a company that has a system of policies and process flows that define the incoming and outgoing parts flow. It's called project management in a knowledge worker company, and uses PERT charts instead of assembly lines, but the system principles are all the same. This is just the "we're *special* because we're programmers" mentality. --Sean Stickle -- 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] ---------------------------------------------------------- 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]
