The Artima Developer Community
Sponsored Link

Weblogs Forum
Writing Software is Like ... Writing

54 replies on 4 pages. Most recent reply: Mar 29, 2010 11:22 PM 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 | » ]
Florin Jurcovici

Posts: 66
Nickname: a0flj0
Registered: Feb, 2005

Re: Writing Software is Like ... Writing Posted: Apr 22, 2009 1:17 AM
Reply to this message Reply
Advertisement
> You can't give me 1 hour here and 2 hours there. I need
> longer spans of time to do the "development" (which THERE
> is a more appropriate word, but in software we don't take
> that word the same way we do in writing.) if you want a
> solid plot that will not fail and supporting subplots and
> good characters... I NEED DEVELOPMENT TIME!! LOTS OF IT
> (in span of time)!!

:D Seems to me you just need to run a PVM on your brain, and let development run on a backgorund thread.

Jokes aside:
1) with some training, you can get to use these one or two hours periods efficiently
2) IMO efficiency as a programmer has lots to do with architecture. An adequate architecture will allow you to work efficiently in pieces of one or two hours
3) Even if working in pieces of one or two hours is possible, it's tiring and not nearly as fun as coding something you like for straight twenty hours in one go

Florin Jurcovici

Posts: 66
Nickname: a0flj0
Registered: Feb, 2005

Re: Writing Software is Like ... Writing Posted: Apr 22, 2009 1:36 AM
Reply to this message Reply
Not quite. IMO it's a dangerous analogy.

Writers seldomly work in teams, programmers most often do. Even if they do, they work in teams of two - I never heard of a team of three. While there may be references fromm one book to another, there's no such things like function calls or object instantiation across books, one book building on another book before that other book is published.

My favorite analogy is with engineers. Programming is like bridge building, but with zero costs for the actual building, which is performed 99.99% automatically by the compiler, and all costs concentrated in the research and development phase. Research and development of any product is notoriously expensive and unpredictable, no matter if you build bridges or cars. Nevertheless, anybody not in IT expects research and development of software products to be cheap. They then get what they are willing to pay for.

Now, if customers consider us writers, they will think "a bad novel or newspaper article can't harm too much, so I won't be paying the best ppl to do the job, and still get away with it", rather than thinking "a bad design will for sure yield a broken product, so let's properly fund the research and development of the product, so at least I get something usable out of the whole expenditure".

Andrew McVeigh

Posts: 29
Nickname: 55548
Registered: May, 2008

Re: Writing Software is Like ... Writing Posted: Apr 22, 2009 1:50 AM
Reply to this message Reply
I think writing software is quite a lot like writing prose. The key is to do it continuously over a number of years to find your own "voice". This is something that prose writers spend a great deal of time seeking out. It also explains why you have to program quite a lot and fairly consistently to get "good at it". Writers find this effect also.

some interesting analogies:
- the high level architecture of a system is like a plot synopsis in a story
- programming has unit tests which can reestablish context quickly (sort of like an automated consistency checker?), which helps when work is divided into 1-2hr chunks
- both mediums offer a level of reuse -- in software we can reuse existing services or classes/functions. in prose, we can allude to other stories, or even write a sequel. in both, the original and the reuse need to be consistent to "work". If the original presents a particular story or context and the sequel wants to subvert or alter this, it has to be very clever (c.f. the Wicked musical versus the wizard of oz). And even then it may not completely work.
- contradictions in both mediums cause programs. these are bugs in software and plot holes/internal inconsistencies in writing.

However, I don't think it's the whole picture. Like any analogy it breaks down at points, colored by the characteristics of the 2 different mediums:

- programming has levels of abstraction not present in writing. if you don't program a class well, but it does the job and presents a suitable interface, noone will really care. but prose is scrutinised from page 1 to page N.
- programming has many different paradigms which greatly effect "writing style". perhaps prose varies as much, but I'm not expert enough in prose to know.

Cheers,
Andrew

John Wellbelove

Posts: 72
Nickname: garibaldi
Registered: Mar, 2008

Re: Writing Software is Like ... Writing Posted: Apr 22, 2009 2:50 AM
Reply to this message Reply
I think programming can also be seen as a craft, as in say a cabinet maker. The customer can specify what the piece of furniture must do (store my CDs) but it is up to the skill and experience of the cabinet maker to design and build it. Another may come up with a better or worse design, or maybe even just different. The basic skills should be common among the craftsmen, but the application of them is liable to be variable due to their aptitude and/or experience.

Steve Merrick

Posts: 9
Nickname: erisian
Registered: Mar, 2008

Re: Writing Software is Like ... Writing Posted: Apr 22, 2009 2:54 AM
Reply to this message Reply
This reminds me of Richard Gabriel's "Writing Broadside" - http://www.dreamsongs.com/RPGWritingBroadside.html

Of course we're writers. What else could we be?

Joao Pedrosa

Posts: 114
Nickname: dewd
Registered: Dec, 2005

Re: Writing Software is Like ... Writing Posted: Apr 22, 2009 3:31 AM
Reply to this message Reply
It has to be a good analogy, I am told. ;-)

It is strange though in that as we gain experience, we learn to appreciate more of the good things we see even if what we were doing was not going to directly affect the bottom line of the project we were applying ourselves to.

I just fixed a little bug in my code that I wrote a while ago. The bug was not being triggered because of a coincidence that the loop would find the key in the first try so the loop was not necessary for all of the code that depended on it... It was like this, in Javascript:

for(var i = 0; this.gut.rows.length; i++){
if(this.gut.rows[pk]){
return etc;
}
}

Sure the code was ugly. When I first wrote it I was not as acquainted with JavaScript and I "invented" the "gut design pattern" to hold the "private" data of the object leaving the methods all the namespace they could require in the public part of the class. ;-) That was just a few lines out of thousands of them and I even moved from JavaScript framework to another like from ExtJS, to jQuery and then to Prototype. As a matter of fact, what prompted me to edit these files was another conversion that I was trying to make, to move to the YUI 3 JavaScript library. In the process I found motivation to clean up some of the code, even though I ended up forgoing YUI 3 as my usage of it was not to the letter and I happened into some issues with it, not considering that YUI 3 is still in alpha state, albeit being used by some Yahoo! sites.

Another little story was when a week ago, I was quite excited about running JavaScript on the server-side with the Google JavaScript engine (V8). It allowed me to experiment with JavaScript without being stuck with the browser. I tried to create some OOP example with 3 classes, one inheriting the other, and calling "super()" from the constructors and from a method.

Once I got that working, I had the idea of benchmarking it against Ruby, Python and PHP. I then set to create similar programs in them and in the process I learned some more about inheritance in Python and PHP. As a curiosity, the benchmark showed JavaScript being over 10 times faster at that benchmark, and upon reading the design behind Google's V8, I could understand that they have further optimized things like properties and even compile JavaScript to machine code!

With all of that said, one more thing that surprises me is when I see lots of old code that I wrote and think "how did I do that?"

And as most of you know, once a program is written, it can run indefinitely, which is the biggest wonder of programming, if I may say so.

That and being able to write, however non-native English speaking one is. ;-)

Cheers.

Lon Binder

Posts: 1
Nickname: lonb
Registered: Apr, 2009

Re: Writing Software is Like ... Writing Posted: Apr 22, 2009 7:28 AM
Reply to this message Reply
Bruce - First of all, let me say that writing to you is an honor, your book Thinking in Java, is the only programming book I ever recommend to anyone for any language.

Second, I generally agree, but I have usually taken the analogy to a somewhat more specific level and in a slight different vector. I think the better analogue, that most business people seem to understand, is that Developers that Write Software are Like Lawyers that Write Contracts.

Yes, any lawyer can write a contract. For the same purposes, let's say employment agreements, some attorneys will produce one page agreements (nice and concise), others will produce 40 pages bibles (lengthy and detailed). There is no guide in law that says one is any better than the other. In the end, the usage of the contract (particularly in worse case scenarios) is what truly draws out which is the better agreement.

Moreover, it seems that contract writing logic is very similar to functional programming. It is important to try to think out scenarios (cover bases), write somewhat defensively, and segment logic into natural grouping.

It always amazes me that lawyers and programmers have so much in common, but can't seem to talk to each other.

Sean McQuillan

Posts: 1
Nickname: seanmcq
Registered: Apr, 2009

Re: Writing Software is Like ... Writing Posted: Apr 22, 2009 9:26 AM
Reply to this message Reply
I was on this analogy for a while, and I generally am fond of it, but there is a problem that you glossed over.

Writers, at least of the fiction variety, tend to work by themselves. Software developers, tend to be more productive when working on small close-nit teams.

Harrison Ainsworth

Posts: 57
Nickname: hxa7241
Registered: Apr, 2005

Writing Software is NOT Like Writing Posted: Apr 22, 2009 9:40 AM
Reply to this message Reply
The real causes of disappointment are, on the one side: industrial and educational immaturity (only to be expected at this stage), and on the other: no substantial guide or reference for expectation.

Veering off into presenting software development as like writing novels seems like heading in a very wrong direction. I see that the purpose is for simple communication, but it is no better founded than a fairy-story. That just cannot be satisfactory for any serious discipline or enterprise.

There is still a confusion in how to think about software. But there are good, substantial, well-established models: a good overall one being the building industry. Unfortunately, almost no-one inside software has bothered to look outside. You need only glance through references in the most respected 'software engineering' publications: perhaps one or two, but usually zero, point to even basic external knowledge.

There is much to say on the subject (which I have begun to say elsewhere). But it starts with realising that software development, as an overall 'enterprise' or industrial pursuit, *contains* engineering, but it also contains other things too.

It is easy to pick some feature or other and point out some anecdotal difference. But if you then claim software engineering is therefore not engineering, and must be something completely else, something weird, unknown, new, etc., you will have made no progress at all.

Software engineering has features that are obviously engineering. You need only look at books on general engineering design (such as Pahl Beitz) to see a very similar process. Or consider your own work when putting together well-defined parts according to their required relationships.

Ultimately, software engineering is engineering because its basis is determinate knowledge: it assembles pieces by understanding their properties, and uses experiment to fill gaps in understanding.

An 'engineering' 'model' of understanding that part of software development can encompass the differences. And now, since the model brings the backing of a substantial body of thought, there *is* a possible way to make progress.

w work

Posts: 2
Nickname: workgold
Registered: Apr, 2009

Re: Writing Software is Like ... Writing Posted: Apr 22, 2009 10:03 AM
Reply to this message Reply
Is programming a science or art?
If Alan Watts answered:
It is a philosophy.
Why are so many programmers fired by CEOs?

Level 1: Western
Universe as monarchy.
quote:
For if Christianity is a religion ...
they are based on the idea of man's obedient response
to a divine revelation.
Analogy:
CEO is the monarch. The programmer is the commander.
The computer is the soldier (lowest footsoldier)
Bad results result in monarch firing commander (see footnote)
Level 2: Hindu
quote:
God is the actor of the world as an actor of a stage play
---the actor who is playing all the parts at once
UML = Unified Modeling Language (multiple actors)
www.agilemodeling.com/artifacts/useCaseDiagram.htm
Analogy:
All are part of the universe. Different masks are different
views or encapsulations.
Level 3: Chinese Tao
The world is an organism has no boss, and even no actor.
principle of organic growth
Analogy:
meta-metaclass, aspect oriented. strategy pattern is pattern of
patterns
Application:
Body and Health.
Western Hierarchy: head controls the spine which controls the feet.
Hindu Concurrency: feet walks and head thinks of dancing
Chinese organic pattern: Tao Te Ching. Tao is the Way.
How to classify programming languages?
Java = Western Hierarchy (single inheritance)
Scala = Hindu Concurrency
Python = Chinese Organic (glue language)

quote:
Our social way of bringing up children is to make them
concentrate on the bits and to ignore the totality.
We point at things, give them names, and say, "Look at that."
Children point out backgrounds, and the
shape of spaces between things, and say, "What's that?"
footnote: computer as insubordinate soldier
it cannot be fired; it is easy to fire the programmer
it 'soldiers'; it obeys the EXACT COMMAND, not the intent.
History:
King of England is head of Church of England
Single Ruler, Roman Caesar, military ruler becomes a god.

Engineering Example: Three Mile Island Nuclear Accident
Too many alarms tripped; buffer overflow;
operators got dated and useless inaccurate sensor data.
No intelligence in reporting system.
from workgold
http://www.artima.com/forums/post.jsp?forum=106&thread=255898&reply=true

Matt Doar

Posts: 9
Nickname: mdoar
Registered: Feb, 2004

Re: Writing is Like Writing Software Posted: Apr 22, 2009 10:09 AM
Reply to this message Reply
A lot of technical documentation would be better if it were written like programs!

~Matt

Jeff Fry

Posts: 1
Nickname: jfry
Registered: Apr, 2009

Re: Writing Software is Like ... Writing Posted: Apr 22, 2009 10:20 AM
Reply to this message Reply
Nice post. Reminds me of similar writing on Software Artists http://chrismcmahonsblog.blogspot.com/2008_05_01_archive.html

N D

Posts: 1
Nickname: artimguest
Registered: Apr, 2009

Re: Writing Software is Like ... Writing Posted: Apr 22, 2009 11:10 AM
Reply to this message Reply
yes, this inspiring discussion is needed, more humanity right, right, programmers are people..

Kay Schluehr

Posts: 302
Nickname: schluehk
Registered: Jan, 2005

Re: Writing Software is Like ... Writing Posted: Apr 22, 2009 12:52 PM
Reply to this message Reply
Nooooooooooooooo!

Programming is such a new culture technique that we naturally consider it in terms of older ones: science, engineering, craft, story telling etc. We adapt programming s.t. it becomes familiar to what we know, what we've learned in school, what is our alphanumeric cultural heritage. Even today we just write programs as texts, as linear sequences of symbols. And now comes you and says: that's it. This very specific adaption of programming is what we really do.

What I'd like to preserve is the radical difference of programming and that it originates from the bit and not from the sound of the spoken word and the linear organization of symbols. It's mostly writing today but not limited to it and writing doesn't capture its essence neither does source code. We are lacking an existential and phenomenological account of what programming is in its own right. But so what? The 21st century will give birth to a philosopher who will finally get it - at least I hope so.

Chris L

Posts: 1
Nickname: cnlwsu
Registered: Apr, 2009

Re: Writing Software is Like ... Writing Posted: Apr 22, 2009 1:03 PM
Reply to this message Reply
I think... Dijkstra would turn in his grave if he read this and the comments...

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-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use