I've recently finished reading Scott Rosenberg's rather excellent Dreaming in Code. It's a book about programming, rather than a book about programming. What I mean by that, is that its the sort of book that you could give a client to read to give them an insight into the programmers world. It's about programming in the same way that a book about "D-Day" is about D-Day (ie, what happened when and why). I don't use that analogy lightly either. Having read a few ww2 history books in the past, this reminds me of those, although a different genre. The tale is like reading about a battle of an idea against some of the best minds in software development. The programmers are going to change the world with their new way of organizing information, time and money seemingly no object. Roll forward a few years, and whilst time and money are still not really that much of a barrier, it seems that the programmers need to product something rather than perfect the design for 10 years. And I don't blame them. The original idea would have taken a very long time to perfect, and I think that their approach in the end was probably correct (I won't tell you what happens, I'll leave it to you to read that). I also found it interesting to read characteristics that I possess being described by Scott Rosenberg. Things like "whilst they are eternal optimists, programmers always take an idea, and analyse it to it's ultimate doom [I paraphrase]," (effectively working out everything that can go wrong so that they can anticipate how to deal with it - something that my wife points out I do quite regularly in the non-programming world). Scott Rosenberg also leaves the best chapter 'till near the end too - a lengthy discussion (and historical text review) on whether developing software is "engineering" or "artistic." Previously, I was of the opinion that whilst it was both, it was more on the "engineering" side. After reading that (and relating that to what I actually do) I have changed my opinion and I now think that programming is primarily "artistic" and a creative pursuit than an engineering feat. In my "about me" page on this site, I've referred to myself as a Systems Architect, primarily because the accepted definition includes specification, design and development of many the layers of the system that makes up the solution. I think I'm going to change that soon to something more appriopriate, like Systems Author, or Systems Sculptor. Hmm. Systems Sculptor - I like that. Anyway, I recommend you read the book yourself and make up your own mind on the engineer vs artist debate, plus it's good for motivating yourself as you start your next project. [tags]books[/tags]

So, following on from my recent reading, and having just finished a project, I've been investigating using cruisecontrol.net and the nmock framework. The old project was the customers website, which enables the company members (the website is for a member's only shop), to make purchases from the catalogue, manage their accounts, transfer funds to and from their online account, manage membership subscriptions, and manage their distributors (members of the public who resell stock on for members, kind of like Avon or Bettaware). Oh, and an extranet site to let the office people manage the above. Anyway, that part is now in a maintenance phase for the time being (i.e. Done, apart from bug fixes) - we have had a load of ideas to add (eg a members forum, and dynamic customised pdf catalogues for the members), so now I'm on another part of the project. This part of the project is the loyalty program processor - essentially members get a "commission" payment based upon their purchases from the company and the number of members they have introduced to the company who also purchase from the shop (although this is optional). The formula is fairly complex, and conceptually takes the form of a series of binary trees, although not algorithmically (unfortunately). I've written a "version 1" of the processor previously, a couple of years ago, so I know what to expect, and the previous version is well documented and diagrammed, and the requirements are fairly well fixed, but this time I want to get it done asap (I'm writing a version 2 to make use of newer functionality in the website, and also because the original design wasn't very extensible. Also v1 was win32 delphi code, which I haven't used now for a couple of years, which while great enough, I wouldn't know how to do things like remoting or reflection (or even if I could) ). So, I'm planning on making more use than I have in the past of various techniques like test driven development and continuous integration. The idea being that the earlier I spot the bugs the better. I've known this, of course for a few years, and whilst I've used unit testing, I've not really had much experience of TDD, and have only set up a cruisecontrol.net server today with the empty project and blank test class. So, I'll report back as to how I get on with that. [tags]unit testing, tdd, cruisecontrol.net, nmock[/tags]

Well, I've been a real bookworm the last few weeks. I've just read the Practices of an Agile Developer from the PragmaticProgrammer publishers. These books are always an easy read (I've previously read the SourceControl using Subversion and Pragmatic Unit Testing), and this one doesn't disappoint. I've been reading about "agile" practices for a few years now, and "sort of" using a lot of them, more out of luck than judgement. Things like integrate compile and test often are the sort of things that I do without thinking. The book's got a lot of good "what it feels like" sections where it tells you the sort of feelings you will be having if you are doing this particular practice. eg, for compiling and testing often, it says something like: "You feel a bit nervous if you haven't compiled & tested after having typed a few lines of code." Well, golly, yes I do, especially when maintaining existing code. Anyway, it's the sort of book that reinforces the practices that you have been using all along, and guides you away from the habits you know are bad (like the quick-fix to get it done, rather than spending time to do it properly). In fact, the book is sort of like Steve Mcconnell's Code Complete, but a few hundred pages shorter. And, just in case you forget the "practices," there's a handy tear-out quick reference card that you can pull out and leave on your desk for all to see and refer to in times of emergency or stress. All in all, a good book, a quick read (about 3 evenings of light reading), and well laid out. [tags]book review[/tags]

Why are my blog posts so infrequent? I don't feel that adding material to the web that is readily available on other blog sites needs to be on mine. Technology announcements etc. What I do like blogging about is problems that I have solved after a bit of research, as I feel that if I have that problem, and it took me a while to find the answer, then it may benefit someone else to have my experiences on the web. If I am going to take time to make a blog post, then I want it to be something worthwhile, rather than a "me too" kind of post. That said, I may well break the above rule as I choose. It's my blog after all! [tags]blogging[/tags]