Comment by 0xdeadbeefbabe
5 years ago
> At some point CS as a profession has to find the right balance of art and science.
That seems like such a hard problem. Why not tackle a simpler one?
5 years ago
> At some point CS as a profession has to find the right balance of art and science.
That seems like such a hard problem. Why not tackle a simpler one?
I didn’t downvote but I’ll weigh in on why I disagree.
The glib answer is “because it’s worth it.” As software interfaces with more and more of our lives, managing the risks becomes increasingly important.
Imagine if I transported you back 150 years to when the industrial revolution and steam power were just starting to take hold. At that time there were no consensus standards about what makes a mechanical system “good”; it was much more art than science. The numbers of mishaps and the reliability reflected this. However, as our knowledge grew we not only learned about what latent risks were posed by, say, a boiler in your home but we also began to define what is an acceptable design risk. There’s still art involved, but the science we learned (and continue to learn) provides the guardrails. The Wild West of design practice is no longer acceptable due to the risk it incurs.
I imagine that's part of why different programming languages exist -- IE you have slightly less footguns with Java than with C++.
The problem is, the nature of writing software intrinsically requires a balance of art and science no matter what language it is. That is because solving business problems is a blend of art and science.
It's a noble aim to try and avoid solving unnecessarily hard problems, but when it comes to the customer, a certain amount of it gets incompressible. So you can't avoid it.