> Your main thesis is that software and computing should be optimized to ship products to consumers.
Those were just examples of other things I thought were more important, it wasn't an exhaustive list. However, it's interesting that you focus in on "optimizing to ship products to consumers", when I made mention of no such thing. I mentioned development velocity and end-product reliability. These are things that are important to the process of software development regardless of the scale of the project or the team working on it or the financial implications of the project.
They are tools. Tools for making things. They enable both faceless corporations who want to make filthy lucre by shipping boring line-of-business apps and individuals who want to "expand human potential" or "instill a sense of wonderment and discovery".
Reliability and robustness are very fundamental aspects to all software, no matter how it's built. And tools such as automated builds combined with unit and integration tests have proven to be immensely powerful in facilitating the creation of reliable software.
If your point is that non-commercial software need not take advantage of testing or productivity tools because producing a finished product that runs reliably is unimportant if you are merely trying to "expand human potential" or what-have-you then I reject that premise entirely.
If you refuse to acknowledge that the tools of the trade in the corporate world represent a fundamentally important contribution to the act of programming then you are guilty of the same willful blindness that Bret Victor derides so heartily in his talk.
Those were just examples of other things I thought were more important, it wasn't an exhaustive list. However, it's interesting that you focus in on "optimizing to ship products to consumers", when I made mention of no such thing. I mentioned development velocity and end-product reliability. These are things that are important to the process of software development regardless of the scale of the project or the team working on it or the financial implications of the project.
They are tools. Tools for making things. They enable both faceless corporations who want to make filthy lucre by shipping boring line-of-business apps and individuals who want to "expand human potential" or "instill a sense of wonderment and discovery".
Reliability and robustness are very fundamental aspects to all software, no matter how it's built. And tools such as automated builds combined with unit and integration tests have proven to be immensely powerful in facilitating the creation of reliable software.
If your point is that non-commercial software need not take advantage of testing or productivity tools because producing a finished product that runs reliably is unimportant if you are merely trying to "expand human potential" or what-have-you then I reject that premise entirely.
If you refuse to acknowledge that the tools of the trade in the corporate world represent a fundamentally important contribution to the act of programming then you are guilty of the same willful blindness that Bret Victor derides so heartily in his talk.