Tuesday, November 27, 2007

consistency, integrity and exceptions

I was blaming myself today talking about consistency and integrity without remembering the exact definitions of it. I just remembered that there are some interesting differences between them. What I meant was a definition like Consistency and Integrity.

My point was that exception handling and especially the concept of design by contract could be seen in a similar context. I tried to argue that violating a design by contract-rule(pre/post/invariance) is like violating the 'programs internal consistency'.

But as Consistency and Integrity is just clearly defined in the context of data it seems that my derivation doesn't make sense.

In personally would say a 'program consistency' is maintained as long it's internal state doesn't contain any contradictions. Furthermore a 'program integrity' is maintained as long as the programs internal state does reproduce all related external state correctly.

Following that definition one could say that 'program consistency' can be checked by the design by contract-technique but 'program integrity' cannot. 'program integrity' cannot be checked at all by a program.

Tuesday, November 20, 2007

Expresso - Regextool and others

I used Expresso first time today and I liked it much more than the Regulator that I've used up to now . The 'Regex Analyzer'-View and the 'Search Result'-View display the Regex and the matches as a tree and this helps me a lot in understanding Regex's.

I've always wanted to mention that I'm using a visual studion plugin named Cool Commands. I'm using just one command of it: 'Collapse All Projects' . It collapses my 20 projects in a solution with one click! Will the brand-new visual studio 2008 support that out of the box?

Sunday, November 11, 2007

Scrum and xp from the trenches

I've just finished reading Scrum and xp from the trenches. To see that everybody trying to adapt Scrum is running into the same kind of problems perks me up. Scrum like its written in the books is quite dogmatic but this book gives some good pragmatic advices.

Two remarks about what I've read related to the project I'm currently working on:
  1. We are trying to adapt a simple estimation method where we compare the complexity of use-cases choosing a number from 1,2,3,5,8,13 ... One use-cases is randomly chosen as a 'reference use-case' and all other use-cases are estimated by comparing it with the 'reference use-case'. Estimating use-cases is a reoccurring activity in our project and the problem is that every team member has always to remember a 'reference use-case' in its details to be able to give an estimate to another use-case. Using that method we had a kind of 'currency' to determine the real value in time (how many hours is one point?). Calculating 'Total Points in a Sprint' * 'currency' gives us the total amount of working hour of the team in a Sprint.
  2. Maybe we should switch over to a system where 1 Point is '1 ideal programming day'. We could still use an exponentially growing number like 0.25, 0,5, 1,2,3,5,8,13... to address the growing uncertainty. The drawback is that we might have to deal now with number less than 1 but on the other hand it gives us a better feeling on how much work is related to one certain number. Furthermore our 'currency' gets a 'focus factor' and that's easier to understand by managers and addresses directly the question why we cannot deliver as fast as in an 'ideal environment'. I guess comparing use-cases according to their complexity is a good choice for a single 'planning-meeting'. However in our case where we estimate a small number of use-cases monthly, it's better to pin the points to '1 ideal programming day'.