Entry 1676, on 2014-08-29 at 13:58:07 (Rating 1, Activities)
My loyal readers might have noticed that I haven't written a blog post for a while despite the abundance of source material I could have used. There is a simple explanation for this: I am working on too many other projects just at the moment and have tended to spend time on those instead. Contrary to what you might think I do spend a reasonable amount of time researching, writing, and revising each blog post and they're not just tossed together in 5 minutes!
Most of what I am working on currently are programming projects which all seem to have become critical at the same time. But that doesn't really worry me because (and I'm sorry if this sounds really geeky) programming is fun. It's one of those rare creative activities which results in something which is actually useful (well, at least in most cases).
When I create a new system (and my current projects all involve web-based databases and apps written using PHP and MySQL) I like to create something which is easier to use, more reliable, faster, and just generally more elegant than the alternatives. There are some pretty impressive web-based systems out there now but there is a much greater number of truly terrible ones, so in general I just hope to raise the average a bit.
It's quite amusing using another person's web system and noticing all the design and functional errors they have made and smugly thinking "amateurs! my projects never suffer from that problem!" Of course, I shouldn't be too smart because every system has its faults.
As I have said in the past, programming is a great combination of art and science, or at least it should be because both are required to get the best outcome. The art component doesn't just involve superficial factors like graphics and typography, it is deeper than that and requires creation of a friendly, logical, and flexible user interaction. The science component should be obvious: programs must be technically correct, perform calculations accurately, but also more subtly be fault tolerant, easy to enhance, and interact with other systems properly.
All of this is not easy to achieve and I have made plenty of mistakes myself, so it is even better when something does magically come together in a positive way. And that description is significant because the way I work a project is an evolving, organic thing which often changes form and function as it progresses. I always have a plan, diagrams for the database structure, flow diagrams for the general functional flow of the program, and technical notes on how certain functions should be performed before I start coding, but by the time the project is finished all of these have changed.
And I am often asked to write technical documentation while I am creating a new system but that is useless because I change the details so often that it's better just to write that documentation when the project is complete.
When I look back at old projects I am sometimes amused at the naive techniques I used "back in the day" but more often I am quite amazed at some of the awesome, complex code and clever techniques I have used. It's not usually that I set out to write really clever, complex code, it's more that as more functions and features evolved the code became more and more impressive. But it is too easy in that situation to let things become convoluted and clumsy. In that case I toss that section out and start again. Sometimes my systems take a little bit longer to complete but they always work properly!
And that brings me to my last design philosophy. I don't re-use a lot of code, I rarely recycle libraries and classes, and I definitely avoid using other people's code. Also I don't use rapid prototyping tools and I don't use graphical tools to create markup code like HTML. No, it's all done "on the bare metal".
In fact that's not really true, or course. I was recently tidying up some shelves in my office and found some old machine code programs I wrote back on the 80s. Now that was really coding on the bare metal! Multiplying two numbers together was a big job in that environment (the 6502 had no multiply instruction) so PHP and hand-coded HTML are pure luxury compared with that!
Well that's enough talking about it, it's time to get back to doing it. I've got a nasty bit of database backup code to debug right now. Some sort of privileges error I think, time for some science and not so much art.
Comment 1 by richard on 2014-09-09 at 10:26:46:
Enjoyable article - I appreciated and 'caught' your enthusiasm. Then you mentioned 6502 and I got really excited. I too remember writing MIDI programs on the Apple IIe in 6502 machine code, to store synthesiser parameters and settings etc on the computer, and display MIDI data as you played the synth etc etc. I was quite proud as a 'youngster' to actually discover a bug in the ROM of one of Roland synthesisers, when my 6502 code didn't work as expected. I followed it up ('knowing' my code wasn't at fault) and the code sample eventually went right back to the original developer of the synths ROM back in Japan, who wrote back and verified that I had it right after all and it was their ROM that was faulty. Yeehaa moment! Thanks for the memories!
Comment 2 by OJB on 2014-09-09 at 11:52:32:
Happy to share those great moments from the early 80s! Things were very different back then. We now have so many great facilities provided by the OS that programming is a lot about connecting the components in the OS together. This certainly makes creating awesome programs much easier but somehow it's just not the same.
One of my favourite comedy sketches. I often quote it to my son and daughter and they look at me strangely (that happens a lot). Thanks for the excuse to watch it again!
You can leave comments about this using this form.
Enter name, email (optional), enter number, comment, click Add. You can leave the name blank if you want to remain anonymous. Enter your email address to receive notifications of replies. Comment should appear immediately (authorisation is inactive).
BLOG PAGE
