Friday, 12 June 2009

Spec thought for the day

Browsing around StackOverflow I came across a question about specifying binary files. One of the answers said that the Java spec for class files was a good example of how to do it.

So I went there to look and found this:

  ClassFile {

u2 constant_pool_count;
cp_info constant_pool[constant_pool_count-1];

}

and the following description:

constant_pool_count
The value of the constant_pool_count item is equal to the number of entries in the constant_pool table plus one. A constant_pool index is considered valid if it is greater than zero and less than constant_pool_count, with the exception for constants of type long and double noted in §4.4.5.

constant_pool[]
The constant_pool is a table of structures (§4.4) representing various string constants, class and interface names, field names, and other constants that are referred to within the ClassFile structure and its substructures. The format of each constant_pool table entry is indicated by its first "tag" byte. The constant_pool table is indexed from 1 to constant_pool_count-1.

and I wondered if this is a good spec what does a horrible one look like?

Granted, this is quite chatty, but when you read it for sense you get more and more confused.

It looks like a C structure, so let's read it like one… 

Why is the count one more than the number of elements in the array?  The array index starts at 0 when I declare one.  Oh yeah: the valid indexes are greater than zero (why omit the zero index?)—except for some long and double stuff, life's too short—and then the valid indexes are from 1 to count-1.

Whoa! where do they go? The declaration a[3] normally allocates three elements (indexes 0, 1 and 2), but here we allocate count-1 and index from 1 to count-1.  The last index would be invalid!??!

Aha!  We must be basing our arrays from one and not zero!! 

…and the count entry isn't a count really.

Ugh!

If this is a good spec my name is Edsgar Dijkstra.

Thursday, 2 April 2009

Install updates?

It's a few weeks now since I last posted about my new job.

Spring (in my step) source
    One of the nicest things that ever happened to me, being in a new (smaller and friendlier) company has boosted my energy, optimism and self-esteem. That, and free membership to the local gym, has made me feel younger! It is simply amazing what a challenge and a change (with, it has to be said, a wise and people-savvy company) can make to a person. [I still look the same age, though--you can't have everything.]

A few weeks ago (about six, now) we adopted Scrum working. (See picture below.)














This, in case you didn't know, is an iterative development structure that encourages short, development spurts, with clearly defined and effort-sized deliverable outcomes. These spurts are called Sprints and in our case are three weeks (elapsed time). [Of course, in my old place we couldn't have just `adopted' Scrum. This would have been hard to do without several levels of sign-off: and the running and scheduling of Sprint planning meetings would be very difficult indeed.]

Progress
    We just completed our second (full) sprint. (That's how I knew it was six weeks -- see?) I have to say that, normally cynical about these much-lauded `methodologies' (and having experienced--and even taught--a fair few in my time), I have found this one to be quite positive.
    Since the internal workings of a sprint are really up to the team (and they are relatively free to do as they please) we have been guided (by the team leader) rather than driven, and are still feeling our way. However, the nature of the beast is that teams are expected to learn for themselves what is good and bad about the process -- including how to estimate the team's tasks beforehand. 
    For us, that means we are still tinkering with how we deal with change: most of these are the usual--design changes, external dependency lapses, unexpected and persistent bugs, unplanned absence; and the answers are the usual ones--postpone design disruption (until the end of the sprint), re-order tasks to allow more external time (and plan tasks to negotiate with third parties), rally the `troops' to crack hard bugs once and for all, pull together to keep the sprint plan on target.
    In the case of a short spurt (the sprint), and well-defined and agreed tasks for that spurt, we find it is easier to apply those standard solutions. In every case the small tasks and sprint structure makes it easier:
  • postponing tasks is easier since there are enough small tasks planned to rearrange and even re-assign;
  • re-ordering is easy, even if there are inter-dependencies, since the short sprint meant that not too many were scheduled at once, and the dependencies are manageable;
  • rallying the troops is not hard, because only a week or so ago all the team members took joint responsibility for the deliverables--there is no shortage of offers of help.
After a number of these, too, the members of the team have worked closely and regularly and this makes joint responsibility easier to execute: we learn each others' skills. New guys learn more quickly and have a sense of achievement earlier. They become old guys sooner (and I mean that in the nicest possible way).

Distress
It is prudent of me to talk about the not-so-good things, or things for which the jury is still out:
  • the expectations of the product owner can be skewed, and not allow enough team experience before expecting (or trusting) tight estimates -- hopefully this is something that can be ironed out over time;
  • the team members have to work at close co-operation during the sprint (we are lucky to be all in the same room--although this could be a problem for a larger team);
  • learning what `hours worked', `task complete', `ideal hours' mean requires several sprints to iron out--and this can easily be disrupted by team personnel changes;
  • it is hard to do difficult things--especially if they require sustained, co-ordinated effort.
There are other niggles, but I have to be careful not to confuse genuine concerns with my natural tendency to be a Grumpy Old Man.
    More on the progress of this `experiment' later.

Meanwhile...
    Back at the (old) ranch I hear all is not happy: the large management structure, lack of technical autonomy (caused by lack of trust), and catastrophic disconnect between effort, achievement and reward, means that more and more (oftener and oftener?) I am hearing heart-rending bleats of discontent from my old friends. What they can do about it, I don't know, but I wish better for them.

Sunday, 15 February 2009

Re:sprung

Well, it has been a few weeks since I started at this place, and I promised an update.
It hasn't been entirely easy, of course, and I can't say I've fully found my feet yet, but it is still exciting and I'm still enjoying it. I guess that is good enough in this present economic climate; there are some I fleetingly met here who are no longer with us.
Just a week after I joined, there was a full company meeting. (Oh, the joy of having so shallow a corporate structure that the CEO was in the same room as me.) The company had to make savings of such-n-such per month; suggestions for savings were being taken now (from anyone); redundancies were inevitable; we will consult with each and every one of you over the next two weeks; those who are ear-marked to leave us already know this.
I was, understandably nervous -- I only just got here, and one of the criteria was length of service. Well, I'll get my coat. But it turned out, I hadn't known it, so maybe I wasn't going, and this was confirmed (in a personal interview) soon after (approx. an hour later).
It transpires that the percentage cut in our (little) company was only just higher than that for my previous (humungous) company. About twenty from the new firm were let go. I shudder to think of the number in the old place. I guess the procedure was a little slicker here -- it was all over in two weeks, and everybody had a say. In the old place, I hear there was FUD (and blood) but that, thankfully for my old colleagues, not many casualties in the UK Lab.
All in all, I'm happy to have moved. Although my chances of being snuffed were (numerically, at least) higher here, I think I might have been a casualty (early retirement forced) and although I missed a redundancy offer, I'm happier to have jumped rather than being pushed. I feel so much better about this place having made the decision myself.
And they seem to want me.
All we gotta do is make money this year.  Shouldn't be too hard :-)