Centrist Approach to Process and Design

[swatts]

Hello Weary Travellers (for those who have travelled)

Well that was an enjoyable NIWeek! I'll do a diary of my travels around the USA next blog, needless to say I went to a lot of odd places and had a great deal of fun.

Here's a piccie of some wild flowers that I saw with the lovely people Fabiola, Brian and Matthias.

Wildflower Center

One question I get asked often is about whether I love xxx or hate xxx and if I were to make an observation it is that software design seems to be an all or nothing occupation. It seems to be something peculiar to software engineers. I've never heard builders being pro or anti-screwdriver, they are just tools to do a job.

I also think that our software community doesn't evaluate shiny new things as befits scientists and engineers. 

As I hopefully ascend the ramp to programming enlightenment I would like to propose a centrist position. I think that the best way to program is to use a particular technique where it is most appropriate. Here's some examples where I think the moderate approach leads to better outcome...

First let's look at Agile.

There are times in a project life-cycle where Agile is appropriate, but I will contend that there are also times when it isn't. For us the start is Agile, then the project goes into a more disciplined life-cycle and then from Beta we're back being Agile again.

Now let's look at OOP.

I have reached a bit of an epiphany with regards what works well and what doesn't. It's a bit earth-shattering, but I've not seen it put this way before.

OOP works well when it is a tangible object (hardware, report etc), I think when you start getting contrived objects like moderators, managers, factories, facilitators etc there is a clearer way to program. Here the mixture of procedural and objects comes together nicely for us.

Similarly Actor stuff works best when there is a definite need for an asynchronous process (we call them services).

Globals?

Globals are neither evil or brilliant. They are just a technique for passing global data and sometimes this is cleaner than all the knots people tie themselves into with pseudo-globals (DVRs, FGVs, Shared Variables, Named Qs etc <-- these are all global data!). The thing with global is write once and read many times. If you're writing many times you need to think of encapsulation.

Add to this the extra variable of use-case and you can see that being a purist may be an expensive past-time. Use the tools appropriate to your use-case and life will be less stressful for everyone.

Maybe the centre-ground is the path to get our most efficient designs.

Lots of Love