Sainsburys reward carrier bag re-use!

For every carrier bag you re-use they give you a whopping 1 (yep a whole ONE) Nectar point.

"QI: The Book of General Ignorance" is currently on offer at only 2,400 points, and using Amazon as a guide on its retail price (£4.76), that means each point is worth a staggerring 0.2p

Oh, and you have to actually use a carrier bag to qualify. Not using any carrier bags at all means you get nothing.

Way to go Sainsburys, that global warming's going to be stopped in its tracks now.

The Happiness Meter

As part of any iteration review / planning meeting there should be a section where everybody involved talks about how they felt the last iteration went, what they thought stood in the way, what they though went particularly well and suchlike.

We find that as the project goes on, and the team gets more and more used to each other, this tends to pretty much always dissolve into everyone going "alright I suppose", "yeah fine".

Obviously, this isn't ideal and will tend to mean that you only uncover problems in the project when they've got pretty serious and nerves are pretty frayed.

This is where "The Happiness Meter" comes in.

Instead of asking the team if they think things are going OK and having most people respond non-committally, ask people to put a value against how happy they are with the last iteration's progress. Any range of values is fine, just as long as it has enough levels in it to track subtle movements. I'd go with 1-10.

You don't need strict definitions for each level, it's enough to say '1 is completely unacceptable, 5 is kinda OK, 10 is absolute perfection'.

At some point in the meeting, everyone in the team declares their level of happiness. When I say everyone, I mean everyone: developers, customers, XP coaches, infrastructure guys, project managers, technical authors, absolutely everyone who is valuable enough to have at the iteration review meeting should get a say.

In order to ensure that everyone gets to provide their own thought, each person writes down their number and everyone presents it at the same time. The numbers are then taken recorded and a graph is drawn.

From the graph we should be able to see:

1. The overall level of happiness at the progress of the project.


2. If there is any splits / factions in the interpretation of the progress.

If the level of happiness is low, this should be investigated; if there are any splits, this should be investigated; and just as importantly - if there are any highs, this should be investigated. It's good to know why things go well so you can duplicate it over the next iteration.

Factions tend to indicate that one part of the team has more power than the rest and the project is skewed into their interests rather than those of the team as a whole.

You may want to split the graph into different teams (customer / developer) if you felt that was important, but I like to think of us all as one team on the same side...

All said and done, the graph isn't the important bit - the discussion that comes after the ballot is the crucial aspect. This should be a mechanism for getting people to talk openly about the progress of the project.

UPDATE: Someone at work suggested a new name that I thought I should share: The Happy-O-Meter.

Ideas for improving innovation and creativity in an IS department

At our work we've set up a few 'action teams' to try to improve particular aspects of our working environment.

The team that I'm a member of is responsible for 'Innovation and Creativity'.

We're tasked with answering the question "How do we improve innovation and creativity in IS?" - How we can foster an environment that encourages innovation rather than stifles it.

As a bit of a background, the company is a a medium sized (2,500 plus employees) based mainly in the UK, but recently spreading through the world, the vast majority of whom are not IS based. The IS department is about 100 strong and includes a development team of 25 people. It's an SME at the point where it's starting to break into the big-time and recognises that it needs to refine its working practices a little in order to keep up with the pace of expansion.

We met early last week and have put together a proposal to be taken to the senior management tier. I get a feeling it will be implemented since our team included the IS Director (you don't get any senior in our department), but you never know what'll happen.

I figured it might be interesting to record my understanding of the plan as it stands now, and then take another look in 6 months time to see what's happened to it...

We decided that in order to have an environment that fosters creativity and innovation you need:

Freedom:

Time for ideas for form, for you to explore them, and then to put them into practice.

Stimulus:

Outside influences that that can help to spark those ideas off - this may be from outside the organisation, or through cross-pollination within it.

Courage:

The conviction to try things, to allow them to fail or succeed on their own merit - both on the part of the individual and the organisation as a whole.

Natural Selection:

The need to recognise success when it happens, to take it into the normal operation of the business and make it work in practice. Also, the need to recognise failure when it happens, and stop that from going into (or continuing to exist within) the team.

Recognition:

When we have a good idea, the people involved need to be celebrated. When we have a bad idea, the people involved DO NOT need to be ridiculed.

Refinement:

The initial ideas aren't always the ones that are successful, it's the 4th, 5th or 125th refinement of that idea that forms the breakthrough. We need to understand what we've tried, and recognise how and why each idea has failed or succeeded so we can learn from that.

---

We put together some concrete ideas on how we're going to help put these in place - and bear in mind that this isn't just for the development team, this is for the whole of the IS department - development, project management, infrastructure, operations, service-desk, even the technology procurement...

Curriculum:

A position set up that will be responsible for defining / tracking a curriculum for each job role in the department.

Obviously this will be fed by those people that currently fulfil the roles, and will involve things ranging from ensuring the process documentation is up to scratch, through specifying reading lists (and organising the purchasing of the books for the staff) and suggesting / collecting / booking conferences, training courses and the like that might be of use.

This takes the burden of responsibility away from the staff and managers - all you need is the idea and someone else will organise it and ensure it's on the curriculum for everyone else to follow up.

IdeaSpace (TM ;-) ):

A forum for the discussion of ideas, and collection of any documentation produced on those ideas and their investigation. This will (hopefully) form a library of past investigations as well as a stimulus for future ones. Everyone in the department will be subscribed to it.

Lab days:

Every employee is entitled to 2 days a month outside of their normal job to explore some idea they might have. That time can be sandbagged to a point, although you can't take more than 4 days in one stint. Managers have to approve the time in the lab (so that it can be planned into existing projects) and can defer the time to some extent, but if requests are forthcoming they have to allow at least 5 days each rolling quarter so that the time can't be deferred indefinitely.

Whilst the exact format of the lab is yet to be decided, we're aiming to provide space away from the normal desks so that their is a clear separation from the day job and lab time. People will be encouraged to take time in the lab as a team as well as individually. Also, if we go into the lab for 3 days to find that an idea doesn't work, that idea should still be documented and the lab time regarded as a success (we learnt something)

Dragon's Den:

Gotta admit, I'm not sure about some of the connotations of this - but the basic idea is sound. Coming out of time in the Lab should be a discussion with peers about the conclusion of the investigation in a Dragon's Den format. This allows the wider community to discuss the suitability of the idea for future investigations, or even immediate applicability. One output of this meeting may be the formalisation of conclusions in the IdeaSpace.

Press Releases:

The company is already pretty good at this, but when something changes for the better we will ensure that we celebrate those changes and, even for a day, put some people up on pedestals.

None of the above should be seen as a replacement for just trying things in our day to day job - but the idea is that these things should help stress to the department that change and progress are important aspects of what we do, and that we value it enough to provide a structure in which big ideas can been allowed to gestate. Cross pollination and communication should just form part of our normal day job anyway, and we should ensure that our project teams are cohesive and communicate freely amongst and between themselves.

Also, an important factor in the success of the above has to be the format of the Dragon's Den - if it is in any way imposing or nerve-racking then the idea is doomed to failure. As soon as people feel under pressure to justify themselves then the freedom disappears.

I'm quite excited by the prospect of putting these ideas into practice, and I wonder exactly where we'll end up.

I'll keep you all posted.

An apology to IE users

To all those visitors who've visited the site with IE over the last 6 months and had a borken layout.

All apologies... I had no idea that long titles in the Orablogs digest was breaking things. The offending feed has been removed.

Things I believe in

• It's easier to re-build a system from its tests than to re-build the tests from their system.


• You can measure code complexity, adherence to standards and test coverage; you can't measure quality of design.


• Formal and flexible are not mutually exclusive.


• The tests should pass, first time, every time (unless you're changing them or the code).


• Flexing your Right BICEP is a sure-fire way to quality tests.


• Test code is production code and it deserves the same level of care.


• Prototypes should always be thrown away.


• Documentation is good, self documenting code is better, code that doesn't need documentation is best.


• If you're getting bogged down in the process then the process is wrong.


• Agility without structure is just hacking.


• Pairing allows good practices to spread.


• Pairing allows bad practices to spread.


• Cycling the pairs every day is hard work.


• Team leaders should be inside the team, not outside it.


• Project Managers are there to facilitate the practice of developing software, not to control it.


• Your customers are not idiots; they always know their business far better than you ever will.


• A long list of referrals for a piece of software does not increase the chances of it being right for you, and shouldn't be considered when evaluating it.


• You can't solve a problem until you know what the problem is. You can't answer a question until the question's been asked.


• Software development is not complex by accident, it's complex by essence.


• Always is never right, and never is always wrong.


• Interesting is not the same as useful.


• Clever is not the same as right.


• The simplest thing that will work is not always the same as the easiest thing that will work.


• It's easier to make readable code correct than it is to make clever code readable.


• If you can't read your tests, then you can't read your documentation.


• There's no better specification document than the customer's voice.


• You can't make your brain bigger, so make your code simpler.


• Sometimes multiple exit points are OK. The same is not true of multiple entry points.


• Collective responsibility means that everyone involved is individually responsible for everything.


• Sometimes it's complex because it needs to be; but you should never be afraid to check.


• If every time you step forward you get shot down you're fighting for the wrong army.


• If you're always learning you're never bored.


• There are no such things as "Best Practices". Every practice can be improved upon.


• Nothing is exempt from testing. Not even database upgrades.


• It's not enough to collect data, you need to analyse, understand and act upon that data once you have it.


• A long code freeze means a broken process.


• A test hasn't passed until it has failed.


• If you give someone a job, you can't guarantee they'll do it well; If you give someone two jobs you can guarantee they'll do both badly


• Every meeting should start with a statement on its purpose and context, even if everyone in the meeting already knows.

A reading list for our developers

An idea I'm thinking of trying to get implemented at our place is a required reading list for all our developers. A collection of books that will improve the way that developers think about their code, and they ways in which they solve problems. The company would buy the books as gifts to the employees, maybe one or two every three months.

Some questions though:

• Is it fair for a company to expect its employees to read educational material out of hours?

Conversely:

• Is it fair for an employee to expect to be moved forward in their career without a little bit of personal development outside the office?

If anyone has any books out there that they'd recommend - please let me know. Otherwise, here's my initial ideas - the first three would be in your welcome pack:

Update:Gary Myers came up with a good point, being that any book should really be readable on public transport. That probably rules out Code Complete (although I read it on the tube, I can see that it's a little tricky), but Design Patterns and Refactoring to Patterns are small enough I reckon.

Unfortunately, Code Complete is a really good book that gives a lot of great, simple, valuable advice. Does anyone out there have any other suggestions for similar books?

Update 2:Andy Beacock reminded me of Fowler's Refactoring, which really should also make the list.

Update 3:The development team have bought into the idea and the boss has been asked. In fact, I'm pretty pleased with the enthusiasm shown by the team for the idea. I can't see the boss turning it down. Interestingly though, someone suggested that Code Complete go onto the list...

In this order:

• Extreme Programming Explained - Kent Beck


• The Pragmatic Programmer - Andy Hunt & Dave Thomas


• Pragmatic Unit Testing using JUnit - Andy Hunt & Dave Thomas



• User Stories Applied - Mike Cohn


• Software Configuration Management Patterns - Steve Berczuk


• Refactoring: Improving the Design of Existing Code - Martin Fowler


• Refactoring to Patterns - Joshua Kerievsky


• Design patterns : Elements of Reusable Object-Oriented Software - Gamma, Helm, Johnson, and Vlissides


• The Mythical Man Month and Other Essays on Software Engineering - Frederick P. Brooks

Ruled out because of their size:

• Code Complete - Steve McConnell


• Head First Design Patterns - Freemen(s), Bates and Sierra

Database Build Script "Greatest Hits"

I know its been a quiet time on this blog for a while now, but I've noticed that I'm still getting visitors looking up old blog posts. It's especially true of the posts that relate to "The Patch Runner". Many of them come through a link from Wilfred van der Deijl, mainly his great post of "Version control of Database Objects".

The patch runner is my grand idea for a version controlled database build script that you can use to give your developers sandbox databases to play with as well as ensuring that your live database upgrades work first time, every time.

It's all still working perfectly here, and people still seem to be interested, so with that in mind I've decided to collate them a little bit. Basically provide an index of all the posts I've made over the years that directly relate to database build scripts, sandboxes and version control.

So, Rob's database build script 'Greatest Hits':

• On the basic idea of building a database in an agile manner


• On how you might start putting together a version controlled database build script


• On how you can organise patches to reduce the pain of a rolling back changes


• On the arguments between table-centric and patch-centric database build scripts


• On what automated build scripts give you


• On having the build script be able to tell when something goes wrong, and stop


• On how you can use your automated builds to give you a sandbox


• On why your DBAs shouldn't burst into tears when you tell them you need a database for each developer


• On how you database build script can work with you version control tool


• As well as: a presentation given to the UK OUG

All of the posts describe processes and patch runners that are very similar to those that I use in my work every day. I started playing with these theories over 3 years ago now and there is no way I'd go back to implement database upgrades the way I did before.

However, I'd LOVE to hear ideas on how things can be improved. I'd be amazed if my three year old thinking was still up to date!

Technorati Tags: oracle,, rdbms,, software,, development,, upgrades,, Robert+Baillie

Wow

And you think software patents are bad...

China Regulates Buddhist Reincarnation

Problems with CVS removes?

Accidently removed a file in CVS that you want to keep?

Sounds like a stupid question, because when you know the answer to this problem it just seems blindingly obvious,
but what if you've issued a 'remove' against a file in CVS and before you commit the remove you decided that you
made a mistake and still want to keep it?

I.E you issued (for example)

 > cvs remove -f sheep.php

But not issued

 > cvs commit -m removed sheep.php

I've heard work arounds such as:

• Edit the "entries" file in the relevant CVS directory in your workspace, removing the reference to the file.
  This makes the file appear unknown to CVS.
• Perform an update in that directory. This gets the repository version of the file and updates the "entries"
  file correctly

All you actually need to do is re-add the file:

 > cvs add sheep.php

 U sheep.php
 cvs server: sheep.php, version 1.6, resurrected

When used in this way, the add command will issue an update against the file and retrieve the repository version of the file.

A word of warning though, if you had uncommitted changes in that file before you issued a remove, CVS isn't going to recover that for you...

How about if you've removed a file, but your version of the file is out of date and so you can't commit it?

So you've issued the following:

 > cvs remove -f sheep.txt 

 cvs server: scheduling 'sheep.txt' for removal
 cvs server: use 'cvs sheep' to remove this file permanently

 > cvs commit -m removed sheep.txt 

 cvs server: Up-to-date check failed for 'sheep.txt'
 cvs server: correct above errors first!

You can't issue an update because you get the following:

 > cvs update sheep.txt

  cvs server: conflict: removed sheep.txt was modified by second party
  C rob_tmp.txt

Again, add the file.

 > cvs add sheep.php

 U sheep.php
 cvs server: sheep.php, version 1.6, resurrected

This gets you the most up to date version from the repository, that you can then check for changes (you wouldn't want to just remove it now that someone's added new content would you?)

Once you've convinced yourself that it's still a good idea to delete it, just issue the remove and commit.

Simple when you know how!

Can a change in execution plan change the results?

We've been using Oracle Domain indexes for a while now in order to search documents to get back a ranked order of things that meet certain criteria.

The documents are releated to people, and we augment the basic text search with other filters and score metrics based on the 'people' side of things to get an overall 'suitability' score for the results in a search.

Without giving too much away about the business I work with I can't really tell you much more about the product than that, but it's probably enough of a background for this little gem.

We've known for a while that the domain index 'score' returned from a 'contains' clause is based not only on the document to which that score relates, but also on the rest of the set that is searched. An individual document score does not live in isolation, rather in lives in the context of the whole result set.

No problem. As I say, we've known this for a while and so have our customers. Quite a while ago they stopped asking what the numbers mean and learned to trust them.

However, today we realised something. Since the results are affected by the result set that is searched, this means that the results can be affected by the order in which the optimizer decides to execute a query.

I can't give you a full end to end example, but I can assure you that the following is most definately the case on one of our production domain indexes (names changed, obviously):

We have a two column table 'document_index', which contains 'id' and 'document_contents'. Both columns have an index. The ID being the primary key and the other being a domain index.

The following SQL gives the related execution path:

SELECT id, SCORE( 1 )
FROM   document_index
WHERE  CONTAINS( document_contents, :1, 1 ) > 0
AND    id = :2

SELECT STATEMENT
  TABLE ACCESS BY INDEX ROWID SCOTT.DOCUMENT_INDEX
    DOMAIN INDEX SCOTT.DOCUMENT_INDEX_IDX01

However, the alternative SQL gives this execution path:

SELECT id, SCORE( 1 )
FROM   document_index
WHERE  CONTAINS( document_contents, 'Some text', 1 ) > 0
AND    id = :2

SELECT STATEMENT
  TABLE ACCESS BY INDEX ROWID SCOTT.DOCUMENT_INDEX                       
    INDEX UNIQUE SCAN SCOTT.DOCUMENT_INDEX_PK                         

Normally, this kind of change in execution path wouldn't be a problem. But as stated earlier, the result of a score operation against a domain index is not just dependant on the individual records, but the context of the whole result set. The first execution provides you a score for the single document in the context of the all the documents in the table, the second gives you a score within the context of just that document. The scores are different.

Now obviously, this is an extreme example, but more subtle examples will almost certainly exist if you combine the domain index lookups with any other where clause criteria. This is especially true if you're using literal values instead of bind variables in which case you may find the execution path changing between calls to the 'same' piece of SQL.

My advice? Well, we're going to split our domain index look ups from all the rest of the filtering criteria, that way we can prepare the set of documents we want the search to be within and know that the scoring algorithm will be applied consistently.