My office - like many software companies - has a department specifically devoted to development of the core product (we just call it "Dev"). We also have a computer system for tracking change requests for the core product. So, for example, if you find a bug that needs to be fixed you enter a description into a system and it gets doled out to one of the Dev programmers who fixes it. The same process works for enhancement requests. With every change request documented and cataloged the only question is how to match up programmers with tasks: i.e. how do you coordinate workers with jobs that need to be done. In our society this task is often handled by markets. At my company - like all software companies that I know of - markets are almost never used. To see why you have to try to flesh out what such a market would look like.
If the Dev management wanted to dole out tasks using markets they might select tasks for the developers to bid on. Each developer would call out the number of hours he think it will take him and (assuming the task is fixed) the lowest bidder wins. Once completed they'd get paid. Several problem present themselves immediately:
- Even a large company has a relatively small number of developers; They could easily collude to raise prices. A liberal like myself would call that "unionizing" and of course management doesn't want that.
- If a developer had special knowledge of a task that allowed her to complete it much faster than anyone else she'd seek to merely underbid the others by a small amount. That way she'd get credit for many more hours of work than she actually worked. Considering that it is much easier to fix bugs in code you wrote yourself this is not an unrealistic possibility. You could also combine this with 1 and get collusion among the few developers who know how to tackle a given task.
- The naive bidding system described here could easily be gamed by a developer who writes bugs into his code so he could fix them later at a profit.