There's another side to that coin. Computer languages are so expressive and powerful that you always have several different ways to accomplish the same thing. It's easy to know a language inside out and still turn out what is derisively known as "baroque" code. (I have first hand experience).
But if you use all the nuances and power of the language, and produce code that's just like a-ringin' a bell -- take a bow, you're writing elegantly.
And like with other creative processes, attempts to regiment the writing of software tend to produce mundane code. Imagine following a list of guidelines while writing a novel. What would you get but a dull, boring tome? Do you think the inspired prose of a Vikram Seth or a Dom Moraes or an Amrita Pritam came from The Cookbook of Creative Writing (TM)?
Yet a whole slew of people work to stifle creativity in software. They seek to cloak software design in a fog of regulations and guidelines. These folks share two characteristics. One: they never actually write any software. Two: a god-given talent to use a hundred words to say what the rest of us would manage in ten. (Or, preferably, not say at all).
For two years in the mid-80s, I watched a group of these people first-hand. Their mandate was to consider software design and produce a computer-based model of it. Why was this desirable? I have no idea, but the people in this group -- they called themselves software engineers -- went at it like it was earth-shatteringly important.
The popular notion among them was that software design was like a waterfall. (Yes). Thus there were some who studied the "upstream" part of the process. Naturally, others studied the "downstream". Not content with that much, others decided that the "up-upstream" was where their interests lay. Naturally, this spawned the "down-upstream" people.
If you think it didn't stop there, you're right. If you're also asking "What does it all mean anyway?", the answer is "nothing."
But they were paid well. And they turned out documents by the gross. For software engineers -- and these were some of the best known -- are adept at turning out documents. At writing about writing software.
They didn't, however, write any software. In the eight years this project lasted, it produced one software product of note. That was the effort of a team of four who held a healthy, barely secret, contempt for their colleagues. Following no particular rules -- certainly none that the documents contained -- they took five months to turn out a robust, useful, even elegant piece of software.
A lesson for the "up-upstream"-ers? Hardly.
In the '90s and later, we've been plagued by a whole new field of play for these guys. It's called ISO 9001, and its faithful will tell you it aims to improve the quality of software. (All software is poor quality, didn't you know?) To persuade you, they produce lots and lots of -- you guessed it -- documents.
Yes, if ISO 9001 is characterized by just one thing, that would have to be the kilograms of documents it generates. They come complete with official looking numbers and designations and warnings, so you start thinking they say something worthwhile.
Like one that I have, "Guidelines for the application of ISO 9001 to the development, supply and maintenance of software." It begins with this vital announcement:
- Use of the masculine gender in this Guideline is not meant to exclude the feminine gender where applied to persons.
As any writer of software will tell you, he -- without meaning to exclude the feminine gender where applied to persons -- worries about exactly this while doing his -- without meaning to exclude the feminine gender where applied to persons -- job.
And what's inside this document? Endless lists of points about writing code. Then you read them.
What, for example, should you keep in mind while making copies of your software?
Paragraph 18.104.22.168 (a) has the answer: "the number of copies of each software item."
What, for another example, should a "maintenance plan" for your software include?
Paragraph 5.8.2 (d) has the answer: "Maintenance activities."
24 pages of this stuff. The waterfall guys would salivate. (Or maybe they wrote this).
But you, you would do well to wonder: why isn't there an ISO 9001 for creative writing?