Two Facts about Programming

In any project that you are a part of, you will do things that you have never done before

Because if you have done it before, you find your old solution and copy it. If you needed to tweak it after copying to get it to work - congratulations! You just made a new solution that wasn't there before.

This is why estimating how long it will do to implement some particular function in a computer program is so difficult. Programming, by its very nature, will always contain many unknown obstacles that will affect your estimate, usually making the task take longer than anticipated.

If you encounter tasks that tend to be very similar and require little thought, you are either confusing programming with configuration/boiler-plate code (alas hard to avoid), or you are lazy or a bad programmer. Recurring programming problems are solved by refactoring or making scripts that generate the program for you.

Any project will probably involve tasks that no one has ever done before, anywhere

Because if someone has done it before, you will try to find that someone and copy or buy their solution.  Sometimes the price is too high, but more often you will not choose that third party solution because it doesn't do exactly what you want, or it is of poor quality. Congratulations, you are about to implement something that no one has ever done before!

This is why estimates of incorporating third party solutions, or making a completely new solutions, always suffer so hard they're hardly worth the effort. Just start working and see how it goes.

Often the new ground you tread will just seem like a crappy for loop deep inside a crow's nest of tangled programming. You should take the time to look around you, at the vast landscape of code, all around, thousands of man-hours in the making, and realize that here is the apex of this particular mountain of source code. The only one of its kind and never more advanced than right now.

Part of being a good programmer is learning to accept and enjoy these two facts. It's an exciting ride!

Some Thoughts on Programming

During my life and career as a programmer, I have gradually adopted a pragmatic attitude towards software projects and my role in them. I expect every assignment to end up being something totally different from what was explained in the originally project specification. Also, at any given moment fundamental conditions for the work may radically change in relation to what they were a month or even week ago, and they may do so many times. This is to be expected of any normal software project.

I believe this because I see it happen constantly in projects I work in, but I have also figured out that there may be a logical reason for it. Here's what I think:

There is a good chance that every software project will contain elements, large or small, that no one has ever done before. Also, there will most likely be elements, large or small, in a software project that you partake in, that you have never done before.

The reason for this is one of the things that sets programming apart from other crafts: duplication. It's popular to compare programming with other vocations, such as architecture/house building. Most of these comparisons fall flat - creating a piece of software has little in common with building a house. You might compare it to the work of machine engineers, since a computer program can be seen as a kind of machine. Writing a program can be compared to making the blueprint for a machine (or collection of several machines working on a conveyor belt), making soda bottles or mowing the lawn.

But where machines need to be set up in a physical location, possibly needing adjustments to the blueprint to adapt to the environment it runs in, a software program lives in the memory of a computer, where it has all it needs, no more tangible than the thoughts in my brain as I am writing this text. And where a machine needs time to be physically set up, connecting parts that have been transported to the location where the machine is assembled, a software program, once written and ready for production, may be installed on a computer in minutes. If it is prepared for its platform, in the blink of an eye.

In a software project, the resulting product (putting aside project plans, minutiae, and other side effects deemed crucial to the workings of a successful project) is some source code that may be used to create a working piece of software on some selected platform. You need to make this source code (actual program code plus configuration data used by the program code) because you can't use existing software to do the task you need accomplished.

This may be because the software you need has been written by someone else, but requiring too high a purchase price - you believe you can create the same software yourself at a lower cost. Or maybe the software exists for Linux, but you are restricted to using Windows computers. Or maybe the software doesn't exist at all. I have personally dealt with mostly the last of these three possibilities. I believe the first one is rare, except for hobbyists, who often don't organise their work into projects.

Unless you're too mean to buy existing software (or, as is sometimes the case, have an irrational fear of using free software), there will be elements in your project that no one has done before, be it conditions of a new platform or a whole new software solution that the world has never seen. Certainly no member of the project has done it before. If they had, they would dig out their old source code, copy it, and then look for something else to do. If the software exists as free, open source software on the web, the software developer may well download and use it despite restrictions put by the employer, maybe changing some labels to disguise the true origin of the code.

The never-heard-of challenges of a new piece of software can often go deep into the low level. Sorting a list is a classical problem in computer sience, with many established solutions for different situations, but this project might need to sort a huge matrix with respect to other structures on some ad hoc-basis, without needing an aeon to complete. The developer needs to think up a solution for this with little help from the giants whose shoulders he thought he was standing on.

The current trend of development systems with short intervals between status updates, team programming etc may be well suited for handling this issue concerning the unknown that is inherent in all software development. I still feel that we could be humbler and more accepting towards the fact that we don't always know quite what we are doing, in life as in programming.

The 140 BPM Blues

The seasonal streaming event that used to take place every new year's eve at electro-music.com seems to have expanded into celebrating all turning points in our planet's position in relation to the sun. It started with the summer solstice event last year, and now we've just gone full circle - the Spring Equinox shoutcast event took place on the night that was 2010-03-20 - 2010-03-21, with 16 hours of great, disparate performances spread out over the globe. Check them out here: http://electro-music.com/forum/viewtopic.php?t=40217

I played a half hour set titled "The 140 BPM Blues", trying out some clip switching, looping and vocoding. And blues. Here it is.

VG-99

Got a VG-99 and a GK-3 the other day. Acronymn fun! Anyway, here's an image of a GK-3 mounted on a guitar:



That's not my cheap Squier strat, but you get the idea. The deal with the pickup that is wired to the control unit at the bottom here, is that it treats each string separately, sending six individual signals to the control unit and into a 13-pin connector. You can use a suitable cable to connect these 13 pins to an identical socket on a VG-99, which is capable of doing stuff with these signals that you may not have thought possible before.



That's the VG-99. What it does is take each signal and treat it, playing sounds based on Physical Modeling in one way or another, or detecting the pitch of each string and sending it as MIDI note data to whatever synthesizer you'd like. The models include a variety of electric and acoustic guitars, basses, banjos and sitars, and never-before-heard-of synthesizers. These synths don't work like a keyboard-triggered kind, they rather are excited in ways similar to the aforementioned guitar models, creating new kinds of sounds that I (in my admittedly G.A.S-enhanced excitement for a new piece of kit) am very excited about. Here is a test run I did with some synth sounds:

Knotwork

I've posted about this here and here.

It will be fun to see if this leads anywhere :)

Antimon On the "Air"

Wow, apparently I used to post to a blog here once! A lot of stuff has happened - I'm hanging out at electro-music.com, and I've participated in a couple of events, the most recent being streaming events on the summer solstice, the autumnal equinox, new year's eve, and "A Winter's Dream - an Evening of Ambient Music 2" a couple of weeks ago. The last event was the first where I felt I didn't lose track of what I was doing at some point in the performance. Fun!

Next up is a radio show that's sent on shoutcast at radio.electro-music.com. I'm calling it The Antimon Plays Some Doodles Show, and I'm going to be playing all tracks from an album called Doodles, that I've put up on Tunecore, which distributes stuff like this to online music stores, most notably iTunes. I did it mostly to get a kick out of seeing myself on iTunes I guess.

Two More Tunes

Posted this at Kontrollrummet and electro-music.com: Invulnerable and this at Kontrollrummet: Talon.

"Invulnerable" is an experimental thing that I enjoy listening to myself but I'm not sure if it really works outside my brain. The reception at Kontrollrummet was varied - some like it and some didn't like the quirky percussion.

"Talon" was writted yesterday while walking to work. I take a long route to and from work everyday that includes a 40 minute walk, during which first the chorus words and then the main bassline crept into my head in the morning. Having bad experiences in the past with great ideas in the morning that evaporate during the work day, I kept humming the tune to myself and did an attempt at score notes when I got to the office (I got the note pitches wrong but the timing was right). I managed to keep it in my brain until today, and recorded most of it before lunch. It's a simple pop tune.

The Modern Sport

Posted a new tune at Kontrollrummet.com (swedish forum for musicians) a while ago, called The Modern Sport. The responses were varied. I am starting to think that a lot of people don't enjoy monotony as much as I do. Though my reckless attitude towards recording techniques and polishing takes may have something to do with it.