Some thoughts on Programming

As programmers our work consists of the following: talking, thinking, coding and difficult stuff. All four things are necessary.

Talking is essential, we swop ideas, learn new things and generally train our brains in new skills.

Thinking: this is where we are mulling over problems, planning possible solutions or re-evaluating. One of the key times for me doing this is at home when I’m not in front of a computer or in a noisy open plan office. I like to garden and quite often great ideas will pop up ‘out of the ground’.

Coding, this is putting into practice everything we’ve talked about and practised. Some programmers spend to a lot of their time coding, others take a more surgical approach. Apparently programmers only spend ten per cent of their working day writing programs, which sounds wrong but is about right.

Difficult stuff: This is a catch-all term for all the bits of work that is either truly difficult, hard-to-solve bugs or the flash stuff where we show off. “Look at me, I can do this’. Some of the difficult stuff is difficult because we simply don’t do it very often. Pushing software live is one of these things. Some of the difficult stuff becomes much easier with practice.

Other tasks remain difficult not because of the technical complexity but the complexity of the relationships between all the interested parties. Programmers, despite quite often wanting to, rarely work in isolation and what they do affects others. None more so when pushing software live.


SQL Server Enterprise Manager Gotcha

A fairly routine task today became a bit of an ordeal, made worse by remembering the symptoms but not the solution. So, I’m documenting this to try and prevent future occurrences.

All I wanted to do was set up a Foreign Key / Primary Key relationship. This should have been relatively straight-forward but wasn’t. The error message from Enterprise Manager told me that it couldn’t create the relationship but didn’t tell why.

Now, I remembered this problem happening before but for the life of me could not remember reasons for it happening. Eventually after getting other people’s views I found the reason, which is that the two columns didn’t have a relationship. I was making too many assumptions.

In future the best way to prevent this error are to follow these two steps.

1.) Make sure column names are fully descriptive. This way the links between should be obvious. See Step 2.

2.) Try and do a join between the two tables. The error I was getting was me trying to link two columns that could not be linked. It might be useful if SQL could tell me that, but it didn’t and perhaps can’t. The confusion arose from there being two IDs, and I was referring to the wrong one. Now, there should only ever be one ID but at the moment with some of my database tables, one ID points to a SharePoint List Item, and the other to a row in the database. The work I’m doing at the moment is to try and get rid of the links between SharePoint and the database so normality can resume.


Using Generics

A while ago on StackOverflow I asked a question about what problems could be solved using generics. I had read a lot about generics and use Lists a lot but I personally for a good long while hadn’t used them.

Recently I started looking at to use for DataMapping and ended up developing the following service to help me in my code. This is a fairly good use of generics I feel. What the service is doing is taking two objects: a target and a source. It then copies the values from the target into the source.

using System.Collections.Generic;
using Omu.ValueInjecter;

//Uses to do the mapping

namespace MyVee24.Services {

    public interface IDataMappingService<T, K> where T : class
                                                                                  where K : new() {
         K Map(T storeDept);
         List<K> MapList(List<T> dataStoreDepts);

    public class DataMappingService<T, K> : IDataMappingService<T, K> where T : class
                                                                                                                                   where K : new() {

        public K Map(T source) {
K target = new K();
return target;

        public List<K> MapList(List<T> sourceList) {
List<K> targetList = new List<K>();
foreach (T item in sourceList) {

            return targetList;

I’m posting this as a handy reference, mainly for myself.

P.S: Apologies for the lousy formatting. I’ll try and find time to learn how to format code samples nicely in WordPress

Add jQuery to almost any site from the console in your browser

First I must stress that I’m copying this article from here. I’m writing this post so I can keep this snippit of code in a place that’s handy. As I say I read this artice on SpYk3’s blog and all credit must go to him.

If you have a modern browser you’ll be able to find the console, The Firebug extension in Firefox is the easiest way to do this. Open the console and paste these lines of code in:

if(typeof jQuery === 'undefined') {
  var $script = document.createElement("script");
	$script.src = "";
	$script.type = "text/javascript";

You should now be able to use jQuery and run any commands you wish. All this code is doing is adding a script tag to the webpage and adding it to the <head> tag that exists in nearly every webpage. The source attribute of the script tag loads the jQuery javascript from the URL it’s specified.

Evolution versus Revolution

A friend of mine once, as part of a job application, had to do a presentation concerning evolution versus revolution and how they applied to software. For one reason or another she never did the presentation, which was lucky because as she confessed to me she didn’t know what to talk about.

If you had a big piece of software that needed changing so as to keep up with your competitors, whilst also allowing you to introduce new innovations, which method would you choose? Would you sweep all the old code to one side and start again with a completely clean sheet: the latest technologies, perhaps that new language that everyone is raving about and commit all your development resources? Or would you take calm measured steps, always aware of the direction you needed to go in but conscious also of the here and now, the code you currently have, the demands of business and your customers?

Is the Big Re-write really a revolution? Netscape thought so but in the three years it took them to develop the latest version of their browser the market and their customers had moved on. At a previous company two well-meaning developers were given a year to develop a brand new product, the company stopped taking on any new business and we all waited. At the end of the year, the product was half-finished, difficult to work with and within the next year was already being replaced.

Revolutions happen swiftly and suddenly. Something that takes three years cannot be a revolution but that doesn’t imply it is then evolution. Evolution is when you adapt, when a tangent suddenly turns out to be an exciting new direction. When a caterpillar turns into a butterfly that’s evolution, when a potato goes mouldy that’s decay; both have changed but only one for the better.

The tricky part for developers is writing software and applications that give us this flexibility, this ability to evolve and keep our companies in business

I believe that Agile development, Object Orientation, and lean, well- tested code give us this flexibility. Growing object orientated code is evolution, and if you’ve read the book then hopefully you’ll agree with the point I’m making. If you have’ a big piece of software’ make gradual changes. Re-write a bit at a time. Do some pruning; get rid of repetition or redundant features. Set small goals and aim to achieve them quickly. Get these changes out into production and see what happens. Don’t wait around. That’s evolution, just getting on with things.

Getting rid of everything that’s gone on before and starting again is tempting but is that really possible with software? Don’t forget that revolutions could also mean you are simply going around in circles, repeating the same mistakes many others have made before.

The Right Tool for the Job

Something that has been on my mind for a number of months now is the ‘rightness’ of a tool. When I  had left secondary school with no idea what I wanted to do, my first job was in a textile mill. It was an interesting place to work because the majority of the looms were made in the Nineteenth century. It was like stepping back in time, although thankfully there wasn’t a requirement to do three hours work before breakfast and there were metal guards in place so there was less chance of getting trapped in a machine.

I was employed as a tackler, which can be taken to mean loom mechanic. I learned how to fix looms and how to work with wood. This particular mill produced woven narrow fabrics used in upholstery, probably one reason why it had lasted as long as it had. Each loom had at least sixteen shuttles made from box wood or hornbeam and quite often they needed repairs. One of the reasons for using box or hornbeam is because they have very close grains, which means they don’t produce splinters.

I wasn’t particularly skilled at working with wood at school but I gained a real appreciation for it in the mill. Pulling machines to pieces and putting them back together was real work. Some of the jacquard machines were very complex and required patience and skill to repair.

I mention all this because I think it is easier to visualise a carpenter having a favourite plane or a favourite chisel. It would be a tool that fitted so nicely into his hands that it would feel like an extension of them. He could concentrate on his work with no distraction or irritation from the tool he was using.

This should be a goal we should strive for when writing software. It should be a good fit, it should feel right and it shouldn’t get in the way. All too often when we write software we either don’t know how it is going to be used or we’ve been given that many requirements that it is impossible to produce a tool that will satisfy any. There is a reason why Swiss Army knives have not replaced corkscrews, screwdrivers, scissors and pen-knives. The saying ‘Jack of all trades, master of none’ springs to mind.

It is though worth bearing in mind that one carpenter’s favourite chisel is another’s least favourite. A tool that helps one person can hinder another. Yet, most chisels will do the job and nine times out of ten if you buy a chisel it’ll be ideal for the job. One of the main reasons for this is that chisels and those who use them have been around for many years. We know what they should look like and what a person using them hopes to achieve.

There’s a lot to be said for a tool that feels right and just works.