Consciousness

(started off as a reply to a post of  coalescent's)

In my (extremely simplified) opinion, consciousness is the reflexive bit of the brain that deals with abstract concepts.  It's the deductive bit that sits on top of the main, inductive, areas of the brain, putting together concepts based on the observations those areas make, and feeding back when it makes a logical connection between things that the purely reactive areas can't.

I don't think it's in any way 'in charge' of the rest of the brain, and I think people's inductive areas frequently overrule it, leading to people saying things like "I was out of control." and "I don't know why I did it." and "I knew it was the wrong thing to do, but I couldn't help myself.", but I do think that it exerts pressure.

I don't think consciousness comes from a sufficently complex et of neurons - I think it comes specifically from an arrangement of neurons that can work in abstract, deductive ways (like the human forebrain, and that of various other mammals). 

I think the reason that we have such problems with AI is that you need both inductive and deductive thought and computers are _terrible_ at induction - being basically deduction machines.  Also, most of the AI researchers are extremely geeky, and therefore focussed on logic, believing that's what intelligence is.

Development Techniques (or why most software sucks)

I moved to a new team at Christmas, leaving the mainframe (largely) behind me, and heading into the worlds of Java and C#.  This was nice - a decent IDE makes a huge difference to me, and compiles that take 3 seconds rather than 5 minutes are a godsend.  However, in many ways this wasn't the biggest change from my old team to the new one.

The standard way of working on software development is for a business analyst to talk to users, look at processes and work out what is needed, setting it out in some kind of large document.  An IT analyst then takes this document and produces a design and specifications for how the computers will produce the effect the business person described.  A bunch of programmers then follow the specification to produce a working system that fulfills the IT analyst's specification.  At the end the working system is handed over to the users, who cry with joy at the sheer wonderfullness of what's been created.

Or Not.

What tends to _actually_ happen is that the Business Analyst has a pretty good idea of what they want, knows that anything they miss out will cause people to whine at them incessantly, and that IT projects come along once every five years.  They therefore throw vast amounts of 'nice to have' items into the spec, leaving out lots of things that they believe are obvious, and put in a variety of things they can't have, as they don't actually understand the current system.

The IT analyst then mostly understands this document, works out a good way of implementing bits of it, hides the bits that look impossible, writes up a design based on their (limited) understanding of the current system and hands it to a bunch of developers who all work independently to produce something which then doesn't really hang together when they come to integrate it.  It doesn't quite do what the IT analyst wanted (because the spec wasn't 100% perfect), it doesn't really do what the business analyst wanted (because the IT analyst didn't understand the business spec 100% before writing the IT spec), and it really doesn't do what the actual business user wants (because they've been pretty much left out of the whole process). 

The business users then complain loudly about the programmers, who are terribly upset, because _they followed the spec_.  At this point everyone goes down (separate) pubs and cries into their beer.

The problem here is not the quality of specs, the quality of the understanding of the various people involved or the laziness of the various workers.  The problems is that the whole methodology is a big pile of poo.

The _current_ methodology we're trialling (to rapturous response) is this:
The business people come to us with a problem.  We then spend 1-4 weeks going over their processes with them and seeing where we can help, before agreeing a general, over-arching goal/direction for the project.  We then agree what we are going to do _in the first month_.  We do this using a very simple method - they organise their priorities into a list (with our help) and then we tell them how far down the list we can get in a month.

We then beaver away for a month, producing the stuff we said we would.  We do this _with a business representative sitting with the team_.  This business rep may well bring work with him to do while they're sitting there, but they're constantly available when we ask awkward questions like "When you said you wanted X, did you want X1 or X2?", the answer frequently being "Y, of course."  This keeps us on general track during that month, in general.

At the end of the month, we then have a system that _does something_.  This is important.  It may not be finished.  It may not be ready to show the world.  But it _is_ in a state where we can show it off to a bunch of business people and ask for their feedback.  They can then look at what we've done and decide (a) what changes they want, because of miscommunication and misunderstanding and (b) what ideas they've now had as to what it could do.  We now go back to the priority list, they add, remove and move things around and we then agree what will happen in the second month.

By doing this, it is impossible to produce a system they don't want.  We may go off on the wrong track for a month (although this is unlikely with a business person sitting there), but we can't go wrong for longer than that.  We can't focus on functionality they don't care about, rather than the things they do, because they set the priority.

And so far, in general, it seems to work extremely well.  I never have a feeling of working in a vacuum, or that I'm not doing the right thing, or that what I'm making makes no sense - because there's always someone around to give me a sense-check, and at the end of each month we get feedback about how well we're doing.

If they try to make me go back to the old way of working, I'm going to cry.  A lot.

It's the Gruniad again!

I sent a letter into the Guardian Online section, which was published in this week's letters page.

I got an email from them during the week saying:

We would like to use your letter to Online, but we need to add a geographical area. Are you in London?

I replied with the following:

I'm in extremely North London.

Or "Edinburgh" as we call it.

Can you guess where they actually put as my address?

Axiom 1

Over here you can find Axiom 1 of computer programming, as reported by my brother.

It is:

If the total time wasted by all computers ever running the slow version summed up, is less than the time taken to discuss it collectively on ‘progs’, go with the slow way. Else discuss more on progs until axiom 1 is true, then go with the slow way.

(where 'progs' is the programmer mailing list at his work)

Blogger back. Not.

Remember the fuss about the blogger wh was sacked from Waterstones for talking about them on his journal?

He successfully appealed his dismissal.

They offered him his job back.  He decided to stick with his new bosses (Forbidden Planet).

Which reminds me - has anyone else noticed that the current Forbidden Planet SF selection in Edinburgh is remarkably shit?