I remember in the late '70's that when I was using a card punch and card reader to write FORTRAN programs, I sure _did_ need to design the program ahead of time. Because it took time to get the results back.
There is some truth to Graham's essay. I remember one contract I took back in the mid-'90's at an oceanographic institution. Great environment - folks starting to experiment with Linux, people mostly using LaTeX... I was using a combination of Perl, awk, sed and LaTeX on UNIX and Linux to get my work done. It worked because most programmers in sciences aren't much good unless they are actually schooled in those sciences - you need to know the application domain. Was my work "hacking"? Dunno - I tried to document it and design it. But really it was hacking. And fun.
I can't agree with the premise that a heavy emphasis on "software engineering" is not the way to go. I won't say who I last worked for, but quite frankly we produced crap. And it's because although we had many very good people, we had a culture of hacking. I also know of too many other companies, through contacts or acquaintances, that also produce crap when attached to a hacking ethos, but improve when starting to institute process.
I'd estimate that maybe the top 5% of programmers (and I am not arrogant enough to say that I am one of them) are good enough to "hack" and actually produce readable, maintainable, working code. This also applies to open-source. For everyone else you need process, and sometimes lots of it.
Generally, no, it's not art. Only your programming superstars can get away with that, and even then you don't always want to look at their code. Most of the time it is process and techniques.