Every once in a while, someone gets the bright idea that the job of a software developer can be eliminated through automation.
The fundamental problem with this idea is that software developers are already continuously automating the repetitive tasks within their jobs through the creation of new and better tools, so that the tasks remaining to the developer generally involve a significant degree of creativity and craftsmanship.
A closely related fallacy is that the element of craft can be eliminated through the creation of “software factories,” by applying principles of industrialized mass production to the job of software development.
But the notion of a software factory implies that there exists some means of specifying the intended software design that is somehow easier or better than producing the software code itself; again, though, once we acknowledge that the most repetitive coding tasks have already been automated, then the coding that remains is generally the best available means of documenting the detailed design of the software being produced; alternatives are either less complete and/or more difficult to evaluate.
The other problem with the idea of a software factory is the implicit notion that a product that exactly meets specifications is better than a product that exceeds expectations. In manufacturing, of course, we accept this as a given – if I order a widget from Amazon, I want the same widget that others have already purchased and reviewed, not a unique item that has been “improved” by the work of a craftsman in the factory; in the case of software, though, we are never producing exactly the same thing more than once, so the industrial values of standardization and consistency do not apply. Instead, what we find is that a craftsman can often add value to the finished software by producing something better than the minimum needed to satisfy the starting expectations: something more useful to the customer, and/or something easier and cheaper to maintain and enhance in the future.