Imagine if you could build a skyscraper by running the blueprints through a machine that automatically builds it with essentially zero costs, and then you can just tear it down and rebuild it again deppending on how it responds. The engineering methods applied would be completely different. And furthermore, it would incentivize a close iteration and "sketch"-like process that would approach to something that people can considered "artistic", becasue you replace the "let's be 100% sure our specs are perfect and follow strict mathematical models before building" with "let's just build it and figure it out".
This is what happens in software. The code is the blueprint, the exact spec, and "building it" means running it through the compilation/deployment pipeline.
Software is a machine, but the main difference with other machines is not that you can't analyze it with math or can't approach it as classical engineering, is that it's not economically feasible to do so. The translation from the blueprint (the unambiguous, absolute and exact spec, the CODE) to the final product (the deployed working system) is "automatic" and basically free from material costs.
PS: And add to this the fact that most software is NOT "critical" (as in "if it fails in production people die").
Is an architect an engineer? They draft and re-draft their blueprints until they are happy with them, and then oversee the construction process making changes to the plan as necessary. This is analogous to writing software and deploying it. There's more at stake perhaps, but the process is not all that different.
IMHO, this sounds more like the distinction between theoretical science and experimental science. You may consider one or the other art, but to me they both can be.
The author doesn't know the subject matter or, to be blunt, is full of excrement. From TFA: " If you ask Michelangelo to paint the ceiling of your chapel, you are asking him to function as an artist; if you dictate to him the nature, coloration, size and relationship of the objects he will portray there, you are asking him to function as an engineer."
Porque no las dos? (Why not both?) Art and Engineering go together in many cases and have been for thousands of years. All historical landmarks and statues required good artistic skills. At the same time, there is an engineering aspect to them. You cannot just build whatever comes to your mind. There are mathematical calculations that have to be done first. Same applies to Software. Software development has gotten so big and complex that it's hard to give it one dimensional definition. That being said, let's take a social web app as an example. All the algorithms and architecture in the backend are the engineering aspect. The graphic design aspects (UI) with all the animations and slides are art. So is the UX. One won't work well in the market without the other.
Art and Egineering are not opposed. As Donald Knuth said, if we go back to Latin roots, we find ars, artis meaning "skill." and the corresponding Greek word was τεχνη, the root of both "technology" and "technique." (http://www.paulgraham.com/knuth.html)
> [...] if we go back to Latin roots, we find ars, artis meaning "skill." and the corresponding Greek word was τεχνη, the root of both "technology" and "technique."
That's a fun fact to know, but ancient word origins do not give any indication about the modern meaning of derived terms.
It might be the case that "art and engineering are not opposed", but this doesn't follow from their vaguely similar etymologies.
Art used to mean representational skill. But that was a couple of millennia ago, and culture has moved on a little since then. There are plenty of artists with exceptional representational skill but limited visual creativity or psychological insight. They don't get a lot of interest because they're more like cover bands than original talents.
I tend to think of software as a brain craft. It's certainly not an art in the usual cultural sense of the word. When it's done well it's more like very good carpentry or metalwork.
I little bit ago I wrote an article on that topic, here are my two words (would love to reignite the discussion)
[...]
The definition of Engineering as Wikipedia defines it:
Engineering is the application of scientific, economic, social, and practical knowledge in order to invent, design, build, maintain, research, and improve structures, machines, devices, systems, materials, and processes.
So based on these words the case is quite clear. Software development is engineering. We apply practical knowledge to invent, build, maintain, research, improve structures, machines, devices systems and processes. Our software applications.
The definition of Art as Wikipedia defines it:
Art is a diverse range of human activities and the products of those activities, usually involving imaginative or technical skill. In their most general form, these activities include the production of works of art, the criticism of art, the study of the history of art, and the aesthetic dissemination of art. [..] Architecture is often included as one of the visual arts; however, like the decorative arts, it involves the creation of objects where the practical considerations of use are essential
So again, we could say Software development is a product of an activity involving imaginative AND technical skills where the practical considerations of use are essential.
Is software development part of the decorative/visual arts?
In terms of art and by drawing the parallel to Architecture we could assume that a software developer has enough freedom to choose from a variety of foundations, building blocks. Developers influence the "Gestalt" of the final product and no two systems will look the same. Software development can be considered a unique form of art with intricate nuances that follow simple concepts we find in engineering.
[...]
I'd argue that it is far, far, far, far, far easier and takes far, far, far less skill to make a 1,000-line piece of code work than it does to make a 1,000-line short story 'work'.
If you are trying to say that your use of 'work' is the same as Amelius', then the burden of proof is on you; if not, then your comment is beside the point.
The act of creating software is a craft. Designing the architecture for software is what I'd call engineering, but there is still a lot of craft involved in most software architecture.
I don't think there is any art in it, unless the software you are building it supposed to be an artistic project. But that is not unique to software, painting itself is a craft, painting in a novel thought-provoking way is art.
Well-engineered software can possess some of the qualities that are esteemed in art: simplicity, balance, creativity.
Software is usually too purposeful to be art. I think a functional intent or purpose belies its designation as art. Creation of software is, however, a mixture of both art and engineering.
Agree. Software industry has become so huge the last 20 years that it's not enough to just say "Software." But I agree with you. If it's simple mobile app with eye-catching animations and cool buttons, that software leans more towards art. But if it requires complicated algorithms and AI like those in Stock Exchanges, then it leans more towards Engineering. But there is both Art and Engineering in almost all software.
Software is intended for both people and machines.
When you solve a technical problem using software, that's engineering. When you solve a human problem, that's art.
I think the OR should be replaces with AND. Obviously some software are more art or engineering than another, but almost all software are combination of both.
This is what happens in software. The code is the blueprint, the exact spec, and "building it" means running it through the compilation/deployment pipeline.
Software is a machine, but the main difference with other machines is not that you can't analyze it with math or can't approach it as classical engineering, is that it's not economically feasible to do so. The translation from the blueprint (the unambiguous, absolute and exact spec, the CODE) to the final product (the deployed working system) is "automatic" and basically free from material costs.
PS: And add to this the fact that most software is NOT "critical" (as in "if it fails in production people die").