Software matters because without it a computer-controlled instrument, device, or system is just a collection of plastic, metal, and silicon. It does nothing.
Without software an interferometer is just a bunch of mirrors and lenses. Without software a CCD or CMOS image sensor is just a slab of inert silicon. Without software a deep space probe is a piece of very expensive metal sculpture. Without software data collection and analysis becomes an exercise in jotting numbers in a notebook, pushing a slide rule to get approximate numerical results, and dealing with errors. Lots of errors.
Good software is not trivial, nor is it easy. It is not the simple exercises encountered in undergraduate courses, nor is it the hacked logic and unreadable gibberish generated by overcaffeinated graduate students late at night. Good software is the result of applied discipline, resulting in the creation of an abstract logical construct that is coherent, readable, elegant, and reusable. Good software is beautiful.
You don’t wake up every morning, assemble an ad-hoc automobile from scratch, drive it to work (if it runs), and then simply leave the vehicle in the parking lot to rust or get tossed into a dumpster, do you? Why should software be treated as a throw-away thing of no value? It took effort to work out what was needed to solve the problem and then write it and test it. Maybe it took 30 minutes, perhaps it required 30 days, but that time has been spent, and it is gone forever. Why would you casually throw it away?
Software of any significance is, by its very nature, prone to internal inconsistencies and defects. These are otherwise known as bugs. Only the most trivial programs might qualify as being 100% error-free, and even then little things can still lurk in the corners. This must be understood and taken into account. Failure to do so is a certain path to failure. This is why both design and testing are key factors to success when creating good software. By omitting either of these steps (takes too long, no tangible results, doesn’t seem to apply to the goal of getting results, data, or product out the door) the software becomes an unknown. It might work, it might not, and it might fail at the worst possible time. Having software fail in front of project reviewers or customers is usually not a good thing, but it happens all the time.
Treating software as a trivial part of a project is one of the worst mistakes one can make. It is anything but trivial. The success or failure of any computer-dependent project hangs on the ability of the software to do its intended function, reliably and robustly.