But I think you're missing a subtle aspect of developing arbitrarily good applications: You probably can't develop a truly great application one block at a time. Sure, you can add all the features of a truly great application one block at a time. But the devil is in the details (just like in music, art, etc.), and sometimes missing one spark of inspiration can make all the difference.

Google is great software. Microsoft Live search is a cheap knockoff with more features and flashier design and less of whatever it is that makes Google "great".

The iPod is great software. Zune is a cheap knockoff with more features and less of whatever it is that makes the iPod "great".

And those two "knockoff" examples were made after the original--they should have been able to copy the "great" aspect and one-up it, by throwing money at it. But somehow they failed. That's the subtle distinction between great software/art/music and mediocrity.

The Beatles made great music. Paul Revere and the Raiders made cheap knockoff songs with less of whatever it is that makes the Beatles "great".

jraines post sums up quite a bit of the process similarities, so I won't go into it.

Music is less objective than software--a bug is a bug, but a blue note might be on purpose and it might be the key to the song. So, it's not precisely the same. Knowing software works or doesn't might be easier than knowing if a melody is worth anything.

I think in all creative pursuits you can get very very good by consistently seeking to do better and gaining insight into what you do. If you're always thinking about the next layer of meaning and trying to stretch you'll achieve great things.

I just made the comparison in this blog post which hasn't garnered much yc interest: http://greendestinyonyc.blogspot.com/2007/08/creativity.html

The encapsulated idea might be the dominant part of a V-I cadence, which you can replace with an extended, embellished pattern that has basically the same function but is much more interesting. V->[I-ii-iii-IV-V/V-V]

    I-vi-ii-V-I
    I-vi-ii-[I-ii-iii-IV-V/V-V]-I

    [I-vii-I]-vi-ii-[I-ii-iii-IV-V/V-V]-I

(note that the vii should really be vii-diminished. The forum doesn't appear to support the little circle superscript.)

In code, the classical approach is akin to the waterfall method. Design it all up front. Build it with statically linked tools. Hire programmers like an orchestra, based on their ability to follow the score. The iterative approach is more like jazz. Write a little bit. Bounce it off other people. Write a little more. A conversation. Duck typed scripting languages are great for that.

And then there's interaction design. This is more like a band leader who 'gets' the audience. Or, at least, someone who the audience 'gets'. This is isn't working backwards from a tune or forwards from a set of building blocks. It's a bidirectional search.

On a more pragmatic level: it takes about 1000 hours of playing with any tool to become arbitrarily proficient. Another 1000 hours of playing with people to become arbitrarily 'good' (give or take a zero or so).

1. Both require long periods of focus to really get in the zone and be productive.

2. Progress is marked by stretches of frustration punctuated by "eureka" moments.

3. It helps to be around others with the same interests, be it Scandinavian metal or Ruby on Rails.

4. If you do the little things wrong, you make it harder for yourself at the more complex levels. Good habits are key.

5. Don't get too hung up on the tools in the beginning (ie overspending on guitars, amps, mixing equipment -- or switching development tools every time the next hot framework or dev kit comes out)

My advice to you is to persevere. Just like with programming, one day you will find that things which once seemed impossible are within your reach, and it's a very rewarding experience.

The main difference with composing is that you are usually writing a program for a real person to perform, not for a computer to execute. This means that writing music is less exacting, but can also be more subtle.

The other big difference is that you aren't usually writing music to solve an external problem. With music, you have to invent the problems you want to solve. You might say "I want to hold an F# in the alto line for 4 measures, while moving all the other voices in a chord progression that adheres to the following restrictions..." You just make up the conditions on your own. Software, in contrast, almost always solves a concrete, defineable problem (even if you don't know what that problem will be when you start coding).

With performing, the biggest difference is that it's real-time action and communication. You have to train physically in order to be good, and learning bad habits is disastrous. Code-reading and being good at using an editor are more analogous to music performance than software development in general. With writing code, it can be a good thing to write 1,000 lines of crap, if you learn enough not to make those mistakes again. Making mistakes while performing just leads to more mistakes in the future.

I tend to think more in terms of emotions I would like to express, but maybe that is insufficient.

that sounds familiar when you create an application for what people want! but I think its a totally different way of creation needing different sources of inspiration.

Yes.