December 23, 2003

Record Digital Telly on your Mac

Just found this product called the eyetv 400 which is essentially a box for getting digital terrestrial TV signals into your mac. The software that comes with it enables you to do most all those things you wanted to do with a TVR except it only recieves digital terrestrial. Downside is you have to watch it on your mac, but I'm sure there's ways to plug the Mac into the television again.

It'd be good if you could decode cable and other signals on it, but it doesn't do that... yet. I wonder how long it will be before they can work out a legal loophole or negotiate a deal with the commercial media pirhanas providers. Now that'd be a coup for the consumer.

Posted by Ant at 03:50 PM | Comments (1) | TrackBack

December 22, 2003

XPDAY - Mary Poppendieck, Tom Poppendieck - Lean Development - Tuesday 2nd December 2003

Waste is anything that doesn't create value for the customer. If the customer would be as happy without something, then don't do that something.

Value Stream Analysis - [Ant see this entry for a little more on that]

Increase Feedback
For fixing troubled projects, increase feedback at customer, team and management levels. A lack of feedback somewhere in the chain is the most common area for improvement in project debriefs.

Make change inexpensive. You can do this by:

  • delaying commitment
  • sharing partially complete design information
  • developing a sense of how to absorb changes
  • avoiding extra features
  • developing quick response capability
  • developing a sense of when to make decisions

Encapsulate variation
Group what is likely to change together inside one (code) module so that interdependencies are intrinsically linked.

Separate Concerns
A module should have only one responsibility. Don't make them dual purpose.

Avoid Repetition
Don't repeat yourself. Never copy and paste code.

Defer Implementation
Functionality doesn't have to be made till the order is recieved.

Deliver fast - rapidly, reliably, repeatedly

  • Wait till there's a need before you start to build. This is a good incentive or way of 'pulling' your requirements out
  • Don't 'push' with a schedule, you can't keep them up to date. Too much in a project's life changes and its wasted time updating them.
  • Make work self-directing through the use of a visual workplace whereby staff can see what state elements of the project are in
  • Rely on local signalling (like a Daily SCRUM or other methods for communication between team members)
  • Do small batches

Queuing Theory
  1. Steady rate of arrival (short iterations)
  2. Steady rate of service (test features immediately)
  3. Small work packages (integrate features individually)
  4. Reduce utilisation (you don't load servers to 90%... productivity in staff drops off exponentially after around 70-80%)
  5. Eliminate Bottlenecks (Everyone piteches in, when and where ever they are needed... yes this means multiskilled staff)

Lean means introducing a gating mechanism so that full capacity is never reached. Lots of half done stuff IS BAD and is the result of overloading. Just as a highway gets choked up when there's too much traffic, the same happens in a workplace when it is overloaded with work.

Build Integrity In

  • Perceived totality overall customer delight
  • Conceptual the system's components work well together

The way to build both perceived and conceptual integrity is to ensure all aspects of a business are included in the design process. There are 4 questions to answer which cover all aspects.
  • Why are we doing this? This is the business drivers question
    • The Vision
    • Success Model
    • Priorities
    • Capability
  • What needs to be done?
    • User Experience Design
    • Acceptance Tests
    • User Tests
    • Use Cases
  • How do we build it?
    • Programming methods (e.g. XP)
    • Technological platforms
  • How do we support it?
      Ask your support team to be involved in the design process

Empower the team
Kaizen Events are a way to bring a multidisciplinary team together to improve a process or product. The order in which they are done is as follows.

  1. Bring team together
  2. Set the challenge
  3. Brainstorm Solutions
  4. Present recommendations
  5. Decide at a "town meeting" (merely where all stakeholders are consulted)
  6. Implement immediately
To empower the team means that they must have the ability to move autonomously, without fear of reprisal for making decisions.

Posted by Ant at 05:57 PM | Comments (3) | TrackBack

December 10, 2003

XPDAY - Barry Fazackerly - Enterprise XP - Tuesday 2nd December 2003

Enterprise XP is the bastard child of DSDM (Dynamic Systems Development Method) and XP (Extreme Programming). DSDM is another agile process, however, like SCRUM it is more concerned with overall management than it is with programming practices. DSDM however pays fairly rigorous attention and deference to the business case behind a software development project. In this regard it is more of a business analyst or consultant's saviour rather than a programmers. Enterprise XP endeavors to deliver the best of both worlds.

Always ask 'What is the Business case? What is the Return On Investment? What are the measures of success so far as the business is concerned?' A lot of these concepts are captured in The Balanced Scorecard management approach.

The running order of an Enterprise XP project would look something like this

  1. Feasability Study
  2. Business Study
  3. Functional Model iteration
  4. Design and build iteration
  5. Implementation

Other links to interesting things about DSDM
Roles in DSDM
Core DSDM Techniques
Overall process lifecycle

Posted by Ant at 02:09 PM | Comments (0) | TrackBack

XPDAY - Martin Fowler - Keynote - Tuesday 2nd December 2003

Martin Fowler started controversially by announcing that he was a bit sick and tired the Agile world and process methodologies. He used book writing as an example and posed the question: When writing a book, do you do an outline first and then get steadily more detailed? OR Do you just muck in and get busy writing detailed sections and string them all together later? Both methods are 'successful' and merely the personal styles of two different authors. How do you objectively measure the success of the outcome of either of these methods? Isn't it completely subjective? To what do you compare or measure? [Ant - Here I would suggest that perhaps setting your own success criteria is enough providing you do so before you set out to do the work].

Martin is more interested in knowing what makes good software design and how to achieve good software design. SWEBOK (SoftWare Engineers Body of Knowledge) is attempting to define what a software engineer should be knowledgeable about. What would a software university curriculum look like? Analysis, Construction, Design, Testing, etc.

The practice and science of Engineering separates design and construction. Agile, especially XP, does not. Agile advocates doing design and construction together so that each informs the other [Ant - this is only possible because the only cost of building code is man hours and not materials. If physical construction was 'Refactorable' would we engineer and build together too?] Design can be an evolutionary process. UNIX is an example of successful evolutionary design [Ant - although, is the success of UNIX due to the fact that it's free, therefore there is a pretty natural incentive to adopt and grow it or is the success of an evolutionary design that draws people to it?]. Testing, refactoring and continuous integration allows evolutionary design to happen. XP has these three factors that enables evolutionary design to converge.

Only design for the current set of requirements. Future proofing or anticipatory capability isn't so good because extra features and code complicates the system, thus crippling future efforts to adapt and extend the system later. Keeping it simple will enable evolution.

Evolutionary design can work because there are people on the team, willing and able to do it. Teaching design is about showing others how to see problems first. Then over time and apprenticeship, the art of making solutions to the problems can be learned.

You can tell when evolutionary design is happening because the team is motivated, code is being thrown away and the team can freely say 'this isn't working, lets change it'.

Posted by Ant at 12:52 PM | Comments (0) | TrackBack

December 09, 2003

XPDAY - Richard Watt, David Leigh-Fellows - Acceptance Test Driven Development - Monday 1st December 2003

How does a coder know when they are done? The natural tendency for a developer is to continue to perfect a piece of code for long after it has attained an acceptable level. The Unit Test ascertains whether a unit of code works. A Functional Test is used to ascertain whether a group of units are working together to satisfy a desired function. But these are both simply testing that the code is working in a manner that the developer intended. The Acceptance Test asserts the conditions of acceptance set by the customer or designer. They are less concerned with finding imperfections in code as they are with identifying the result of an imperfection. Acceptance tests relate better to requirements or stories than they do to units or objects at code level.

Acceptance tests are a way for the developer to know when they're done. Where automating acceptance tests is achievable, this should be done. A developer can keep working until the testing application gives 'the green light'.

Acceptance tests should be written at the same time as stories are specified. This helps to set the goal posts for and aid in estimating particular functionality for all disciplines involved in the process of designing and building software.

Acceptance tests are hard for many reasons. The customer is involved in defining the test. They are not always adept at structuring such a test framework and will thus need guidance on this. Acceptance tests raise the level of quality assurance support required on the project team. Writing the tests are time consuming. Maintaining the tests is also time consuming and requires careful management and organisation to ensure this is as efficient a process as possible. Setting a common framework for testing can be difficult across multiple work streams. So, acceptance test driven development is not an easy road, however it is worthwhile as it ultimately saves time, eliminates waste and increases quality.

A typical chronology for an acceptance test driven framework would look like this:


  1. Select candidate stories for iteration or development
  2. Write the acceptance test skeleton for each
  3. Sense check the candidate stories
  4. Using the iteration planning workshop as a starting point:
    • A small multidisciplinary group takes a few stories aside
    • The group lists the subtasks associated with each story and then provides an estimate on how long this will take to do
    • The group then presents back the subtasks and estimate to the wider group for critique

  5. Check story dependencies and estimates
  6. Pick highest value group of stories
  7. Agree stories for iteration

And there you have how Acceptance Tests should be integrated into an XP process.

Posted by Ant at 03:35 PM | Comments (0) | TrackBack

December 08, 2003

XPDAY - Sean Hanly, Duncan Pierce - Introduction to XP - Monday 1st December 2003

Values of XP

  • Courage = Get on with it. Be honest about your abilities. If it's not working, change it, refactor it, throw it.
  • Simplicity = Keep all things as simple as they can be. Investment in XP products is incramental.
  • Feedback = Monitor performance, inspect and adapt. Measure early returns.
  • Communication = Focus on info that matters, don't do unnecessary documentation.

Agile is a mindset
Agile is about making incremental investments small changes to serve longer term goal. Nothing Agile is done in massive increments. So, changing to an agile methodology should be the same. Small incremental steps toward a better solution where each step has been evaluated for success. Change one thing at a time, do things simply, ask 'what already works?'. There is already good in what you do, don't throw it all away. Make a series of small process changes. Using XP is based on these principles - get feedback, measure benefits, inspect, adapt.

When prioritising features, look at which will make for early returns and assess which of those deliver most value to the customer.

When designing and building, see good enough, not perfect (this pertains to the type of feature, rather than the quality of workmanship).

Organic processes work, not just the mechanical and systematic. Order within teams can rise from chaos if the team is empowered to organise themselves.

Don't be afraid to measure progress, make it visible and have courage about honesty around it. Progress indicators are only as valid as the last measurement. Assess the progress over one 'time box' or 'iteration' and then estimate the next based on progress or 'Velocity' of the last.

Planning
In XP there are two types of planning sessions. One for each iteration, and one for each release. When using XP you assume that you are not going to release full functionality in the first release, but build it up over a series of releases. The Release planning meeting should have the 'Customer' (This is a term used within XP to denote the sponsor of the project), developers, tester(s) and an interaction designer all present. Each requirement is captured on an index card as an abstract description of something that the system will provide. Each of these estimated in terms of required effort and value. One effort unit is usually equated to a perfect day's effort with no distractions. This unit is then given an arbitrary descriptor (e.g. Gummy Bear) to abstract future indication of velocity away from any expectation of time scale. The value indicator equates to the relative importance of each requirement over the others. Iteration planning involves writing acceptance tests (even if they are not perfect) for each story and ordering the stories according to value and effort. In this case, the team must balance what can be achieved in the iteration with which story has the most value. Where possible, acceptance tests should be automated with development and refactoring carried out only until the unit of code passes its test.

A good story looks like this

  • Independent
  • negotiable
  • valuable to the customer
  • estimable
  • small
  • testable
Measure a story according to whether it increases or protects: Cashflow, Profit or Return on Investment. Each story should have four identifying attributes. Story Name, Acceptance Test(s) name and location, Effort estimate and Value Indicator.


Acceptance tests
Tests for enabling the project team to know when they are done are a crucial and useful to aid in setting targets. There are three levels of test. Screen level tests cannot be automated and involve user testing for comprehension and visual checking by the design team to ensure they are as specified. Interaction tests can be automated and test whether certain use cases work, technically. Engine tests are base level code and can be automated. A tip for writing all tests: make the language and labeling as consistent as possible, as far up as the customer level and as far down to the object (code) level. This will make less a need for documentation and aids communication within the team.

Posted by Ant at 05:29 PM | Comments (0) | TrackBack

XPDAY - Mary Poppendieck - Keynote Monday 1st of December, 2003

Mary's talk mainly focussed on the wider issue of productivity and engendering it within a workforce. She opened with a statement that productivity had a direct relationship to standard of living due to increased profits. Increased profits are derived from increased sales and history has many examples where this is evident.

The first steps to increasing overall profits within an organisation is to focus on the core business practices and work toward being more productive than the competition in these areas. Then work on non-core business practices and match the competition's performance on these.

Being productive does not mean sacrificing quality. You could improve speed and decrease overall quality or value and this would not be increasing productivity. Productivity is about putting the same effort into something and getting more out of it for changing the method in which the work is done. Or being able to charge the same amount for doing less work.

We can be productive by either reducing direct cost (i.e. what a client would pay for) or reducing indirect cost (i.e. streamlining processes and methods). The primary way to reduce direct cost in software development is in building only functionality that is required. Usually 80% of software product functionality is infrequently or not used. Each piece of functionality should have its return on investment measured and then only those yielding highest value should be built. Do the minimum marketable features then release. "Release early, release often" moves profit forward in time thus paying for future releases.

Value Stream Mapping is a good tool for analysing the way in which a business spends its time. It is derived from Japanese manufacturing process analysis. It is basically done by stepping backwards through a process and documenting time taken to do a task and time wasted in between tasks.

Overall, success should be measured not per employee, but the increased productivity of the organisation as a whole. There is a Japanese term 'Keiretsu' which encapsulates the notion of a cooperative group of related companies supporting one another. Productive for a software product can be measured by the increased revenue in the supported business per dollar spent by the IT organisation charged with maintaining it. To help design for this, it is very helpful to have those who will be supporting the product from technological through customer service, to be involved in the design effort.

Other books from which lessons learned in the manufacturing sector can be taken here. More on Mary and Tom Poppendieck's work here

Posted by Ant at 03:04 PM | Comments (0) | TrackBack