This is fabulous stuff! > That would be a pretty stupid manager then. That's saying "I don't mind > my developers costing me over $6,000 to learn something that I could send > them on a course to learn for just $2,500!" - it has nothing to do with > bottlenecks or constraints and everything to do with plain ol' efficiency > and sensible budgeting...
There is no such thing as "plain old efficiency". Or, rather, there is, but it causes a lot of problems. It's sort of like "unit cost", another cost accounting fiction that causes untold problems. 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. Now, you might be able to lay off a programmer if you train another one well enough to do the work that took two programmers before, and that would be a real savings. Otherwise, there is only a fictional savings. If the programmer is a system constraint, on the other hand, and training up that programmer will complete more work, that's not a savings, that's a potential to realize additional revenue. This is a non-trivial difference. 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). >> Pursuing individual developer efficiency is a typical goal, but it is >> not the right goal for a company. The company should optimize the whole >> system efficiency. > So send the whole damn team on the course! Unless your entire company is composed of programmers, then the system is more than just the IT department. Sending the whole IT team to training may increase the efficiency of the IT department, but might not make any difference to the efficiency of the company. System efficiency isn't jus the sum of local efficiencies. >> Sometimes you want people in a manufacturing plant sitting around >> reading the paper rather than working, because if they are more efficient, >> the whole system suffers. > You've got to be a troll with a response like that... You want to pay > people to do nothing??? No troll. Assume you have a process like this: 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. You don't want A to do process 10 units per hour because it will create an inventory in front of B. That inventory is cash bound up in Work In Process, which is money that is not earning interest, which means the inventory is costing the company money. You actually want the people running the A machine to do 5 units an hour and then sit around. If you can cross train them to do something else, that's fine. But if you can't, then you have them sit around. They aren't doing nothing, they are contributing to the system-level efficiency. This is standard operations management, which is a good field of study for programmers, actually. > So you'd rather have a team of people bumbling along making mistakes > and paying them lots and lots of money to get a half-assed product > out the door when you could have spent less, got something better and > got it quicker? You are assuming here that the programmer is a system constraint, and the only thing keeping product from moving out the door is a more productive programmer. If this is true, then of course you should send the programmer to training. Sometimes the programmer is not the system constraint, though, and more efficient programmers just mean that more software is queued up in front of the QA department, or waiting on complementary products from marketing, or so on. As I've said several times, if the programmer is the system constraint, do what you need to do to make the programmer work faster and better. If the programmer is not the constraint, however, then spending money for training in search of fictional "efficiencies" is nonsensical. --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]
