Reset Microsoft Word

I recently had problems with Word style getting messed up, so I figured I’d just zap the file and everything would be OK. It wasn’t, so I took more drastic measures.
It turns out you can use the registry editor to blow away Word’s settings, and Word will restore the defaults when you start it next. The key that holds the settings varies according to the version of Word that you’re running.
Warning: If you think this is a safe thing to do, don’t do it.

Word 97 HKEY_CURRENT_USER/Software/Microsoft/Office/8.0/Word
Word 2000 HKEY_CURRENT_USER/Software/Microsoft/Office/9.0/Word
Word 2002 HKEY_CURRENT_USER/Software/Microsoft/Office/10.0/Word
Word 2003 HKEY_CURRENT_USER/Software/Microsoft/Office/11.0/Word
Word 2007 HKEY_CURRENT_USER/Software/Microsoft/Office/12.0/Word

The PRINCE2 Business Case Theme

The Business Case is one of 7 PRINCE2 Themes (things that must be attended to throughout the life of a project).

The Purpose for the Business Case

A basic principle of PRINCE2 is “Continuous Justification”, which asks the question, “is the project (still) worth investing in?”. The project’s Business Case documents the answer to this question.
Different projects will measure success is different ways, for example ROI or legislative compliance.  Nevertheless, all projects must be evaluated to see if the right  approach is being taken to achieve benefits with available resource. In order to do so, the Business Case provides the means to evaluate the project on whether it is:

  • Desirable = Is the project worth investing in, given its anticipated costs, benefits and risks (CB&R)?
  • Viable = Is the project possible? Will it produce the intended products?
  • Achievable = Will the products of the project provide the intended benefits?

Delivering a project’s products doesn’t mean benefits of these products will be realised. For this reason, it is important to distinguish between the project’s products (or outputs), outcomes and  benefits.

  • Output = a specialist product of the project, e.g. new web site
  • Outcome = result of using project’s outputs , e.g. more sales
  • Benefit = measurable change that is advantageous to stakeholders, e.g. increased profits

In  contrast to a project’s products, its outcomes (and therefore benefits)  may not occur until some time after the project closes. To avoid the  danger of loosing sight of benefits and focusing on products, the  Business Case must make the relationship of products, outcomes and benefits explicit.

The Contents of the Business Case

The Business Case must contain sufficient information to determine if project is DVA i.e. will give a ROI (return on investment). A typical Business Case will contain:

  1. An executive summary
  2. Reasons for undertaking the project, including options that have been considered
  3. The anticipated benefits and and dis-benefits
  4. Estimates of costs and time-scales
  5. A risk profile
  6. An investment appraisal

The Reasons for the Project and the Options Considered

This section outlines the reasons that the project is required, given corporate strategies and objectives. These reasons may be derived from the Project Mandate, but clarification should be sought if that is not the case.
The options considered should be included in sufficient detail for stakeholders to determine which gives the best ROI for business. It will include estimated CB&R (costs, benefits and risks for each option).
PRINCE2 recommends that options should include:

  • Doing nothing (default)
  • Doing the bare minimum
  • Doing something

As the project progresses, the Business Case will be continually updated with regard to CB&R.

Expected Benefits and Dis-benefits

The project’s products are determined by the benefits desired from the project. The business case should list the tangible and intangible benefits anticipated from the selected option. (Intangible benefits might be “increased employee morale”)
Details of each benefit should include:

  • How the benefit fits with corporate objectives and strategy
  • How It relates to the projects outputs and outcomes
  • How much benefit is expected (with tolerances)
  • How the benefit will be measured (even for intangible benefits)
  • Who benefits

To enable continuous justification of the project:

  • The relative importance of benefits should be recorded
  • Benefits should be objectively quantifiable

In addition dis-benefits should be included in the Business Case. Dis-benefits are those perceived as negative outcome by at least one stakeholder. The difference between risks and dis-benefits is that risks are uncertain whereas dis-benefits are expected.

Time-scales and Costs

Information about time-scales will include:

  • When resources will be required
  • When benefits will be realised and verified
  • The earliest / latest feasible project start / end dates

Information on costs will include:

  • Project costs based on the Project Plan
  • Ongoing operational and maintenance costs
  • The basis of costings
  • Funding arrangements

The time-scales and costs in the Business Case are used as basis of tolerances as the project progresses.

Risk Profile

Projects are uncertain, and therefore risky. Risks can impact both benefits and resources both positively and negatively. The justification needs to take major sources of risk into account, so a summary of risks will be included in the Business Case, and major risks will be. The recording of risk should  focus on benefits, and should therefore includes both project and ongoing operational / maintenance risks.

Investment Appraisal

An Investment Appraisal is a comparison of costs and benefits over a period of time (a fixed period, usually in years, or life of product). It will includes both project costs and ongoing costs, and is intended to demonstrate the value of the project to stakeholders.

The Life of the Business Case

There are 4 stages in the life of a Business Case:

  1. Development
  2. Review
  3. Maintenance
  4. Confirmation of Benefits

Developing the Business Case

Initially, the information in the Business Case is based on approximations. These estimates should be iteratively refined as more is learned, and this may lead to project replanning.

Process Development of the Business Case
SU An Outline Business Case is drawn up based on the Project Mandate. The Outline Business Case forms part of the Project Brief.
IP The detailed Business Case id based on the Outline Business Case and Project Plan, and may include information from the Project Brief and Risk Register. The Business Case forms part of the PID.

Reviewing of the Business Case

At various times throughout the project, the Business Case will need to be revised and re-evaluated to see if the project is still justified. This will occur:

When Why Who
At the end of the SU process To ensure project is worth investing in Project Board
At the end of the IP process To authorise the project Project Board
As a result of changes to the project’s anticipated costs, benefits or risks To assess the impact of the revision on the project PM
Following an exception To approve an Exception Plan Project Board
After each stage To authorise the next stage Project Board
During final stage To ensure project will provide expected benefits PM
As part of the benefits review To ensure that benefits are realised Corporate / programme management

Maintaining the Business Case

The Business Case is continually updated regarding CB&R. This is especially important at the end of each stage before the next is authorised. Updates will include benefits already realised as the project progresses.

Confirming the Benefits

Most benefits are realised after the project has closed, so a mechanism is required to confirm them after the end of the project. This is the purpose of the Benefits Review Plan, which is based on the Business Case. The Business Review Plan will include:

  1. Expectations regarding the scope, timing and responsibilities associated with review.
  2.  Information required to confirm that the benefits of the project:
  • What benefits are expected
  • What (objective) measures will be used to confirm these measurements
  • What baseline measures will be taken
  • How measures will be collected

The Business Review Plan may be updated during the project if benefits are realised before it is closed.


Corporate or Programme Management

  • Provides the Project Mandate, upon which the Business Case is based
  • Ensures that the Benefits Review takes place


  • Ensures the Business Case and Benefits Review Plan are written and approved (doesn’t necessarily write them)
  • Secures funding
  • Ensures that the benefits specified by the Senior User represent ROI, are aligned to corporate strategy and that they are realizable.

Senior User

  • Specifies the benefits
  • Realizes benefits by using products
  • Confirms their realization in the Benefits Review
  • Individual beneficiaries may be recruited to support the Senior User

Project Manager

  • Assists in writing the Business Case and Benefits Review Plan
  • Performs an Impact Analysis following changes in CB&R
  • Assesses the Business Case at the end of each Stage
  • Reporting benefits realised during project in the End Stage Report

Project Assurance

  • Assist in developing the Business Case
  • Monitor the Business Case to ensure that events outside the project have no impact upon it
  • Verifies and monitors the Benefits Review Plan

The Seven PRINCE2 Principles


PRINCE2 is founded upon 7 principles (made explicit in the 2009 refresh) that underpin best practice in project management. These principles are therefore fundamental to PRINCE2, and should be used as a guide to applying of the PRINCE2 methodology. A project cannot be said to be a PRINCE2 project if any of these principles is neglected. They provide the basis for decision making throughout the project’s life-cycle.

The 7 Principles (JERSEPT)

  1. Continued business justification
  2. Learn from experience
  3. Defined roles and responsibilities
  4. Manage by stages
  5. Manage by exception
  6. Focus on products
  7. Tailor to suit the project environment

Continued Business Justification (2.1)

There should be a clear ROI (return on investment) for any project, both at the start and throughout its life-cycle. Even compulsory (legislated) projects require justification of the approach taken to solve them. The justification may change as the project progresses, but it should remain valid. If a project becomes unjustified it should be stopped.
The justification is documented in the Business Case, which includes the resources required and the expected benefits for the project. The business case should, of course, be aligned with corporate strategy.

Learn from Experience (2.2)

Throughout the project, all participants should seek out and document learning opportunities. A lesson that doesn’t result in change is not a lesson learned!
At the start of a project, the project team should:

  • Consider seeking external expertise
  • Review similar past projects

As the project progresses, they should:

  • Include lessons learned in all reviews

And at the close:

  • Pass on learning at the end of the project

Defined Roles and Responsibilities (2.3)

For a project to be successful, it is essential that:
1. the right people are involved in the project
2. these people know what is expected of them
3. what they can expect from others
The project must have a clearly defined management team who represent the interests of:

  • The business – to ensure that the project is justified in terms of ROI
  • The users – to ensure that the project produces the intended benefits
  • Suppliers – to ensure that the project is feasible from a resourcing perspective

Manage by Stages (2.4)

Every project has a “Planning Horizon”, which is the limit beyond which meaningful planning cannot be undertaken.
To tackle problems associated with this, PRINCE2 divides work into discrete Management Stages. Detailed planning can be undertaken for current stage, whereas plans for the whole project can remain in outline. A significant advantage of this approach is that learning from earlier stages can be carried forward into later stages.
Between each stage are control points where senior management (i.e. the Project Board) undertakes to:

  • assess the previous stage
  • verify Business Case
  • review plans for next stage
  • decides whether or not to continue with the project

Longer stages therefore provide less control management control, whereas shorter stages require more work from management.
A PRINCE2 project as a minimum of two stages:
1. The Initiation Stage
2. One additional Management Stage, which includes project closure.

Manage by Exception (2.5)

It is essential that decisions are made at the right level in the organisation, and that each level of authority:

  • Has delegated authority to manage at that level
  • Is accountable to higher levels of authority
  • Can delegate to lower levels in order to use time effectively.

To achieve this, PRINCE2 projects define tolerances at each management level for:

  • Time
  • Cost
  • Quality
  • Scope
  • Risk
  • Benefit

Changes inside tolerance are dealt with at that management level without bothering higher levels. Issues outside tolerance are Exceptions, and are reported to level above. For example, the Project Board normally only hears from the Project Manager in regular reports, unless there is an Exception in which case they are alerted immediately.

Focus on Products (2.6)

A project should focus on outcomes rather than activities. Without clearly defined outcomes, there are no shared expectations. As a result, the project risks:

  • rework
  • scope creep
  • acceptance disputes
  • customer dissatisfaction

To mitigate these risks, PRINCE2 Product Descriptions detail outcomes (esp. for quality) and acceptance criteria. Product Descriptions should define such things as the product’s purpose, composition, derivation, format, quality criteria and quality method.
Product Descriptions define the scope of project, and provide the basis for planning resource requirements, dependencies and schedules.

Tailor to Suit the Project Environment (2.7)

PRINCE2 is applicable to all project types, but approach and effort must be tailored as appropriate the project’s needs: environment (e.g.. existing management structure), size, complexity, importance, capability and risk (e.g.. reporting frequency, emphasis on risk).
The Project’s Project Initiation Document (PID) should describe how PRINCE2 will be tailored for that project.

Metaphors for Programming

In the opening chapter of “The Developer’s Code“, author Ka Wai Cheung describes the book as “a collection of lessons, observations, and missteps I’ve gathered, first-hand, in our industry”.

The following is my summary of Chapter 2: Metaphor. Whilst I’ve tried to do justice to the author’s intentions, the interpretation is my own. I’ve included my comments in italics.

Follow metaphors with care

In other professions (cooking, music) people’s experience tells them if something is good or bad. However, programmers must resort to metaphors like “software architect” because people have little experience with code. Whilst metaphors are useful, they can distort our priorities if relied upon too heavily.

Several examples follow:

Plan enough then build

The architecture model over-emphasises planning over writing code and testing it. Agile development unbinds us from the metaphor.
In construction, the product requires detailed specifications:

  1. re-work is expensive or impossible
  2. task scheduling is complex
  3. raw materials are limited
  4. errors during production are expensive

Whereas in software production:

  1. the construction remains malleable
  2. the product is testable in (near) real situations
  3. errors during production needn’t equate to issues in use
  4. the product can be duplicated at no cost

Launch is just the first release

Buildings are built and then opened. In contrast, software can mature and develop over time, and users are increasingly accustomed to change.
Launch is a milestone, but not the end of a software products life-cycle. Get the important stuff right and fix the small stuff over time.

The “ivory tower” architect is a myth

Real architects don’t hammer in nails, but the division between designing and building software is arbitrary. In reality, software architects need the insights that are only available to coders. Software architects must, therefore, find time to do at least some coding.

Throw away your old code

Unlike real-world materials that are often reused, we don’t need to keep old code because:

  • Unlike real-world materials (bricks, metal and so on) the raw elements of code are inexpensive and easily replaced
  • Commented-out code is distracting
  • We rarely uncomment code that we comment out
  • Resurrecting old code is often more expensive than rewriting it

An important exception to this rule is where you want to keep a record of your thinking rather than the code itself.

Diversification over specialization

Specialised roles in building occur in different physical places, whereas our tasks are all on the same screen. For this reason, there is no reason we can’t be good at a range of jobs.

The logic of this argument is flawed, and the conclusion questionable. While over-specialising can be dangerous, trying to be a jack-of-all-trades can be equally hazardous.

My guess is that this is just a weak example of a powerful idea: the author is trying to illustrate the idea of architecture as a limiting metaphor rather than provide a justification for becoming a generalist.

Metaphors Hide Better Ways of Working

Metaphors both liberate and constrain our thinking.
Where they are a problem:

  1. Learn to see where metaphors are being used and their limitations
  2. Try changing metaphors

The C# Null Coalescing Operator


A the ?? operator is a binary operator that is used to simplify checking for null values.

If the left operand is not null, it returns the left operand, otherwise it returns the right operand.

For example:

This means that:

Is equivalent to:

And is even shorter than:

The ?? operator is right-associative, which means that it is evaluated from right to left. This means that:

is evaluated as:


  • Arguments can be reference types or nullable types.
  • If both arguments are constant, the result is not considered to be a constant.
  • Both arguments must be of the same type.


Assigning a Non-Nullable Type from a Nullable Type

int result;
int a? = null;
result = a ?? 1; // Assigns 1 to result.

Lazily Instantiated Properties

Avoiding Double Evaluation


Take Time to Go Fast

Imagine that you have to drive a long distance as fast as possible. Do you just jump in your car and put your foot down?

  • You won’t get there fast if you run out of fuel. You need to take time to fill up.
  • You won’t get there fast if you have an accident. You need to take time to drive safely.
  • You won’t ge there fast if you have to come back because you’ve forgotten something. You need to take time to pack properly.
  • You won’t get there fast if you pick a poor route. You need to take time to look at the map / program the SatNav.

We all know that, when driving, we need to take time to go fast.
Why don’t we understand the same thing about writing software?

HTML CSS and Real Programming Languages

It is a universal rule:
Wherever people talk about web programming languages:

  1. Someone will mention HTML and CSS
  2. Someone else will protest that HTML and CSS are not programming languages

But, does it matter?

A True Story

I once spent a few months developing a complex performance management system using a “proper” programming language. It automated the process of gathering data from various other systems, performed various manipulations on that data and then presented the results in a simple table, a kind of balanced scorecard.
Once it was live, a senior manager saw a tool written for a similar business, and asked if we could replace what I had written using their alternative. Furthermore, he was upset that I’d spent weeks developing my solution, where this new app had been written in a matter of days.
Further investigation revealed that the manager’s preferred option was all presentation with no substance: there were lots of colours and icons and graphs, but there was absolutely no logic behind them. All the data had to be gathered and manipulated manually. Despite the pretty interface, the application was essentially useless.
I’m happy to say that the manager in question was persuaded that my approach was the one that met his real business needs.

The Importance of Real Programming Languages

Now, as any CS graduate will know,  “real” programming languages are Turing Complete. As a proper sad geek, I find this sublimely fascinating. It means that, for any program written in a T-C language, a functionally equivalent program can be written in any other T-C language. Of course, this isn’t to say that all languages are the same. The each have their strengths and weaknesses that make them more or less suitable for certain tasks. However, I/O aside, this means that all programs can be written in all true programming languages.
Of course, the same isn’t true of a markup language like HTML or CSS. In fact, there are whole classes of problem that these languages simply can’t solve. Where I can program anything I want in a true programming language – including layout engines – it just isn’t possible to achieve the same things with languages that aren’t T-C.
(As an aside, some people think that the fact that HTLM and CSS are declarative rather than imperative actually nakes a difference here. But, that really isn’t the point. It is possible for a declarative language to be T-C and for an imperative language to be not T-C)

The Importance of Presentation

Unfortunately, when programmers get sniffy about HTML and its ilk not being true programming languages, there is often an implication that skills in HTML, CSS etc. are somehow inferior to skills in “real” programming languages. This is a serious mistake.
In my story, the senior manager felt that design was very important to him, to the extent that he was initially prepared to overlook function in its favour. Now, if this were an isolated incident, I might suggest that the manager was just being foolish.
But it wasn’t.
Time and again, I’ve met users who are impressed by flashy graphics and whizzy widgets, but unimpressed by raw functionality and my technical achievements. I think that there are several lessons to learn here:

  • People evaluate software on criteria that they understand. They often understand the difference between good-looking and ugly, but rarely appreciate technical nuances.
  • People are fooled by appearances. This may not be a good thing, but it is a reality that we must live with.
  • Appearances influence the way people feel about software. The way people feel about software is important to them. Indeed, people sometimes prefer software that makes them feel good over software that is functionally superior. Indeed, they might well be more productive with feel-good tools than with technically superior tools. To this extent, our users are not being fooled. They are actually making a wise and thoughtful choice.
  • As programmers, we often neglect the role of presentation as we focus on function. To some extent, this is right and proper. However, it is important to recognize that there is another dimension to our work that is important to our customers.

So, presentation-oriented languages (HTML, CSS) are important. The value added by tose who can use these tools effectively should not be underestimated.

What is the Difference, Really?

The interesting thing is that, to most people, none of this T-C business matters. The important difference between a programming language and HTLM / CSS is this:

HTML and CSS describe presentation, whereas programming languages describe function.

And both of these things matter.

Why are Programmers Pedantic About it All?

So, why do programmers spend so much passion on defending their position that HTML and CSS are not programming languages? There are lots of reasons.

  1. Because there really is a real and fundamental difference, as outlined above.
  2. Programmers spend a great deal of time, effort and money developing their skills. People naturally value the things in which they invest (“your heart is where your money is”).
  3. Programmers often feel the need to justify the amount of time it takes to produce results compared to the rapid results achieved by UI designers. In order to do this, they need to draw a distinction between what the two groups actually do.
  4. Employers need to apply the right people to the right jobs. Unless we clarify the (often technical) differences, managers easily make the wrong calls.

Is it Always Appropriate to be Pedantic?

Let’s face it, as programmers we’re a naturally pedantic lot. It goes with the territory. It doesn’t help that many of us have been burned when non-programmers have failed to understand what we do.
Nevertheless (and to be honest, this goes against my natural instincts), I don’t think we need to call people out whenever they slip over every little distinction.

The important things here are context and perspective.

I’m told that, to a biologist, a tomato is a fruit. But when I buy them in the supermarket, I look for them amongst the veg. Why? Because the technical distinction doesn’t matter in that particular context. Moreover, the distinction would actually get in the way if I daft enough to include tomatoes in a fruit salad.
It is the same with computer languages. There are times when the difference between programming languages and other languages really does matter. Quite often, however, we can all communicate perfectly effectively when just lump them all in together. In the case when people are asking what programming languages they need to lear to do web development, it really didn’t matter what languages were true programming languages and which were not. Pointing out the distinction won’t advance the discussion in any way. Indeed, in many cases, pedantry can stir up negative feelings and damages relationships… as my wife will gladly testify!

When to Make a Stand?

A preacher friend of mine once delivered a sermon entitled:

Is this a hill worth dying to be on?

He was referring to generals who make a strategic assessment over which battles are which fighting: are the gains worth the costs?

  • Is it really worth interrupting the flow of the discussion to make this distinction?
  • Does my pedantry stem from a sense of arrogance or from past hurt?
  • Do my comments value the skills of others as well a my own?

Of course, there are times when distinctions need to be made. My aim is that, when I make a contribution, it will add value to our collective endeavours.
That is, after all, the job of a every real programmer.
(This article is based on my answer to a question on Programmers)

Because there really is a real and fundamental difference, as outlined above.

BizTalk: Problem with Business Rules not Working

The Problem

If you’re having trouble getting Business Rules to work, remember that you can test your rules in the Business Rules Composer. Microsoft provides details on how to do so on MSDN.
However, I recently found that the business rules that I was testing were known to be correct (they worked on another machine) but were not being invoked on my PC.

The Solution

The reason that they were not working was because my PC was not configured correctly. I needed to add a new DWORD registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\BusinessRules\3.0\StaticSupport = 1
Richard Seroter’s blog gives more details on the purpose of this key.

Practice: Don't Repeat Yourself (DRY)


To eliminate information repetition of all kinds.

Every piece of knowledge must have a single, unambiguous, authoritative representation within a system. Andrew Hunt and David Thomas (2000) The Pragmatic Programmer

This does not only apply to code:

  • Copy-paste (surface features of the code are the same)
  • Logical / Functional (the same logical process, but surface features vary)
  • Data (the same information in two different places)

But also to:

  • Documentation (requirements, for users etc.)
  • Software architecture
  • The software development process

To help you remember this practice, write out 100 times, “I will not repeat myself”.


  • Repetition in process calls for automation
  • Repetition in logic calls for abstraction

Alternative Names

  • Single Source of Truth (SSOT)
  • Single Point of Truth (SPOT)

Forces Against

  • Ignorance of parts of the system (I didn’t know it was already there!)
  • Reliance on surface information rather then deep understanding. Assumption that is different because it looks different.
  • Reuse of existing information from several non-colsolidated sources.

Problem Overcome

  • Duplication requires that all copies must be maintained
  • Leads to larger code / data base, making finding defects more difficult


  • Automated derivation (eg. caches, generated code / documentation) where the original source is well know.
  • Certain optimisation techniques

Part of Development Lifecycle

  • All

Related Practices



  • Code reuse: Classes, subroutines, code libraries
  • Data Normalisation
  • Design Patterns


  • N/A