3 ms·

Suppose your team needs new workstations. Or an RDBMS, a server operating system, a compiler, a profiler, or any number of things. “Write down the requirements

Suppose your team needs new workstations. Or an RDBMS, a server operating system, a compiler, a profiler, or any number of things. “Write down the requirements, we will put out an RFP and give you the cheapest supplier that satisfies the requirements” is an absurd approach. The people on your team have familiarity and proficiency with certain tools, experience with many more, and professionally informed opinions of most. These things vary wildly in terms of quality and fitness for purpose in ways that are wickedly hard to pin down in a document listing objective criteria. The best tools may be open source, or from small time shareware shops that will not submit proposals. There may be some discount IDE out there with the same feature set as IntelliJ but unbearably frequent crashes. Well, there is no credible independent report proving its deficiency, so it’s what you’re going to get. There are some ridiculous programming languages out there, but “not ridiculous according to my team” is a clearly subjective and corrupt requirement. Do you think following this process faithfully will make your team more or less efficient than rigging it to land on the tools you know to be right for the job?

AnthonyMouse 7y ago
> These things vary wildly in terms of quality and fitness for purpose in ways that are wickedly hard to pin down in a document listing objective criteria. It's more work. It's not impossible. And when the difference is literally millions of dollars, it's worth doing the work. > The best tools may be open source, or from small time shareware shops that will not submit proposals. If they're open source then you don't need to solicit bids because you're not appropriating money, and if the bidding process excludes small legitimate vendors then you can start by addressing that. > There may be some discount IDE out there with the same feature set as IntelliJ but unbearably frequent crashes. "Doesn't crash more than once per N hours of normal usage" is a fairly objective criteria that can be specified under terms like "if it does that then payment is withheld until you fix it." > There are some ridiculous programming languages out there, but “not ridiculous according to my team” is a clearly subjective and corrupt requirement. Then identify the thing that objectively makes it unsuitable and add that to the requirements. It can't be subjectively ridiculous yet have no objective defects unless your subjective determination is without merit. The difference between this and rigging the bid is that if e.g. the IDE that is only unsuitable because it crashes all the time could have that defect corrected for a million dollars, and it's a ten million dollar contract, it becomes worth it for the other vendor to fix their code so they can bid on the contract, whereas if you rig everything then that's impossible and the sole vendor gets to charge the taxpayer monopoly prices.

AnthonyMouse 7y ago

> These things vary wildly in terms of quality and fitness for purpose in ways that are wickedly hard to pin down in a document listing objective criteria. It's more work. It's not impossible. And when the difference is literally millions of dollars, it's worth doing the work. > The best tools may be open source, or from small time shareware shops that will not submit proposals. If they're open source then you don't need to solicit bids because you're not appropriating money, and if the bidding process excludes small legitimate vendors then you can start by addressing that. > There may be some discount IDE out there with the same feature set as IntelliJ but unbearably frequent crashes. "Doesn't crash more than once per N hours of normal usage" is a fairly objective criteria that can be specified under terms like "if it does that then payment is withheld until you fix it." > There are some ridiculous programming languages out there, but “not ridiculous according to my team” is a clearly subjective and corrupt requirement. Then identify the thing that objectively makes it unsuitable and add that to the requirements. It can't be subjectively ridiculous yet have no objective defects unless your subjective determination is without merit. The difference between this and rigging the bid is that if e.g. the IDE that is only unsuitable because it crashes all the time could have that defect corrected for a million dollars, and it's a ten million dollar contract, it becomes worth it for the other vendor to fix their code so they can bid on the contract, whereas if you rig everything then that's impossible and the sole vendor gets to charge the taxpayer monopoly prices.