Isotoma Limited

This book is almost entirely concerned with technique. As such unless you, personally, are going to be reading or writing Use Cases, then you probably do not want to read this book — it’ll bore the pants off you.

Having said that, if you are directly involved in Use Case work, this is a vital addition to your bookshelf. You’ll gain more from the book if you have written Use Cases previously, but if you haven’t you will still get a lot out of it.

The author first states a number of things I wish I had known when I first started using Use Cases seriously as part of system documentation. First - there are many different kinds of use case, and you need to decide which kind you are writing. Second - you need a template. A lot of the work I do using Use Cases is initially for requirements discovery - it forms part of the requirements documentation but is in the author’s words “casual” as opposed to “full dress”.

The author presents a full-dress template, and boy is it full-dress. I’m going to use a few of these things, but certainly not all of them. The casual version has no structure at all, except for English grammar. Normally the actor and extensions are provided by the modelling tool. Later in the book he goes through the different uses for a Use Case (hah) and shows a few different templates for the different purposes. My normal template is very similar to the one he recommends for Requirements Elicitation, which makes sense. We are a high-communication team, so we don’t need to go into much more detail than that often - we capture detail straight into code.

The modelling tools issue is a difficult one. You can have pretty UML diagrams using the Jacobson notation, but it’s the content of the Use Case that matters, not the graphics. In many ways I think modelling tools distract from Use Cases with their ellipses and stick men. The author clearly prefers text-only tools for producing Use Cases, and I can quite see his point, certainly having used Rational Rose a few years ago, which had horrendous support for Use Cases. That said, I personally find the diagrams to be a useful way of visualising groups of Use Cases and I’ll continue to use (MagicDraw)[http://www.magicdraw.com] (which I think is excellent incidentally).

One of the things the author says that rings very true for me is about Failure Handling. This is so important, I’ve started thinking it’s almost the most important thing in a Use Case. If you don’t consider failures early, you end up considering them far, far too late. Even if you only write a one paragraph use case, have a Failure section, and think about how the case can fail. You will not regret it.

The author describes quite well what the bits of a use case are, and why you might want them. He goes through several different ways of describing them, and this is clearly targeted at people with no experience with Use Cases at all. He presents a whole number of practical tips, far too numerous to go through here, that deal with the practicalities of writing use cases. That makes this a useful reference work too, when stuck with a problem of structuring or expression.

The author introduces some of this own icons that identify various aspects of scope. This is an interesting idea, and does help with the problem that you often end up with the same Use Case written several times for different levels of system scope. I’m not sure if i’d use his icons, to be honest, but I’ll certainly be more explicit about scope, after seeing how well it seems to work for his examples.

One of the great benefits of this book is the plethora of examples, many dealing with corner cases and confusing aspects in Use Cases, and this section is no exception with good examples for different levels of scope and for multi-system designs, with useful tips on how to approach these issues.

This is a really excellent book about a surprisingly difficult subject. The utility of Use Cases is often detracted from because of the difficulty people have in producing them, but using this book should seriously improve the quality of any Use Cases you produce.

Posted by Doug Winter at 02:50 PM | Permalink | Comments (0)

I’ve been struggling for a while with the fact that no one outside our rather close knit group of very Internet savvy friends and colleagues has heard of Flickr, del.icio.us, Technorati, digg or any of the other web 2.0 “revolutionaries”. I heard Joshua Schachter speak at Carson’s Future of Web apps and he referred to his lead users as The Priesthood. I’m honestly starting to wonder whether there is anyone in the choir for these priests to preach to, let alone anyone in the congregation.

While mulling this over in the shower this morning I got to thinking specifically about writely. In many ways writely more than any of the other services can be seen to sum up web 2.0. It suddenly appeared with huge fanfare and was almost immediately acquired by no less than Google (at least that’s how it looked to the external observer). At the time there was vast amounts of blog and media hype around the service - literally all the way from “Why writely matters” to “Why writely doesn’t matter”. It’s easy to get caught up in the hype… Yes ODF is exciting, as is a neat Javascript interface providing a WYSIWYG editor, but it’s also worth noting that writely could actually be deployed in about 15 minutes with one of kupu, FCKeditor or Tiny MCE and some storage on Amazon’s S3 platform.

This article on the current situation from a Venture Capitalist’s point of view sums it up perfectly for me. 25,000 beta users means you got a good review on Techcrunch. It doesn’t mean you’re going to change the world. The list of all things web 2.0 from March this year is a sobering thing. There’s too many to count, but just look how long it takes to load and how small your scrollbar gets for an idea.

Don’t get me wrong. I strongly believe there is space out there for new and fantastic applications, but then there always has been. Doug and I were part of the team that wrote the UK’s first online supermarket (for Sainsbury). Back then it was absolutely bleeding edge to connect a web server to a database. The technologies that make up Web 2.0 might be bleeding edge now, but they won’t be for long and it certainly doesn’t mean the particular application will make it. Ours didn’t (Tesco beat the living daylights out of us) and by today’s standards we were built on solid foundations - first mover into an easily identifiable market with the backing of one of the largest brands in that sector and some very strong tech.

Two final thoughts… It’s worth remembering that Flickr isn’t even Yahoo!’s largest photo sharing service, let alone the largest on the Internet. It’s also worth remembering that despite what we often think Google does not own the Internet.

Posted by Andy Theyers at 06:58 PM | Permalink | Comments (0)

An excellent interview with Werner Vogels, Amazon’s CTO. It’s very good to see someone doing things differently and so successfully, especially when it comes to structuring their business.

Of course there’s a lot of cheerleading in there, and I’m sure they suffer from a lot of organisational problems that he doesn’t talk about - but all that said, the way they have aligned their business architecture, personnel structure and technology architecture along with their strategy is a great example of proper strategic thinking.

His emphasis on testing being the really difficult thing also bears out my own experience with large distributed systems - just orchestrating a valid test can be a huge amount of work, and validating the test’s synthetic loads against real world load is a very skilled job. It’s worth putting the hours in here though.

Posted by Doug Winter at 09:24 AM | Permalink | Comments (0)

Fascinating news from Brendan Eich (CTO of Mozilla and creator of Javascript). The first deployment of Javascript 2 is expected by middle of next year and, to quote a piece in PC Welt: For the future, JavaScript will follow Python. “We’re going to learn from Python. JavaScript is pretty close to Python,” Eich said. Python 2.5 is being tracked, he said..

The two languages are natural companions; it really highlights the architectural success of projects like Mochikit and Nevow (and LivePage in particular)

Posted by Andy Theyers at 08:13 AM | Permalink | Comments (0)

Planning and estimating is by far the most difficult part of any technology project, and this book takes many of the lessons of other Agile approaches and applies them specifically to planning and estimating in an eminently practical way.

Introduction

The author is an engineer and this book is clearly written for other engineers. The writing style is unapologetically terse, forthright and wonderfully pedantic, from the use of the international currency symbol (¤) used throughout when referring to money to a religious alternation of personal pronouns. The book is larded with common sense, and although some parts are overly systematic in my view (such as the financial planning parts), there are many very practical suggestions that obviously come from direct personal experience.

The author also clearly knows whereof he speaks - Chapter 2 Why Planning Fails is an excellent account of the many problems with IT planning such as Activities Don’t Finish Early (Parkinson’s Law), Lateness Is Passed Down the Schedule (only one thing needs to be late to make a project late) and Activities are not Independent (if one thing takes longer than you expected, then probably all of them will).

The one that in my previous career has always plagued me is Estimates Become Commitments. Anyone who has been trapped by that last bugbear will know the greatest problem with implementing Agile approaches anywhere - how to keep all stakeholders on board. This book contains a lot of useful practical information to help avoid assumed commitments and how to keep your customer happy even when there is a lot of uncertainty.

The author puts the problem succinctly An agile project is more like a timed race than a 10-kilometer race: run as far as possible in sixty minutes… the agile project team knows when they will finish but not what they will deliver. This book is very strong is providing an overall structure for development activities that includes planning and estimating exercises as a core part of initiation and of each iteration, and in a way that should help maintain stakeholder confidence.

Estimating Size

This is the core of all useful software planning techniques, and one where things often fall down immediately. The author starts with a method of assigning Story Points to user stories. These are just relative weights - a 2 indicating that a use case is twice as hard/complex/long as something with 1 point. He then introduces a system for determining a team’s velocity by adding up the story points they complete in an iteration, and using that for forward planning.

This is a nice idea, and neatly deals with the problem of Activities are not Independent (i.e. if one feature is harder than expected, then probably all of them are).

The author also discusses Ideal Days, which are perhaps a more natural way of estimating size for most people. Although he presents the idea in detail the author clearly strongly prefers story points, and he is persuasive. The concept of velocity is a strong one, and we’ll be using this approach ourselves.

Planning for Value

This section of the book discusses a wide range of different concepts, all of which can be useful depending on the sort of projects being worked on.

A large part of this section discusses methods for estimating the financial value of a software project, to allow a go/no go decision to be made. This section is very theoretical, with a discussion of, for example Net Present Value versus Internal Rate of Return. I have my doubts as to how useful these things are in practice - the results are eminently massagable and much of the important part of a go/no-go decision is an intuitive belief in the proposal. What these methods do provide, I suppose, is a mechanism for justification that’s very difficult to argue against. This may be useful for an individual, but regular use of these sorts of exercises are often a sign of a disfunctional organisation. Handle with care.

There is some good stuff in this section too though - using Kano’s Model of Customer Satisfaction explicitly as a way of prioritising user stories is a great idea, and the way of structuring this into a survey is the best systematic way of involving a user community in planning that I’ve seen.

There is also some good guidance on splitting user stories here. The user stories the author uses are very terse, and so harder to split. He provides some good guidance on how to make them small enough to fit into an iteration.

Scheduling

This section presents an overall way of structuring activity into a Release Plan, prioritising stories, assigning them to iterations and then breaking stories into tasks. There is also some good guidance on how tasks should be structured, and he covers some of the key agile issues such as automated unit testing and bugfixing within iterations.

He also makes the key point that dependencies don’t matter - this is something I have found myself, and is quite counter-intuitive: because of automated user testing you need to build test versions of many modules anyway, to provide controlled data, so the unavailability of the real thing is irrelevant - your stub code is in itself valuable. It is sometimes even useful to build in this way, because it forces you to consider module APIs independently of implementation (one of the major advantages to the unit testing practice as a whole in fact).

The section on “Uncertainty” has some excellent points for how to cope with applying these techniques in the real world. The biggest problem we have as agile developers is working in an environment where some sort of up-front commitments are required. Using the techniques presented in this chapter, it is possible to provide early commitments, but to frame them with appropriate errors and buffer them appropriately, so that we can make commitments we can really meet.

Tracking and Communicating

This section starts with a number of ways of monitoring and communicating progress, such as the traditional Burndown Chart. We use Trac, which has some good reporting, so I’m going to stick with that. A later post will deal with Agile development using Trac.

The author also covers how to communicate plans, and does suggest a number of useful techniques for expressing them (including, amazingly, Gantt charts).

The final sections of the book summarise everything that has gone before, and presents a very useful fictional account of development using the techniques he discusses.

Conclusion

This is a very useful book for anyone applying Agile practices, and I think could provide a lot of the missing ‘glue’ for teams that are trying to be more agile but have trouble interfacing that with real customers. Using appropriate planning techniques can gain customer confidence earlier in the process, and so allow you to defer more of the architecture and design work to happen during iterations.

Posted by Doug Winter at 10:10 AM | Permalink | Comments (2)

Intro to Mochikit

This is well worth a look on two levels. Firstly it is a fantastic introduction to Mochikit (the Isotoma Javascript library of choice); giving you enough detail to whet your appetite without going overboard. Secondly it’s a fine technical example of what’s possible with Mochikit, Python and reStructuredText!

Posted by Andy Theyers at 08:41 AM | Permalink | Comments (0)