|
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.
|
Now you highlight the other side, helping to complete the picture. I think you're absolutely right that we need engineering as well as art. What's more the best painters spent a lot of time on engineering. Maybe Leonardo could sketch a perfect circle, but many pioneering artists used "engineering" aids like the camera obscura.
The idea I take away from this is that you need to understand and appreciate both "scripting languages" and more "software engineering languages", and understand when to use each one. And more than the languages, you need to understand when you are "thinking out loud" when you're programming, and when you have figured out what you want to do, and build a rigorous, engineered implementation.