But today I got an email that was different but it struck a chord…

I’ve had this blog for a while now but it’s just sat here languid, not doing much except to be the target of random other experiments such as posting photos from my iPhone using Shozu.

Mark’s email invited me to join his blogging course and all I had to do was add this:

And so the experiment begins… the code has been added and next I’ll notify Mark’s website that I’ve added the code and we’ll see what transpires.

Keep watching this blog for updates..

Since it is a personal blog, I guess I should tell you about myself.

I have always wanted to work with computers since reading Science Fiction by the likes of Asimov and Arthur C Clarke but when they showed me punch cards at high school I was somewhat disappointed and looked for another career path.

After a short stint in the Royal Australian Air Force, I was discharged and offered retraining in whatever area I chose. Computers had come a long way in just a few short years so my choice was obvious.

My first job was interfacing satellite receivers and other hardware with HP mini computers for a small Perth company called Qubit making good in Aldershot, England, and I was fortunate enough to join the maiden voyage of our system from Postmouth to Spain for British Telecom.

Not only do I enjoy plying my craft, I also like to conjure up new ideas and make them a reality.

For me there is nothing more pleasing and entertaining than taking a concept and making it into a computer program. There is something especially fulfilling about writing software that does something and then watching it go through its paces.

But there are many things wrong with the software industry, and often they are not that difficult to correct.

Unfortunately, we developers are seen as 21st century alchemists; we can create something out of thin air!

And because there are no raw materials to speak of, the layperson must be forgiven for thinking that we simply spend our time tapping at a few keys on the keyboard to punch out this majestic software program that perfectly suits their needs.

Nothing could be further from the truth…

We think about the client’s requirements, we surf the ‘Net looking for similar products, or suitable source code, or perhaps something else that resembles what we are trying to build.

And then we collect and collate this information and then reconstitute it into something meaningful that resembles what the client was thinking about.

Simple in principle, but in practice it requires a bit more effort.

Fortunately, most of the programmers I know absolutely love their craft and to them the thought of spending hours in front of a keyboard, hammering out Google search requests, and incorporating their findings into this current piece of art (for aren’t we all artists inside?) is nothing short of total bliss.

The fact that people are willing to pay for these services, to many of us, is icing on the cake. Mmmm, icing…

The rub comes when we find what looks like a link to the information we require only to find out that it isn’t quite what we wanted but is damn interesting nonetheless.

Time passes…

And suddenly, an unrelated piece of information has taken us off on some new tangent; a flight of fancy about some new tool or add-in or feature that we just can wait to use in our next product or development project.

I found something like this just this week: Ruport – a Ruby on Rails reporting tool which is not only relatively simple to use but can produce the sort of reports we only dreamed of… unless we were writing an Access database application… now that’s a reporting tool!

Crystal Reports could only dream of being a replacement for Access reports, but apparently Jasper Reports came close… but I digress… so where was I…???…

Oh yeah, building software – so to build great software requires a fairly simple formula: gather the requirements, build the program, test the program and deliver the program – roughly in that order.

With this in mind, we cost up the project and present it to the client who loves it and can’t wait to get started.

But sometimes things don’t always go as planned – that new add-in you thought would be perfect here and thought would only take a few hours to research has now taken most of the day and the documentation, well, frankly, sucks! Time passes…

So now the project is behind schedule and the deadline is looming fast and you prepare for the “whooshing sound that deadlines make as they go whizzing past” to quote Douglas Adams.

Sadly, in order to meet this deadline and keep all the projects on track, something’s got to give, and the primary targets are (a) developer’s free time by way of “all-nighters” to bring the project in on time, or (b) quality in terms of the degree of testing that is carried out before delivery.

We see this far more often that we would like and its all too easy to issue service packs in this day of Internet connectivity but below the surface of this online update mania lies a more disconcerting issue.

In days of old, a computer was set up by someone suitably qualified, and not someone’s 14 year old nephew who is a killer at Halo, and was left relatively untouched.

When something went wrong in your program you could figure out where to look because the only moving target was your code base.

These days there is a critical download to patch the critical download you got this morning because someone mispelt the name of server where the next update is coming from….!!!….

And so your code changes, the server code changes, and we are now looking for needles in haystacks with millions of lines of code.

The days when a server ran for literally years and years (hello, Novell, how you doin’?) are long gone.

So we have tighter deadlines than ever before but technology that allows us to deliver lightning updates whenever we like – but really what we should be doing is getting it right first time.

Developers around the world are embrasing Test Driven Development or TDD. It is a development process whereby the completeness of a project is defined by its ability to pass a series of tests.

If all the tests pass then the project is complete and, best of it, it’s been tested – oh wait, how did that happen?

So I guess what I’m trying to say here, and it has been a windy little ramble, is that software development IS a time consuming process, especially to get it right, and with all the business pressures constantly being exherted, it is even more important to pursue a development life cycle process such as TDD to ensure that the code we produce as developers is the best it can be and has been tested thoroughly before being passed on to the client whether it be a custom piece of development for a business or an application you’ve built to be sold on the Internet.