On our blogs, we recently found we were getting this error when trying to edit some posts:

The id's given were occasionally different but it was always the same format...

"Could not find category id XX in the Checkbox list which has XX items."

Somehow it seems that SubText has got itself in a twist and allocated invalid category id's to the posts. I suspect that this is actually caused by a funny bug between SubText and Microsoft Live Writer. You see, when you write an article in Live Writer you can allocate the categories for it and post it up to SubText. So far, so good. However, the bug occurs when you have a Post Category and an Article Category with the same name. When the Web Service request hits SubText it might not pull out the correct category id - probably because it checks only by name and grabs the first one. The problem we were having is that some posts were getting added with a category id for an article. Changing the category name for the articles fixed the problem.

You can see if any of your posts have this problem by running the following SQL against the SubText database.

   1: select * from subtext_Content, subtext_Links, subtext_LinkCategories

   2: where subtext_Content.ID = subtext_Links.PostID

   3: and subtext_Links.CategoryID = subtext_LinkCategories.CategoryID

   4: and PostType != CategoryType

If you get rows back, then you need to tweak your data :)

Once you've fixed your data, then the main recommendation I'd make is to use different category names for posts and articles. That way, Live Writer or other Web Service based blog tools won't confuse SubText.

I was at a client's office yesterday for the final review meeting of a two-week Use Case exercise. The particular area of the operations that we were pulling out into Use Cases had been the subject of various patchy projects within the organisation over a couple of years. As far as I can tell some of that work had been really good and laid the groundwork for the Use Cases, but it was not organised into any kind of overall picture or process and there was a certain lack of confidence in the previous projects. The concept of the Use Case approach was really quite radical for them, and the timelines we were talking about to draw them out sounded crazy compared to what had gone before.

This is something I come across often with Use Cases when looking at a business area which has been burnt with a 'traditional' approach before. Often good functional requirements and designs do result from these requirements gathering phases but they are just not organised, coherent and in a form that everyone understands and can sign off.

With Use Cases, everyone is brought along together. The business, IT, stakeholders - they are all involved right from the start and throughout. And this works because Use Case definition phases work best when they are short, sharp and tightly controlled. For any specific 'group' of business operations typically I like to work on a 2-4 week turnaround of a Use Case set. I also like to focus on User Level Use Cases - IT can worry about subfunction ones later. It's more important to focus on what Use Cases are good at. Don't try and do implementation, don't try and do logic, don't try to design business processes... focus on goals and the steps to get there.

And the end result? At the conclusion of the review meeting yesterday one of the key business representatives announced that they had achieved more in the last two weeks than they had in the last two years. Possibly a little unfair to what had gone before, but does show the degree of confidence that can be instilled by following a good requirements approach.

I've been back on the Use Cases recently after a bit of a time away from them doing some fairly deep techie stuff. Every time I work with Use Cases I find myself wondering why people aren't using them more (or similar methods) because they are just such a logical way of doing things. Let's face it - who really wants to bounce around a 100 page requirements document between inboxes ad infinitum with no-one really understanding or owning it? And what IT department wants to get a document like that landing on their desks?

One of the real beauties of Use Cases is how they feed into the Project Plan. Traditionally project plans have been geared around 'modules' of work, but these modules have normally been things like 'homepage' or 'data layer'. That's fine as far as it goes, but if you estimate around that and build your plan on it then how do you work out what each module actually adds to the value of the project, and how much effort within each 'module' is for core functionality and how much is for wishlist items? You often end up manipulating the project plan by having umpteen round-table meetings with project managers and techies to work out what can and can't get pulled in or pushed out and what impact that has on estimates and the plan.

With Use Cases, all that changes. If each Use Case is estimated then you have a statement of what goal is being achieved at what cost. This, to the project plan, is pure gold. It now becomes relatively trivial to work out how things need to be shuffled in and out of the project plan and, crucially, this can now be a business driven exercise rather than requiring techies to get involved. They don't enjoy that shuffling anyway.

In practice there are three key types of project constraint that affect the 'shuffling'; Functionality, Cost and Time.

• Functionality driven projects: In this type of project, functionality is king. Use Cases help by identifying priorities. All high priority Use Cases need to be put in the plan and this will give a cost and, when resources are factored in too, time. As Use Cases are flagged with changing priorities they can be put in and out of the project plan and the effect is immediately visible.
• Cost driven projects: All Use Cases have an estimation assigned to them. The beauty of this is that the ROI of each Use Case is much more visible. You pay this, you get this for it. The project plan can be built within a cost including the Use Cases that give the best ROI.
• Time driven projects: Some projects have a hard deadline. That's fine - with Use Cases you can fit as much in within the timeline and you can easily see what you will or won't get in before the deadline.

If you have good or bad experiences with using Use Cases for project planning do drop me a comment or a mail and let me know. Always interesting to see how theory turns into practice in different scenarios.