Jotting #6: miniSPA 2007 – Scoping Game


In this session we played a little game usingĀ  a pot several million pounds (fake, of course) and some features to decide whether and when to implement a re-usable features across several similar products.

Note: I don’t like the term re-usable very much. Either something is usable or not. If it is a usable API and I can inject system-specific dependencies it’s still not re-usable but more usable and well refactored.

In many ways, this is a variation on portfolio management and by adding the necessary input parameters (likely costs and revenue streams, uncertainties and probabilities) it becomes mainly a mathematical exercise to work out the numbers. In the end, you still need to make a proper decision which products you want to advance and that often requires some gut instinct. At least the exercise can weed out the worst choices.

Nice exercise but I don’t think I’ll took much home from it.


Jotting #5: miniSPA 2007 – Collaborative Workspaces


At the recent miniSPA conference Mike Hill (Rachel Davies was on holiday) from Agile eXperience led a session on collaborative workspaces; in the first part in each group we gathered all kinds of bad experiences; in the second part we tried to design a workspace we would like to work in; and in the final minutes we went round each group’s design and discussed it shortly. The results were remarkably similar.

Bad Workspace Attributes

We quickly came up with a number of factors that we had experienced that were detrimental to a good and productive environment:

  • Team spread across
    • the office with other groups,
    • the floor (different offices),
    • the building (different floors),
    • different buildings,
    • different sites, cities, countries, timezones, …
  • Furniture
    • small desks,
    • bad chairs,
    • no shelves,
  • Amenities
    • no tea/coffee,
    • no white boards,
    • no privacy when dealing with private matters,
    • no meeting rooms,
  • Environment
    • too hot (in summer),
    • too cold (in winter),
    • too much air-conditioning,
    • not enough air-conditioning,
    • air-conditioning directed at your desk,
    • too much noise from other groups (sales!),
    • smelly,
    • bad or insufficient lighting,
    • intruding security measures (accompanying you anywhere and that means any where!)
  • Set-up
    • no PC
    • under-powered PC,
    • small screens,
    • bad infrastructure (networks, …)

I am sure there were more but I can’t remember them all. I’ve tried to group them a bit.

Good Workspace Attributes

In many ways, these are the opposites of the bad ones.

All of us agreed that a team should be grouped together in one place, with sufficient space left to add more team members, to allow for pairing, to enable daily standups and small short discussions.

Desks should be arranged in a manner that allows easy interactions between the team; maybe adding round tables for small discussions or customer interactions. Adding some natural light and plants can improve the space.

Meeting rooms should be available for longer discussions, esp. when these would disturb others in their concentration.

There should be enough space (whiteboards) to note down tasks, ideas, etc. that everyone can see and use.

You need a break from work to get a cup of tea (I don’t care much for coffee!) or coffee; a cafeteria should be nearby for such breaks but also for lunch (it’s such a bad habit to eat your lunch at your desk, a habit I’ve found more prevalent in the UK than elsewhere).

You sometimes need to deal with private matters during working hours (your bank, insurance, email, …). Hence, you a need a private space to deal with these, best in a customised or a small meeting room.

I am currently lucky that at my customer site most conditions are quite OK; we mainly lacking space for white boards.


Informative Workspace Repository

The Programmer’s Bill Of Rights which is more concerned with the physical world than the Developer’s Bill Of Rights

Productivity gain with dual monitors is advocated here and in many other places.

Jotting #4: Revealing intent …


Java does not support Design-by-Contract (pre- and post-conditions, invariants) and asserts are really just a weak placebo.

Nevertheless, you can at least indicate your intentions to some degree with labels:

public void foo(Bar theX, ...) {
   pre_condition: { vetoArgument( null==theX, "Bar argument is null" ); }
   // some code
   post_condition: { ... }

where vetoArgument is some helper method to throw an IllegalArgumentException or the like.

Labels are a somewhat under-used feature of Java. But it’s still not the full DBC feature I’d like to see. Annotations will not be able to substitute for proper built-in language support. How long do we still have to wait?