Not Technical Really

Ok, inflammatory title for this post but I listened to a great Podcast talking about the science/religion debate and a couple of things really resonated with me.

Web2.0 and Memes

Firstly was the concept of Memes. Memes is ideas in analogy to genes where:-

memes have, as a fundamental property, evolution via natural selection

I Immediately thought Web2.0! I wont try to Define that but one of the things that sites like Digg.com and Blogger.com do is to catalyse the the evolution of memes, crank up the number of collisions between and tests of ideas. Its happening online right now on and software is making it happen!

Software as Meme

Then I thought, wouldn't it be cool if we could design elements of software that can self evolve be tested and 'compete' to fulfill a role within a process?

'We need software to be stable' you say. Thats fair enough but consider this. What if when you built and tested HelpyWidget1.0, everything was fine but now the processing volume has increased, the mid tier server is new, the Database software is new, the new Database forced us to upgrade the client drivers, none of the users ever use the feature xyz anymore but all of them call the software 'frank'. The environment your code lives in is changing, Code maintenance is boring and expensive. 'Bring on Evolving software!' I say.

As a side note, The Agile folks use 'refactoring' to adapt to changing environments and requirements and to constantly improve the quality. This is a sensible approach to the same problems...but evolving software is way cooler :)

Intelligent design Is not Necessarily good design

The program talked about the clash between Intelligent Design and Science/Evolutionary theory. The presenter made an assertion, 'if anybody has seen the design of the human prostate, they wouldn't believe in intelligent design'. Then I thought, I see crappy design in software every day. Developers are intelligent, building software fits with intelligent design. The assertion that a designed system is a perfect system is only correct if you assume the designer is perfect. The simple fact is that for most humans, bad design, bad software is easier than good design, good software.

So Papa calls last night and has a full 30 Minute spew about his new, ADSL connected computer. After sorting through the confusion, I discover the evil culprit....Auto Update.

Case 1) 'Whats Java and why do I care?'
So the Java Runtime environment was installed by default on Papa's new pc. Fair enough, you need it to do lots of cool stuff on the internet. The problem started when the JRE decided to check the internet for an update and ask Papa if he wanted to upgrade. Now Papa has decided (sensibly) to say 'no' to everything he doesn't understand (most things) but he still found the whole thing confusing (was it a virus?, was it adware? does he need it?).

Case 2) 'Whats Adobe reader?'
Basically same scenario, Adobe auto updater this time but it was also tangled up with hotmail...Mrs Papa saves a pdf file local and then wants to forward the mail on with the document, double clicks the file, adobe reader checks for update, asks the question....Total confusion.

I am a power user, and am in front of a PC a lot. I think auto-update is cool because I like things to take care of themselves. but Papa (and a lot of people) just want their computer to be quiet and only do things when they ask it to do something. There is enough crap to worry about with Adware popups and scam emails, why should legitimate software add to this burden with auto-update confusion.

According to a very learned and wise colleague of mine, while developers will always say that they are pro workflow, none of them really believe
that it works. Personally, since being involved in a workflow project, I have always liked the idea. Its so neat and tidy, the yucky business rules that no developer really truly understands are zip-locked away in some XML document or modeling tool and we can just code neat little boxes that respond to requests from the workflow system. If the flippy types in the business change their mind about a process, you can just fiddle with the model. The code can stand stoicly firm, clean, pure and sexy in the twirly maelstrom of the business process.

I have to admit though, I have never seen workflow actually work. The workflow project I was on never got to technical implementation because they made a headcount save by rearranging the business units more efficiently after reviewing the business processes (the solution didn't involve a .sln). Another colleague of mine says that 'every insurance business in London runs on a workflow platform' so I suppose the statement/heading at the top of this page is debatable.

I decided though to ask the question,

if workflow doesn't work, what does?

This is very difficult, so I gave up on that question and decided to write down a few things about people and systems and work that I was pretty sure were true..Well it started off that way and went a bit pear shaped towards the end...Anyway, this is what I came up with.

Warning, Stream of consciousness follows

People at work have things to do

Systems at work have things to do

Things to do have only a few important attributes. What exactly to do, which people or systems can do them and when they need to be done by.

Sometimes people do the things to do, sometimes systems do them, it doesn't really matter which. People are generally good
at some things and systems are ,generally, good at other things. Some things to do can be done by either people or systems, the only difficulty
with this is, often system friendly instructions and people friendly instructions look a bit different.

An object, for example, a data row or document is fixed in space, it doesn't move (conceptually any way),
it doesn't flow, it is not in a pipeline, it is not transported, it is not itself a thing to do. A thing to do may contain references to objects. The format of these references is not really important, so long as a person or system can find the object or objects it needs to do the thing to do.

A lot of things to do are very similar each time we do them. It seems reasonable that things to do
should be able to be copied from older things to do. Other things to do are completely new and novel, that's ok to, as long as somebody or some
system can do them.

Sometimes after doing a thing to do, it is appropriate to create another thing or things to do. For certain types of
things to do, we may really know for sure what that next thing to do is eg. after receiving a fax instruction to move some cash into an account, the next thing to do should always be to call back the owner of the cash and verify the details...Often when this happens, some or all of the references to objects are passed along to the next thing. Sometimes there may be nothing to do next, sometimes you may not know what the next thing is until you have finished the first thing.

A thing to do is never done until you have created the next thing or things to do, or decided that there is nothing to do next.

People and systems need to know what things to do, they can do.

Systems like to have their things to do in a queue. Systems are good at processing queues.

People find queues depressing. When people look at the things to do that they can do, they
may like to see these things floating, like little blobs of wax in a colorful lava lamp. When things to do are not very urgent, they might float low
in the lamp where the colour is shady and blue. Inevitably, things to do become more urgent and may be seen to float upwards where the colour is brighter and more orangey. Things to do should never appear to flash, become underlined or jerk about wildly. A bit of bobbing on the surface may be ok though ;)

When I was in high school, I was handed one of those 'What career is good for you' kits by the school careers councilor. So I ticked all the boxes and added up all the scores and discovered that with my mix of empathy and analytical skills, I was perfectly suited to being a psychologist! With typical aplomb and common sense, I proceeded to do a degree in Materials Science and now work as a software developer/architect.

So despite my career, if you ever come round for a BBQ, please dont ask me..'should I buy this PC' or 'I am getting this funny error from Firefox'. I'm not technical really but I do know a but about software development and am learning about user focused design. I hope that my odd ventings and rantings may be usefull to some other unfortunates in the software game.