My view is that there are aspects of software development that are craft and aspects that are engineering, and both are necessary.
If you want well designed solutions (i.e. where you care about the characteristics of predictability, resilience, safety, security, recoverability) then you need an engineering process to create these solutions. “Caring about” can mean simply thinking about or considering, all the way to ensuring or guaranteeing. The more to the right you in terms of these requirements, the more you require an engineering process to get there.
That engineering process absolutely requires the application of the scientific process to test hypotheses, discover facts about the system and to provide feedback into the design process.
The process of identifying potential solutions to problems though is quite craft-like: it’s subjective, born of experience, judgement and learned heuristics, pattern recognition. These potential solutions still require the hypothesis-testing that is the bedrock of a scientific, engineering process, however.
The other characteristic of software development that is often overlooked (because of a focus on either craft or engineering) is that of curation of - and care for - a system after it has been deployed: identifying bugs and unexpected behaviour, remediating these, improving the character of the code (e.g. maintainability, clarity, etc).
I have always compared this aspect of software development to gardening: the need to do the weeding, fertilizing, turning the soil on a regular or continuous basis.
Of course the application of craft (identifying potential solutions) and engineering (testing and proving those solutions) applies just as much to this software gardening as it does to the initial design, but it’s a continuous, ongoing process able to adapt to the changing seasons of the maturity of a system and the environment in which it operates.