Right Tools for the Job

I had an evening yesterday to do some coding for another GP Surgery and it made me understand it’s not a matter doing the best possible application which is loosely coupled, well designed and future proof but using the right tools for the job.

I was asked by Tom Brownhill in a GP Surgery to see if they could do their flu invites though PatientChase (a product I develop which supplies software to GPs in the UK). Of course you can I said, but then he wanted the following

  • Individual Times for Each Patient
  • x number of  patients per slot
  • Slots of y minutes
  • within clinics of set times and dates

I set aside one evening to do the job but luckily when scoping out the app I soon realised to do it in an evening I’d need to do some rapid prototyping which is another word for shipping the app just to get the job done. But is that so bad? I would probably take a week if I was going to do it “properly” but this would be extra effort. So I’ve realised you need to do

The minimum amount of work to get the job done properly.

However it’s how you define the word properly which matters.

You can see the code in GitHub here in all it’s gory glory but a few comments

Why didn’t you use WPF?


It took me 5 minutes to do the front end and served the purpose it was meant to achieve. I think this is part of the problem with WPF, it can be difficult for developers to justify it’s use with it’s learning curve if they are just doing desktop vs desktop and other devices. It also has a high overhead especially for animations.

For loops, oh my!


DateTime timeIndex = new DateTime(session.From.Year,
session.From.Month, session.From.Day, session.From.Hour,
session.From.Minute, 0);

for (int n = 0; n < session.NoOfSlots; n++)
for (int i = 0; i < Context.MaxPatientsPerSlot; i++)
timeIndex = timeIndex.AddMinutes(Context.SlotLengthInMinutes);

This fitted well in the context of what I wanted to achieve. I’m not accessing the index so there’s no issue with out of index errors and it’s  little faster.

Using Datatables instead of Objects

There are lots of really nice csv helper nuget packages (CsvHelper, FileHelpers, LINQToCSV) out there but most of them require a one to one mapping with the columns and Models. I didn’t need this as I don’t care what’s right of the 1st column and if I did it would be more complex to define and inform the user.

I settled with CsvReader which converts the Csv to a Datatable from which I insert the Date and Time required for the patient into the 1st column. The only pre-requiste is that the first column must be named “Slot”.

Code to Load Csv Into the DataTable


Code to Save DataTable To File


Gosh, why use Datatables in this day and age. It was the right tool for the job and made the hard bit of the app so easy…

Passing GUI Controls Text Properties into the Service Layer

Repository context = new Repository(


context = new CreateTimes().ProcessRepo(context);

new CsvExport(Path.Combine(
   string.Format("PatientFluInvite.{0}.csv", DateTime.Now.ToString("dd.MM.yy"))), context.DtPatients);

MessageBox.Show("Result on the Desktop", "Export Complete");

Again it’s not good practice to pass references to GUI controls directly to the service/domain layer. I should be abstracting this. However abstraction takes time and is there a need?

Lack of user error checking

This is one area I’d revisit quickly to tidy up input error checking and tidy up the GUI a bit to prevent exception errors for values in the wrong format and type.

In summary look at the user requirements, what you have at your disposal and time it would take to achieve your goal. Why do you want to create a ferrari when all the user needs is a bicycle to get from point A to point B?