The Artima Developer Community
Sponsored Link

Weblogs Forum
Writing Software is Like ... Writing

54 replies on 4 pages. Most recent reply: Mar 30, 2010 2:22 AM by Florin Jurcovici

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 54 replies on 4 pages [ « | 1 2 3 4 | » ]
Vincent O'Sullivan

Posts: 724
Nickname: vincent
Registered: Nov, 2002

Re: Writing Software is Like ... Writing Posted: Apr 23, 2009 5:38 AM
Reply to this message Reply
Advertisement
Creating analogies is like picking apples. Or is it? Only if I then go on to explain what the similarities and differences are. In which case, I would have been better off just describing what the original item is, rather than how it compares to some arbitrary other idea.

Creating analogies is a symptom of an inability to describe something at a level understood by the intended audience. Time spent on describing the analogy is time wasted that could have been spent on properly describing the original.

Andrew McVeigh

Posts: 29
Nickname: 55548
Registered: May, 2008

Re: Writing Software is Like ... Writing Posted: Apr 23, 2009 6:49 AM
Reply to this message Reply
> I think... Dijkstra would turn in his grave if he read
> this and the comments...

possibly, but other very prominent computer scientists would generally agree with the notion that programming computers is largely a human-centered exercise in literature: http://www-cs-faculty.stanford.edu/~knuth/lp.html

"The main idea is to treat a program as a piece of literature, addressed to human beings rather than to a computer"

Florin Jurcovici

Posts: 66
Nickname: a0flj0
Registered: Feb, 2005

Re: Writing Software is Like ... Writing Posted: Apr 23, 2009 1:30 PM
Reply to this message Reply
> possibly, but other very prominent computer scientists
> would generally agree with the notion that programming
> computers is largely a human-centered exercise in
> literature:
> http://www-cs-faculty.stanford.edu/~knuth/lp.html

I would argue that literate programming never caught on. What has made it into the mainstream is javadoc, sandcastle and doxygen. But these tools tack documentation on code, rather than making coding an exercise in literature. It's still writing code _then_ documenting, rather than writing code _as_ documentation, and more often than not it's just writing code without documentation. Which is IMO probably what works best, since cweb didn't take over more traditional IDEs. Which (at least for me) means that writing code as literature probably doesn't work.

Sculptors, painters or musicians work very much more like programmers. They do something, but they don't care to explain to others why they did it in a particular way, or how they did it, or how it's supposed to be. They all use specific techniques and rules - art is a craft to a larger extent than some may think. Some sculptures/paintings/songs are good, others are bad. But there's nothing more in common among all these activties (sculpture/painting/music/writing/programming) than creative effort. But engineering a new type of bridge or architecting a new skyscraper is also a creative activity, and runs pretty much the same way. So IMO programming is as much like writing as it is like engineering or painting. Or choreography, for that matter (web services reminded me of that one).

Cameron Purdy

Posts: 186
Nickname: cpurdy
Registered: Dec, 2004

Re: Writing Software is Like ... Writing Posted: Apr 23, 2009 5:13 PM
Reply to this message Reply
> Wasn't that why COBOL was invented? To make programming
> like regular story writing, that any fool (well, manager)
> could follow? How did that work out?

Unfortunately, judging by all the COBOL code, it worked out far too well! ;-)

Peace,

Cameron Purdy
http://www.oracle.com/technology/products/coherence/index.html

James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Writing Software is Like ... Writing Posted: Apr 24, 2009 9:22 AM
Reply to this message Reply
> Creating analogies is like picking apples. Or is it?
> Only if I then go on to explain what the similarities and
> d differences are. In which case, I would have been
> better off just describing what the original item is,
> rather than how it compares to some arbitrary other idea.
>
> Creating analogies is a symptom of an inability to
> describe something at a level understood by the intended
> audience. Time spent on describing the analogy is time
> wasted that could have been spent on properly describing
> the original.

I don't agree with this. A good analogy can help people get the gist of an idea much more quickly by relating it to something that they are already familiar with. This is especially the case for bottom-up learners (like myself) who struggle with long elaborate descriptions prior to having a working knowledge of the concept.

The biggest problem with analogies is that many people don't really understand what an analogy is and focus on the details of the analogy.

Of course a poor analogy is not worth anything and creates confusion.

Steve Merrick

Posts: 9
Nickname: erisian
Registered: Mar, 2008

Re: Writing Software is Like ... Writing Posted: Apr 24, 2009 1:14 PM
Reply to this message Reply
> Creating analogies is a symptom of an inability to describe something at a level understood by the intended audience.

I strongly disagree. An analogy is saying "consider this, which is a lot like the thing I'm trying to describe to you". This is very similar to metaphor, which is fundamental to human understanding, and to extending it to cover new things. Google George Lakoff, or buy "Metaphors we live by", for more information. Humans learn well by example, by analogies and by stories too. Remember the parable of the Good Samaritan? ... See?

robert young

Posts: 361
Nickname: funbunny
Registered: Sep, 2003

Re: Writing Software is Like ... Writing Posted: Apr 24, 2009 2:44 PM
Reply to this message Reply
> Creating analogies is a symptom of an inability to
> describe something at a level understood by the intended
> audience.

Just hope that you never have to take this:
http://en.wikipedia.org/wiki/Miller_Analogies_Test

Tore Knabe

Posts: 1
Nickname: faikus
Registered: Apr, 2009

Re: Writing Software is Like ... Writing Posted: Apr 26, 2009 12:18 PM
Reply to this message Reply
Interesting article. However, from reading the title I expected something different. I was hoping to learn how to apply my software development skills to improve my writing. I even expected to find some analogy between your article and a computer program. Unfortunately you do not go into the transferability of skills, but concentrate on explaining to non-programmers why there are so vastly different quality levels among us.

Since you are an experienced programmer and writer, I am still interested in hearing how far you see this analogy go. Did being a programmer help you write your books? Or have you been a writer first? What programming principles apply to writing?

Harrison Ainsworth

Posts: 57
Nickname: hxa7241
Registered: Apr, 2005

Writing Software is NOT Like Writing Posted: Apr 30, 2009 1:40 PM
Reply to this message Reply
> "The main idea is to treat a program as a piece of literature, addressed to human beings rather than to a computer"

This is commonly accepted, but it goes too far.

There is a simple argument to disprove its primacy: a program with functionality but no human-readable structure can be useful software, but a program with no functionality but good human-readable structure is not really software at all.

The 'representational structure' of software is valuable, but not essential. -- It is only there to assist the engineering process, but it doesn't constitute the product.

Ra Rue

Posts: 1
Nickname: rarue
Registered: Apr, 2009

Re: Writing Software is Like ... Writing Posted: Apr 30, 2009 5:35 PM
Reply to this message Reply
Excellent observations.

While I haven't ever come up with this concrete analogy between programming and writing, I have many times acted as though the analogy existed.

When interviewing new programmers to work on a team, I am more apt to move quickly past the benchmark tests of degrees or certifications into two more important criteria:

(1) Explain some of your earlier work, what was great about it, why you liked it, etc. The correct answer is not My Earlier Fantastic Work To Which Knuth Would Have Praised but rather How Effectively Do I Communicate To You.

(2) Show me a sample of your work. Just as an earlier court could not provide a precise definition of obscenity but "knew it when I see it", I know good coding when I see it.

The second point leads naturally into what is often needed in programmers - clarity.

Clear code is not just something elegant to be admired. It's damned near a requirement for code that can be read and understood and maintained by someone else in the future. And, if you notice, there's a lot of code in that category these days and there's a lot of need for programmers that can deal with it and prevent future code from rotting before its time.

Bruce Eckel

Posts: 875
Nickname: beckel
Registered: Jun, 2003

Re: Writing Software is NOT Like Writing Posted: May 2, 2009 2:36 PM
Reply to this message Reply
> > "The main idea is to treat a program as a piece of
> literature, addressed to human beings rather than to a
> computer"
>
> This is commonly accepted, but it goes too far.
>
> There is a simple argument to disprove its primacy: a
> program with functionality but no human-readable structure
> can be useful software, but a program with no
> functionality but good human-readable structure is not
> really software at all.
>
> The 'representational structure' of software is valuable,
> but not essential. -- It is only there to assist the
> engineering process, but it doesn't constitute the product.

Both of these arguments are problematic because they each declare that it is an either/or premise. The first says that a computer program is addressed only to human beings, the second says that it is addressed only to the computer. I think that "useful software" must be addressed to both humans and computers. In particular, I don't think that unreadable software can be useful, because it cannot be reviewed, modified, and improved. Indeed, because it cannot be reviewed it can't be verified -- you don't know that it actually works. You might argue that the tests verify that it works, but what happens if a test fails? You can't read the software, so you can't fix it.

Clearly, the machine must "understand" it, but if humans can't understand it, it is not useful software from my perspective.

And to clarify the discussion, I was talking about the process of software development being like the process of writing -- in order to explain why it is so difficult to predict and control.

Harrison Ainsworth

Posts: 57
Nickname: hxa7241
Registered: Apr, 2005

Re: Writing Software is NOT Like Writing Posted: May 3, 2009 8:59 AM
Reply to this message Reply
> Both of these arguments are problematic because they each declare that it is an either/or premise.

I say only that the *relative* importance is commonly wrong.

> the second says that it is addressed only to the computer

I did not say that. I deny only the *primacy* of the common assumption, but I say that it (the representational structure) is valuable.

chris webster

Posts: 1
Nickname: cmhw
Registered: May, 2009

Re: Writing Software is Like ... Writing Posted: May 7, 2009 6:01 AM
Reply to this message Reply
Interesting idea, but as an experienced programmer and qualified translator, I would suggest that programming is more like translation than creative writing. It is to some extent a creative craft, perhaps even an art, but it is always related to the original thoughts of the "authors" of the original requirement, even if the authors might sometimes also be the developers themselves. People do not generate their ideas in computer code, they express them in natural language, then translate them into computer code.

When you start a new software project, you typically have some business users who have particular goals for their systemn, which they express in natural language. As the project progresses, you start to translate their requirements from their own business-oriented natural language into a variety of software-oriented languages - user stories, UML, DSLs, Java etc. In the end, if you're lucky, you have a complete representation of their natural language requirements expressed in computer code.

Of course, the idioms and grammar of software languages are very different - much less vocabulary to learn for one thing! And this is also where the "engineering" aspect of software comes in - you have to learn certain techniques that are generally applicable, based on an understanding of how computers work, as well as the detailed nuances of each target language or platform.

If we compare the process of writing software with natural language translation, we find that lots of people might speak, say, German and English. A smaller number can read, understand and translate ordinary texts from one language to the other. And an even smaller number can translate semantically complex texts like legal documents, or highly stylised artistic content like poetry, competently from one language to the other.

Finally, you have real expert translators who are able to produce, say, an English translation of Goethe's poetry that not only captures the literal meaning of Goethe's words, but manages to replicate a sense of the rhythm, metre and texture of the original language in their translations. The goal of a translator is to produce a text that conveys all these elements of the original as far as possible, but reads as if it had originally been written in the target language.

Similarly, an expert (and lucky!) programmer can represent all the literal content and subtle nuances of the original requirements, but can also do so in a way that is idiomatic and tailored to the target language, as if those requirements had originally been written in, say, Java. Sure, all computer languages do basically the same thing, just like human languages, but they do so in different ways, so your program will do the same thing, whichever language it's written in, but you will express your programs differently in Java, Python, C, or even COBOL if you're a computer classicist!

But all the best science, engineering and of course art is fundamentally a creative endeavour, including software development.

Florin Jurcovici

Posts: 66
Nickname: a0flj0
Registered: Feb, 2005

Writing Software is Like Engineering. Ditto. Posted: May 15, 2009 6:10 AM
Reply to this message Reply
> Interesting idea, but as an experienced programmer and
> qualified translator, I would suggest that programming is
> more like translation than creative writing.

I find your analogy better than creative writing, but still not covering how programming really is. IMO, it is effectively a translation of what people want into what a machine can do. But in the process you have to do much more than just translate.

Usually when ppl come to you do write them a program, they are mostly aware of the problem, not of the solution, and if they envision a solution at all it's usually a wrong one. You have to help them build a solution, formulate the solution in some language they can understand, then translate the solution into something that the machine can understand. Translation covers only part of the process.

Some will probably argue that helping the ppl with the problem to define a solution is not actually the programmer's job. IME that's what consultants are paid for, not for the actual programming. And that's what most freelancers do, with more or less success. Therefore, in my world this work is also programming work, even if it doesn't involve writing code.

But if you look at the problem this way, programming starts to look a lot like the initial phase of architecting and engineering a new building. You have an intense communication process with the customer, you make proposals which may or may not be accepted by the customer, you validate accepted proposals on a technical level, and you only have an accepted building plan after all this is over. The main difference between programming and civil engineering is that in civil engineering the big costs happen after this process is finished, whereas in programming the actual building of the product from source code is extremely cheap. Unfortunately, ppl outside IT often think of programming as the process of actually building the building, rather than designing it. A pretty small program, implementing a particular document workflow for an enterprise, for example, has the complexity of a not so small building. But most often customers are not willing to pay as much for the programm and wait as long as they are for the plans for a similarly complex building. Which puts cost and time constraints on programmers which architects and civil engineers don't have. This is all there is, IMO, related to how software development is. However, IMO it is essentially an engineering discipline, which obeys the same rules as any other engineering discipline.

What makes it more attractive for some people than just some engineering is IMO not some fundamental difference, or the fact that you get to do something so much more challenging, but what makes a computer a very interesting toy for most human beings. You get to play with it all the day, and do something similar to what only a fraction of civil or mechanical engineers do: create someting. The people paying you are paying a lot less than if you'd do the same creational work in another domain, but that's OK, since you probably wouldn't be good enough to design skyscrapers or luxury cars or industrial robots anyway. Besides, the customer doesn't mind if you have him paying for mostly the same code over and over again, and just slightly change it, since he can't understand anything of what you do. And also, since you're cheap, compared to your counterparts in other domains, the customer has no problem coming up with new and changed requirements all the time. Which makes the type of quality assurance work performed in other domains impossible.

Then there are some aspects related to return on investment. You create a program, and this program is supposed to earn money for the one paying for it. In case of a building it's very easy to compute the ROI over a period of time, if you rent it out. In case of a mining machine, you can compute the ROI based on how much ore it extracts in a given time period. In case of software, it's much more difficult. Usually software is done to solve a problem, so the ROI could be calculated based on the economies it allows. But the problems most often solved are not easily estimatable in terms of costs. Therefore I'm sure most of the ppl reading this have seen several projects which were halted even if they would have been beneficial, and many other projects which were done only to be dumped some time after finish because the cost of using the resulting software was bigger than the benefits they created. Which probably explains the big project failure rate in software development, when compared to civil engineering or machinery development.

Which reminds me of something: somebody said a long time ago that if civil engineers built houses the way programmers build programs, the first bird to come along would be the end of civilization. Which is a perfectly valid statement, as long as programmers need to do plans for something with only a fraction of the money engineers get for making the plans of something similarly complex. Most of the times, there is no way we can do the same amount of formal validation of our work as other engineers do, with the money we get.

Petr Vasilev

Posts: 1
Nickname: yonyonson
Registered: Jun, 2009

Re: Writing Software is Like ... Writing Posted: Jun 7, 2009 11:16 AM
Reply to this message Reply
Hi,

I'd like to translate this article to Russian and publish it on my blog and habrahabr.ru website (one of notable Russian IT communities).
Indeed, I'm preserving links to original article and author.
Can it be done?

Best regards,
Petr

Flat View: This topic has 54 replies on 4 pages [ « | 1  2  3  4 | » ]
Topic: Self-bounding generics Previous Topic   Next Topic Topic: Heron Tackles the WideFinder Challenge


Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us