At least in my personal experience, a client who couldn’t have written the software themselves usually gets a slow, buggy product with a terrible UI. (My uncle is a good example here—he’s in the septic business, hired someone to make a simple app for keeping track of his customers. It’s a mess.) By contrast, at most of the places where I’ve worked or my friends have worked which produce noticeably good software, the bulk of the managers are themselves software engineers or former software engineers, and leadership always has at least some object-level software experience.
The main outsourcing step which jumps between a non-expert and an expert, in that context, is usually between the customer and the company producing an app. And that’s exactly where there’s a standardized product. The bespoke products for non-expert customers—like e.g. my uncle’s app for his business—tend to be a mess.
But you don’t need to be able to code to recognize that a software is slow and buggy!?
About the terrible UI part I agree a bit more, but even there one can think of relatively objective measures to check usability without being able to speak python.
True! And indeed my uncle has noticed that it’s slow and buggy. But you do need to be able to code to distinguish competent developers, and my uncle did not have so many resources to throw at the problem that he could keep trying long enough to find a competent developer, while paying each one to build the whole app before finding out whether they’re any good. (Also I don’t think he’s fully aware of how bad his app is relative to what a competent developer could produce.)
I don’t believe these “practical” problems (“can’t try long enough”) generalize enough to support your much more general initial statement. This doesn’t feel like a true rejection to me, but maybe I’m misunderstanding your point.
It seems like the fundamental cause of the problem with your uncle’s customer tracking app is some combination of:
He paid for ongoing effort, rather than delivering satisfactory results. Instead of a bounty model, he used a salary or wage model to pay the programmer.
He lacked the ability to describe what exactly would make the app satisfactory, impairing his ability to pay for results rather than effort.
In other words, the “bounty-compatible” criteria for outsourceability was not met in this case. This raises the question of what to do about it.
If he didn’t know how to specify all his performance requirements, could he have hired somebody to help him do so?
If he’d tried to outsource identifying performance requirements, could he have applied the bounty model to that job?
If he had offered a bounty in exchange for an app meeting his requirements, would his offer of a bounty have been believable?
If his offer of a bounty was believable, would a competent programmer have been willing to pursue that bounty?
As we pose these questions, we see that society’s overall ability to outsource effectively is bottlenecked by the availability of high-quality bounty offer interfaces. A bounty offer interface should help the user define a satisfactory result, broadcast bounty offers to a competent professional network, and make the bounty offer credible.
it sounds like there have been some attempts at creating bounty interfaces for app development. One active site for this purpose is replit. However, as I scan some of their open bounties, the problem description, acceptance criteria, and technical details seem woefully underspecified, with no apparent ability to make bounty offers credible, and I also don’t see any signs that replit is plugged into a competent developer network. Bepro is another such site, but has a confusing interface and the same problems as replit. If I was an employer or programmer, I would probably not waste my time on either of these websites. Some major companies, like Intel, have bug discovery bounty programs.
Overall, it seems like it’s more difficult to build a market for bounty-based contracts. With a wage- or salary-based system, a worker can minimize their losses by quitting if their employer stops paying them. The employer doesn’t need to have the requirements completely specified up front in order to attract talent. Trust can be built on the basis of reputation, willingness to pay, and cultivation of a relationship. Financial rewards for doing work are immediate, and employers get to see the product being built and adjust it as their requirements change in a dynamic business environment. On top of that, wage- and salary-based models are familiar, so it’s easy to attract participants. There is some ability for a non-expert to identify good freelance wage/salary-based coders by selecting highly-paid coders with excellent reviews, which in turn incentivizes those coders to earn good reviews by producing quality software in a reasonable timeframe and budget.
For all of these reasons, in practice, bounties may not be a realistic way to pay for nonstandard goods and services in many cases, sharply limiting the ability to outsource without an omni-competent leader to organize the effort. But perhaps there is an opportunity for someone to deal with the failure modes of bounty-based models and create a new and improved marketplace for bounty-based app development?
At least in my personal experience, a client who couldn’t have written the software themselves usually gets a slow, buggy product with a terrible UI. (My uncle is a good example here—he’s in the septic business, hired someone to make a simple app for keeping track of his customers. It’s a mess.) By contrast, at most of the places where I’ve worked or my friends have worked which produce noticeably good software, the bulk of the managers are themselves software engineers or former software engineers, and leadership always has at least some object-level software experience.
The main outsourcing step which jumps between a non-expert and an expert, in that context, is usually between the customer and the company producing an app. And that’s exactly where there’s a standardized product. The bespoke products for non-expert customers—like e.g. my uncle’s app for his business—tend to be a mess.
But you don’t need to be able to code to recognize that a software is slow and buggy!?
About the terrible UI part I agree a bit more, but even there one can think of relatively objective measures to check usability without being able to speak python.
True! And indeed my uncle has noticed that it’s slow and buggy. But you do need to be able to code to distinguish competent developers, and my uncle did not have so many resources to throw at the problem that he could keep trying long enough to find a competent developer, while paying each one to build the whole app before finding out whether they’re any good. (Also I don’t think he’s fully aware of how bad his app is relative to what a competent developer could produce.)
I don’t believe these “practical” problems (“can’t try long enough”) generalize enough to support your much more general initial statement. This doesn’t feel like a true rejection to me, but maybe I’m misunderstanding your point.
It seems like the fundamental cause of the problem with your uncle’s customer tracking app is some combination of:
He paid for ongoing effort, rather than delivering satisfactory results. Instead of a bounty model, he used a salary or wage model to pay the programmer.
He lacked the ability to describe what exactly would make the app satisfactory, impairing his ability to pay for results rather than effort.
In other words, the “bounty-compatible” criteria for outsourceability was not met in this case. This raises the question of what to do about it.
If he didn’t know how to specify all his performance requirements, could he have hired somebody to help him do so?
If he’d tried to outsource identifying performance requirements, could he have applied the bounty model to that job?
If he had offered a bounty in exchange for an app meeting his requirements, would his offer of a bounty have been believable?
If his offer of a bounty was believable, would a competent programmer have been willing to pursue that bounty?
As we pose these questions, we see that society’s overall ability to outsource effectively is bottlenecked by the availability of high-quality bounty offer interfaces. A bounty offer interface should help the user define a satisfactory result, broadcast bounty offers to a competent professional network, and make the bounty offer credible.
it sounds like there have been some attempts at creating bounty interfaces for app development. One active site for this purpose is replit. However, as I scan some of their open bounties, the problem description, acceptance criteria, and technical details seem woefully underspecified, with no apparent ability to make bounty offers credible, and I also don’t see any signs that replit is plugged into a competent developer network. Bepro is another such site, but has a confusing interface and the same problems as replit. If I was an employer or programmer, I would probably not waste my time on either of these websites. Some major companies, like Intel, have bug discovery bounty programs.
Overall, it seems like it’s more difficult to build a market for bounty-based contracts. With a wage- or salary-based system, a worker can minimize their losses by quitting if their employer stops paying them. The employer doesn’t need to have the requirements completely specified up front in order to attract talent. Trust can be built on the basis of reputation, willingness to pay, and cultivation of a relationship. Financial rewards for doing work are immediate, and employers get to see the product being built and adjust it as their requirements change in a dynamic business environment. On top of that, wage- and salary-based models are familiar, so it’s easy to attract participants. There is some ability for a non-expert to identify good freelance wage/salary-based coders by selecting highly-paid coders with excellent reviews, which in turn incentivizes those coders to earn good reviews by producing quality software in a reasonable timeframe and budget.
For all of these reasons, in practice, bounties may not be a realistic way to pay for nonstandard goods and services in many cases, sharply limiting the ability to outsource without an omni-competent leader to organize the effort. But perhaps there is an opportunity for someone to deal with the failure modes of bounty-based models and create a new and improved marketplace for bounty-based app development?