Visible Continuous Build Display in 10 minutes

1) Find an old PC with a monitor

2) Install HTML Screen Saver

3) Configure screen saver to point at your your continuous build dashboard

4) Turn off any monitor power save features

5) Tweak your build dashboard using colours to represent build status that can be easily seen from a distance e.g

  • Green – Last build passed
  • Blue – Build in progress
  • Red / Pink – Last build failed

6) It’s also useful to be able see a timer indicating how long the build has been at a particular state

  • It’s useful to see how long the builds been broken
  • It’s also useful to see how long a build has been running. Occasionally builds hang, so if it’s been building longer than is typical then it’s a trigger for someone to investigate.
  • In fact you can also flag when the build is taking too long in general

Scheduling stories to avoid hangover

Mike Cohns post prompted me to blog on what my team has been practicing for the last few iterations.

For quite some time (over a year) our team had not been very good at delivering on our iteration commitments, and frequently started new iterations with hangover from the previous iteration, creating a snow ball effect of hangover leading to further hangover. We tried flagging stories at risk of expanding (green monsters) but it didn’t have any noticeable affect on delivery or reduce typical hangover.

For the last 4-5 iterations we’ve followed a couple of simple rules:

  • Limit the size of stories
  • Play stories in order of size, biggest first

Limiting the size of stories

Important for a couple of reasons:

  • Bigger stories tend to be riskier and hence more likely to slip.
  • Larger estimates are more likely to be out by a larger amount in actual terms than smaller estimates

Typically we used a max points value about half of what a pair could deliver in an iteration, and stories over this size would be split.

Playing stories on order of size, biggest first

Generally it’s easier for the team to pick up small stories towards the end of the iteration and still deliver them. The Rocks, Gravel, Sand and Water analogy to filling a container in the comments in Mike’s post is useful. On the last day I can fit some sand and water in, but rocks and gravel don’t fit. I feel deferring larger stories later in an iteration increases the risk of hangover.

    So far after 2-3 months of applying these rules whilst the team haven’t always delivered everything committed to, hangover is certainly less of an issue.

    Class Role Names

    A colleague and myself have just been brainstorming a collection of possible Class role names for domain objects within a Mortgage Origination system. This all stemmed from the overloaded use of the term ”Service” in our application, which had come to mean any of the following:

    • A web service
    • A web service client
    • A component facade
    • A calculator / generator / factory internal to a component

    With the help of dictionary.com’s thesaurus we came up with the following  list of roles we might use in the future as we develop and refactor.

    Creation

    • Builder
    • Generator
    • Creator
    • Assembler

    Selection / Evaluation

    • Selector
    • Chooser
    • Picker
    • Matcher
    • Decider
    • Assessor
    • Evaluator

    Derivation

    • Calculator
    • Counter

    Aggregation

    • Aggregator
    • Merger
    • Combiner
    • Assembler

    Decomposition

    • Decomposer
    • Splitter
    • Segmenter

    Sorting

    • Sorter
    • Ranker

    Starting

    • Launcher
    • Starter
    • Invoker
    • Requestor
    • Notifier

    Receiving

    • Listener
    • Subscriber
    • Activator
    • Handler
    • Receiver

    Authorisation

    • Authoriser

    Development Tools

    Something to look back in a couple of years, here is my current development environment at work:

    IDE : Eclipse

    Haven’t looked at the competition for a while, but Eclipse is still going well. One reason we settled on it is that it can be checked in to source control in it’s entirity so new developers start off having identical IDE configurations.

    Source Control : CVS

    CVS has really had it’s day, and our now fairly large codebase is now causing CVS various issues (performance, tagging). Largely political reasons why we’re unable to switch to subversion at present (ClearCase is the corporate push and CVS is preferable to ClearCase).

    Unit Testing : TestNG + Hamcrest + JMock

    Has worked very well for us, although looks like alternatives to Jmock (e.g. Mockito) are worth a look now.

    Smoke Testing: Selenium

    Selenium can be a productivity drain when the build starts failing due to timing and other selenium issues.

    Code Analysis : Checkstyle, PMD, Findbugs, Cobertura, Macker, Sonar

    Good combination these, especially when bundled together using Sonar.

    Continuous Integration : CruiseControl

    Been using for 3+ years and still no real driver to upgrade it, let alone switch to something else. Gets the job done.

    Build : Maven + Ant

    I’m in the camp where I like maven 80% of the time and hate it for the other 20% where you need to break out of the box.

    Issue Tracking : JIRA + Mantis

    Having come back to JIRA recently, it’s a pleasure to use. Hopefully we’ll complete the Mantis migration to JIRA shortly.

    Wiki : JspWiki

    Again this on does the job, it may not be the flashiest, but it gets the job done.

    Team Blog : Wordpress

    What more do I need to say.

    Virtualisation: VmWare

    Use of any virtualisation software with todays complex software systems is a must. Probably one of the biggest productivity wins having all the developers use standardised virtual environments for databases, app servers and third party software.