2 ms·

My read is that a standard industry practice (e.g. considering programmers interchangeable pieces and that components should be designed with that in mind) will

by the_af 4y ago

My read is that a standard industry practice (e.g. considering programmers interchangeable pieces and that components should be designed with that in mind) will work in many situations, and therefore the "standard" is reasonable for most of them, but the best practice is context-sensitive; in this case, the context didn't require C++/Java and they were actually not good choices. This was specialized, mission-critical software developed on a tight schedule and swapping programmers in/out of the project simply wouldn't work, so many considerations for choosing (say) Java were out of the question.

michael1999 4y ago
There is not such thing as a best practice without specifying a context. The kind of build hygiene required for long-lived commercial product is very different from disposable marketing content. This is especially toxic when the underlying context and goals are so different. Businesses wants interchangeable programmers for many reasons: so they can ramp team size up and down, so hiring is easy, etc. But the number one reason in my experience is to minimize the bargaining power of the programmers. Execs absolutely _hate_ having star programmers holding them up for raises. Building complicated in-house tooling in a language like lisp might make it rain, but the devs are then in a position to demand a slice. Procurement 101 is always have secondary vendors to keep your main vendors honest. Lower productivity is an acceptable price to avoid being held up. This is a very different context from somewhere like JPL where any programmer there could already leave for more money in industry. Anyone there is already committed to the mission. The cost of lower productivity isn't justified, and might make certain activities simply impossible given the current budgets.
- the_af 4y ago
  > There is not such thing as a best practice without specifying a context. Just to be clear: we are in agreement, right? The author of TFA is stating this, and that the JPL misunderstood its own context. It wasn't the kind of business/project where your second paragraph applies, and so the practices they adopted were mistmatched.
  - michael1999 4y ago
    Yes.

by the_af 4y ago

michael1999 4y ago

There is not such thing as a best practice without specifying a context. The kind of build hygiene required for long-lived commercial product is very different from disposable marketing content. This is especially toxic when the underlying context and goals are so different. Businesses wants interchangeable programmers for many reasons: so they can ramp team size up and down, so hiring is easy, etc. But the number one reason in my experience is to minimize the bargaining power of the programmers. Execs absolutely _hate_ having star programmers holding them up for raises. Building complicated in-house tooling in a language like lisp might make it rain, but the devs are then in a position to demand a slice. Procurement 101 is always have secondary vendors to keep your main vendors honest. Lower productivity is an acceptable price to avoid being held up. This is a very different context from somewhere like JPL where any programmer there could already leave for more money in industry. Anyone there is already committed to the mission. The cost of lower productivity isn't justified, and might make certain activities simply impossible given the current budgets.

the_af 4y ago
> There is not such thing as a best practice without specifying a context. Just to be clear: we are in agreement, right? The author of TFA is stating this, and that the JPL misunderstood its own context. It wasn't the kind of business/project where your second paragraph applies, and so the practices they adopted were mistmatched.
- michael1999 4y ago
  Yes.