Friday 30 November 2007

The Matchpeg Introducer scheme is now the Matchpeg Affiliate scheme

We've changed the name of our introducer affiliate scheme from Matchpeg Introducers to Matchpeg Affiliates. It turned out that users from outside the UK weren't familiar with the term "introducer", and too many people were missing the scheme's benefits because they never clicked on the link on the website.

The scheme itself remains entirely unchanged, and very simple:
  • Earn on-going commission by referring colleagues and friends to Matchpeg, either by word-of-mouth or from links on your website or blog.
There are no charges for joining the scheme, and the people you refer don't suffer any financial penalty - quite the opposite, in fact, because we give an even more generous free trial to people who are referred than we do to people who come to the website cold.

You receive commission whenever your referrals spend money with us by buying pay-as-you-packs or paying subscriptions. Therefore, you don't just get a one-off payment; it's recurring revenue based on how valuable your contacts are to us.

Monday 12 November 2007

NEW feature - bulk user creation from Outlook

We've added a new feature to the user administration area:
  • Users of Microsoft Outlook can now download a small tool which automatically creates Matchpeg user accounts from contacts in Outlook.
The software can be downloaded from the existing bulk user-creation page. It's a simple wizard-based tool which works as follows:
  1. You log into Matchpeg using your normal user name and password.
  2. You let the software connect to Microsoft Outlook - this requires you to accept a standard Outlook security warning about automated access to your contacts.
  3. You choose the contacts you want to create as users in Matchpeg.
  4. You tell the tool to do its stuff.
The new user accounts are given individual random passwords which are sent out by e-mail.

(As is no doubt obvious, the tool is only for people who are users of (a) Microsoft Outlook, and therefore (b) Microsoft Windows.)

Sunday 28 October 2007

NEW feature - extra workflow fields

We've added another new feature to Matchpeg Workflow:
  • You can now create two bespoke text fields and two bespoke number fields in each workflow definition. These can be used for any purpose you like - you simply give them an appropriate label.
For example, you can use the number fields to record two extra items of numeric information about each purchase request. These fields show up in searches, and can be downloaded in CSV form for analysis in software such as Microsoft Excel.

Monday 15 October 2007

NEW feature - workflow descriptions and attached files

We've added a new feature to Matchpeg Workflow:
  • The description of a workflow item and attached files can now be marked as compulsory or not required.
Previously, these fields were always optional. You can now insist that users supply a description of a workflow item, or attach at least one file.

Friday 14 September 2007

And God said to Adam...

(Part of a series on matters technological. It beats doing real work.)

We've been interviewing recently. Before hiring people for software jobs, everyone reads Joel Spolsky's Guerilla Guide to Interviewing *. You must have read it - it's excellent. Well, mostly excellent.

The bit we got stuck on is part 6:

Part 6: the design question. Ask the candidate to design something. Jabe Blumenthal, the original designer of Excel, liked to ask candidates to design a house. According to Jabe, he's had candidates who would go up to the whiteboard and immediately draw a square.

Really? A square?

A square! These were immediate No Hires.

A square does seem a bit minimalist for a house. The fashion in the UK at the moment is for buying distressed Victoriana in run-down parts of town. High ceilings, superfluous ornamental brickwork. But it turns out that's not Joel's problem:

Good candidates will try to get more information out of you about the problem. Who is the house for? As a policy, I will not hire someone who leaps into the design without asking more about who it's for. Often I am so annoyed that I will give them a hard time by interrupting them in the middle and saying, "actually, you forgot to ask this, but this is a house for a family of 48-foot tall blind giraffes."

This is puzzling. We'd much prefer a candidate who says "What's the budget for the design stage?" followed by "Well, let's hire an architect to design the thing properly".

Anyone involved in software development will leap at this sort of design question like a seal after fish. It's actively encouraging three of the most disastrous traits of the IT industry: (a) ignoring precedent and expertise, and therefore continually re-inventing the wheel in a squarer form; (b) concocting "problems" in order to be able to "solve" them; and (c) unshakeable belief in one's own wide-ranging genius. It is impossible to over-estimate the self-regard of anyone who has ever worked in the software industry. (Yes, this includes the author of this article.)

There's another problem, which we can tease out by inserting a stage direction into Joel's scene of the hapless interviewee being humiliated somewhere in the Garment District:

Interviewer:Please could you design us a house.
Interviewee:(Pauses. No further information is forthcoming. Eyes swivel in alarm at the prospect of working for people incapable of providing even the most basic brief for a project. Cursing the evil hour that they sent in their resume, the interviewee begins to draw the thing most apparently in tune with the interviewer's mental faculties: a childlike depiction of a house.)

Who wants to work for someone so inept at communicating their essential requirements? When, in real life, would you make a request such as this unless you were the worst manager in the world, or an unspeakable sadist? It's as though God said to Adam, "Don't eat from the tree of... oh, whatever, just hang out in this garden for a few days."

The following is pure supposition, but interesting: questions such as this seem designed to identify candidates with a talent for arch, knowing role-play, and for recognising when it's professionally advantageous. These are skills which seem best-fitted to large, rigidly hierarchical, politics-ridden organisations. Microsoft is the source of this interview question and many other equally famous ones. Microsoft has become notorious for its bureaucracy and back-stabbing.

(* The Guerilla Guide to Interviewing got revised about a year ago. The Design Question mysteriously vanished. The new version is great, but it's less fun and the silent changes are as informative as the article itself.)

Monday 10 September 2007

NEW feature - guest access to meetings

We've added a new feature to meetings:
  • Action points can now be assigned to guests (i.e. people who are not on your firm's Matchpeg user list)
  • Guests can log in to a simplified version of the meeting overview using a six-digit PIN.

After logging in the guests are able to see the meeting details, and can update the status of any action points which have been assigned to guests.

Two things to note:

  • If there is more than one guest in a meeting, all guests share the same list of action points, and any action point assigned to "Guest" can be updated by any of the guests.
  • Guests can't propose agenda items (except by e-mailing them manually to the meeting organiser etc). Guests aren't full users of the system.

The URL for guests to log in to a meeting, and the PIN to use, is shown at the bottom of the list of participants on the organiser's view of the meeting overview. These details are also included by default in e-mails sent out to particpants by the meeting organiser.

Friday 31 August 2007

NEW feature - Skype names as meeting locations

We've added a new feature for people who regularly run meetings over Skype: you can now enter a Skype name as the location of the meeting. The system then displays the location as a clickable hyperlink which fires up Skype.

You simply enter the location in the form skype:name, e.g. skype:bobjones

Saturday 14 July 2007

NEW feature - quick entry of new users

We've added a new feature making it easier to set up meetings and brainstorming sessions: new user accounts can now be created from the pages for setting up meetings and sessions, without having to set up the users on the User List first.

At the bottom of the list of attendees is a new hyperlink labelled "Create a new user". This asks for minimal information - e-mail address, first name, last name, initials - and then creates the user and adds them to the participants for the meeting/brainstorming session.

The user is given an automatic random password which is sent out to them by e-mail (saving the amount of information which you need to provide manually). The user also gets a very basic set of privileges on the system - these can be altered at your leisure via the normal User List.

Sunday 1 July 2007

NEW feature - graphs

We've added several graphing options to the system, mainly on the pages for analysing search results:


  • Analysis of meeting search results

  • Analysis of action point search results

  • Analysis of workflow item search results

  • Analysis of workflow item progress

Graphs are also available in one further place:



  • Participant activity report for a brainstorming session

In each case, a graph icon is displayed at the top of each column of figures in the analysis. Clicking on the icon inserts a graph of the numbers, plus options for changing the style of the graph etc. And the graph gets included if you then choose the save the page as a PDF document.


This isn't intended to handle every possible graphing scenario. You can continue to build bespoke graphs (and reports) yourself by downloading list results in CSV form, into Microsoft Excel etc, and graphing it there.



Friday 15 June 2007

Why is progress in computer software so glacial?

It seems that we're still living out the tail-end of Romanticism. Nowhere is this more evident in the UK than in the popular obsession with cookery, and everything which appertains to it. Cooks, cooking, and cookery books dominate the bestseller lists and the TV schedules. It's the country's prime artistic medium and means of self-expression, and the public is infatuated with celebrity chefs and their dymamic, anti-conventional, artist-hero personas. Gordon Ramsay is Byron, and Heston Blumenthal is Shelley (in the sense of Shelley's experiments with electricity and magnetism, not his interest in proto-socialism, casual sex with jailbait, and advocacy of vegetarianism).

Behind the scenes, of course, things are rather different from the romantic-hero image. Deluxe restaurants are slickly-run operations, far more regimented and rigorous than the average business. The working day is very long, and precisely scheduled. There are complicated and well-protected supply chains. Marketing is vital. There's a clear line of command, and everyone's job is a small cog in the big machine - clear, repeatable, endlessly repeated. The temperatures are sweltering but, in spirit, the chef de cuisine, sous chef, chef de partie, rotisseur, second chef, aboyeur etc. all need to be "cucumber-cool machine minders" (Auden, Horae Canonicae).

Apart from a complete lack of public interest, the position in IT is almost identical. The public perception - inasmuch as there is one - is of the lone hacker, the guru. The reality is a series of highly segmented jobs, of increasingly minute specialisation. No one "knows about computers", or is competent to do more than a handful of jobs in the field. The system administrators can't program, and the programmers would cause utter chaos if they were allowed to fiddle with your company's IT infrastructure. Each of the programmers has an area of specialisation about which the others know little or nothing. The boss can't do any of what his team does. (The more someone earns in IT, the less likely they are to be able to fix your computer.)

In this segmented world, most of the larger entities which produce software - either for internal use, or for sale - separate out the jobs of designing the software and writing the actual code. (Most of them segment things still further, and have one person to identify a "business need" and another to design the software which meets that need. Someone else then codes it. Salaries go in descending order.)

These designers (mostly) can't write code. They (mostly) know no more about programming than you do - barring a sort of cargo-cult knowledge acquired from sitting next to the bearded blokes in T-shirts every day.

Therefore, the designers don't know what's technologically possible and impossible. They only know what they've seen done before. Their designs are necessarily mimetic. They'll produce solid, sensible designs in an accepted mould all day long, but they're never going to innovate. Their employers like this. They're risk-averse. That's why they segment the jobs. Which is fine for them, but it means that progress in computer software en masse is glacial.

Therefore, innovation and improvement in computer software almost always comes when there's no - or very, very little - separation between the people designing the software and the people writing the code. That tends to imply small, young companies - early Apple, or early Google. They keep the fire burning as they grow larger by buying other small, young companies (though Google have tried to institutionalise the phenomenon through their famous "20% time").

Or Matchpeg. We'll never have a job title including the words "Analyst" or "Architect". "Product Manager" is also verboten. Deliver results.

(Part of an occasional series on matters technological. It beats doing real work.)

Monday 11 June 2007

Why doesn't web-based software make use of the right mouse button?

A brief investigation of why it's so rare to see web applications which make use of the right mouse button. Yes, there are lots of reasons not covered here, and numbers #1 to #3 are pretty obvious. Part of an occasional series on matters technological. It beats doing real work.

Reason #1: effort

Handling the right mouse button in web pages is a bit fiddly. Some developers don't know how to, or can't be bothered. It's lots more work than just putting in a hyperlink.

Reason #2a: transient user base

On the whole, people spend much more time using desktop application A than any web-based application B. There's a pretty small number of business-critical, use-it-every-minute-of-the-day web applications. Very few clock up even an hour of usage per user per week. In other words, very few web applications have any "power users".

The traditional problem in desktop software is how you advertise to the user that right-clicking is available.

This problem gets much harder when you're dealing with a web application which people only use occasionally, haven't been trained on, and want to be able to use "intuitively". You don't have time or receptiveness on your side to explain that right-clicking is available.

Reason #2b: not what users expect

And so there's a feedback effect. Developers don't put right-clicks into web-based software. Therefore, users don't expect them. Therefore, developers don't put them in.

Reason #3: blame Apple

Everyone demonstrates web-based applications running on Macs. Many (most?) Macs have single-button mice. Ctrl+click is a pain in the neck.

Reason #4: effort (part 2)

Firms which produce web-based software tend to have less formal documentation procedures than firms which produce desktop software. Documentation is not cool; it's not Web 2.0.

The alternative to providing a right-click (e.g. plus pop-up menu) will often be a whole extra configuration screen/dialog. This extra screen would need to documented and designed in advance, approved, coded, sent back for re-design when the uber-product manager doesn't like it, re-approved, re-coded, and probably needs all sorts of extra pages in the help file as well.

In other words: if your documentation procedures are strict, putting in a right-click is generally less hassle than the alternatives. So, desktop software tends towards having a minimal number of "busy" screens (whereas web applications tend towards lots of simple screens, for a number of other reasons including minimising/shaping bandwidth usage).

Thursday 7 June 2007

NEW feature - analysis of workflow item progress

We've added a new feature to the analysis of workflow items. In addition to analysing the results of a search by current owner, creator, workflow stage etc. you can also now analyse the progress of the workflow items.


After doing a search for workflow items you simply click on the "Item progress" menu-bar link. This shows how long the items have spent at each stage, and with each person. It's obviously a simple and very quick way of highlighting bottlenecks in your processes - people in your team who are overloaded, processes which are inefficient etc.


Like all such pages within the system, the progress analysis can be saved as a PDF document.


Monday 28 May 2007

BMW functionality

(Part of an occasional series on matters technological. It beats doing real work.)

Before we started Matchpeg, we used to be Terribly Important People. We used to think nothing of donning our superhero garb in the nearest phonebox, and then leaping into a presentation with senior executives to sell them hundreds of thousands of pounds/dollars/euros of software and services at a time.

Like everyone else, we built our fair share of BMW functionality - not a reflection on the marque, but a comment on the sort of cars driven by the sort of people we were presenting to.

BMW functionality looks very pretty - albeit in a standardised, Stock-Option Chic kind of way - and it's not totally pointless. (A typical example is a ray-traced pie chart representing three numbers so simple that their relative proportions could be visualised, without graphical aids, by a child of seven.)

You're in a meeting where you're presenting the BMW functionality. You know that no one will ever actually "use" it. Even the users know that they'll never actually use it. But they're not in the room. You're presenting to the company's senior executives, and an 80/20 rule applies: they make 80% of the purchasing decision, but they're going to clock up at most of 20% of the eventual usage of the system.

At best, this is neutral: the BMW functionality is, in effect, part of your marketing (not your software); it helps to sell a fundamentally good system which deserves to do well; and it doesn't have any adverse impact on the quality of the system.

At worst, it's actively harmful: the time spent on the BMW functionality could and should have been spent on making the actual software better; and/or other, useful features are discarded or compromised in order to squeeze in what's effectively your sales pitch which the lowly users then have to live with day-by-day for the next n years.

This is less common on the web, because relatively few web-based applications are sold face-to-face. But there's still pressure to make sure that your software produces a great screenshot, and there's often tension between what produces the best screenshot and what produces the best functionality. (As an innocuous version of the same phenomenon, count the number of web-based applications which are demonstrated using Mac screenshots despite the fact that 97% of their users will be running Windows. Yes, we do this. Everyone does. It's the harmless end of something much more serious.)

What does all this lead up to?

We took a vow when starting Matchpeg: no BMW functionality. Deliver results.

Tuesday 15 May 2007

NEW feature - notes on workflow items owned by someone else

Bowing to very vocal demand, we've added a new feature to the workflow system: the ability to add a note to a workflow item which you don't currently own. (It continues to be the case that the current owner is the only person who can change the workflow item in any way.)


The ability to add these notes is controlled by the workflow definition. This switch is turned off for all existing workflows. If you want to take advantage of this new feature, you need to edit your existing workflow definitions and turn the switch on.


After doing so, anyone who's not the current owner of a workflow item is able to add a note to it using the new box at the bottom of the item overview page.

Sunday 13 May 2007

Project management

(Part of an occasional series on matters technological. It beats doing real work.)

We've been having some internal wrangling here at Matchpeg Towers about project management/software development methodologies (not much wrangling - we're all fugitives from organisations which like signatures in triplicate on everything).

Matchpeg is essentially in the retail software business. We sell tools at low cost, in large quantities, to happy customers who we rarely have any un-automated contact with. We do very little bespoke work. We don't really have "clients".

There's a polarised debate all over the web about the relative merits of waterfall (relatively linear, relatively traditional) software development processes versus more agile methodologies.

Waterfall doesn't work for us. It's not that we're a bunch of laid-back hippies - agile doesn't work for us either.

The problem with both is most concisely represented by the Agile Manifesto. Notice anything about this? (Leaving aside the fact that it reads like a Miss World contestant's pledge to seek out world peace and a cure for cancer.)

The references to customers are both in the singular, not to "customers" plural. We're in the retail software business. We have lots of customers. And they're so diverse that you can't boil them down into a single representative entity called "the customer" (or even "The Customer").

(The same failings can be found in things like the official PRINCE2 material: same assumption of a single customer; same assumption of a single entity paying for the project; same assumption that there's a contract.)

In short, our experience is that no well-known software development process translates at all well to the retail world. They all seem to stem from a founder's experience of in-house development for a large company, or bespoke development for a single (usually large) client. Using a popular term in IT, these methodologies don't "scale" well. They make all sorts of assumptions which stop working when you're dealing with a number of diverse customers, each of whom isn't guaranteeing to pay you anything.

These methodologies are created by consultants in order to perpetrate consultancy. They're for use with "clients", not "customers".

--

On a related note, we're bemused by the way the debate between waterfall and agile is usually presented: an either/or choice, generally accompanied by comments such as "waterfall is so lame".

Instead, it seems to be about risk/reward profiles. A question such as "Which is better, waterfall or agile?" looks as meaningless as "Which is better, stocks or bonds?" The answer depends on your circumstances and what you're trying to achieve.

As a very general rule - to which there are, yes, countless exceptions - the anecdotal reports on the web tend to indicate that agile methodologies offer the prospect of better returns (faster development) at the risk of greater loss (complete anarchic breakdown of a project into marauding bands of developers).

It's not a coincidence that waterfall methods tend to be preferred by larger, older firms, and agile tends to be preferred by smaller, newer firms.

If you're a small company just starting up, you have to take risks. You gravitate towards agile because you're not going to get anywhere by being dull-but-steady. Older companies - particularly public companies - don't and can't have the same appetite for risk. Everything militates against it: the shareholders want predictable returns, the employees want to keep their well-paid jobs. The potential additional reward doesn't justify the additional risk; the reward is too incremental, and the risk is too absolute.

The really nasty fights start when the incentives and risk-tolerance of the business owners are different to the incentives and risk-tolerance of the people running projects for them. This works both ways: an impetuous CEO who finds that he's hired a pen-pushing dullard of a project manager, or a cautious board which has landed itself with a bunch of mavericks who won't be significantly affected if they cause their project (or even the entire firm) to implode.

Friday 11 May 2007

NEW feature - removing brainstorming suggestions in real-time

We've added a new feature to brainstorming suggestions, particularly designed for use when running sessions in real-time. In addition to the full transcript editor, the organiser of a session can now delete ideas from the session, during the brainstorming stage, by clicking on the new grey cross icon which is displayed to the right of each idea.


This simply deletes the idea from the session. It has exactly the same effect as using the transcript editor to remove the idea. Like the transcript editor, only the session organiser is allowed to do this (and only they get given the icon for doing so.)


Thursday 10 May 2007

NEW feature - user groups

We've finally added a feature which we'd had in mind for a long time, and which several customers then prompted us by asking for...


You can now define a group of users (i.e. a list), and use it as part of a workflow definition. For example, you can define a "Customer Services" team, and have customer enquiries and requests being allocated to that team rather than to a specific individual.


It remains the case that every workflow item is always assigned to one specific person: if the workflow definition says to assign the item to a group, the system picks an individual from the group and assigns the item to them.


The definition of a user group lets you define how work is shared out amongst the group members: simple round-robin allocation of tasks, allocation based on who has the fewest items in their workflow queue etc.


You define user groups from the user list - i.e. click on "User list" from the Dashboard, and then click on "User groups". Only administrators are allowed to change (or delete) groups.


Groups can then be used anywhere within the workflow system where it asks who to assign a workflow item to.


As ever, full information can be found in the help file. We particularly recommend looking at the section entitled "Using groups as aliases".

Monday 7 May 2007

Does Matchpeg support the Opera web browser?

Matchpeg supports Internet Explorer (v6 or later), Safari, and all Gecko-based browsers such as Firefox and Camino.

We don't support Opera.

This is because there's an obscure bug in Opera which affects only Matchpeg and a few other sites. The main effect is that error messages don't get displayed - if an error occurs, we have to display a generic failure message rather than the proper explanation of the error. (See below for the technical reason why.)

So, Matchpeg is more or less usable with Opera, but if an error occurs you won't know what or why.

Yes, we've told Opera about this. No, they haven't done anything about it (or, indeed, even responded).

--

Tech details:

The problem is in Opera's XmlHttp handling. Opera doesn't follow the de facto standard which all other browsers adhere to. It's arguable that Opera's implementation doesn't even follow RFC 2616 properly.

When Matchpeg's web pages make XmlHttp calls (e.g. in order to log on), there are obviously two possible results: success (and some data), or an error. The XmlHttp pages on the server signal which has occurred using the HTTP status code. The usual code 200 means that the call has succeeded (e.g. logged on successfully), and the XmlHttp responseText member then contains any applicable data. The code 299 is used to mean that an error occurred (e.g. invalid user name or password), and responseText contains a textual error message to display to the user.

This gives the Javascript in the client-side web pages a simple way of checking what's happened. If you look at Matchpeg's Javascript, you'll see lots of code along the lines of the following:


switch (XmlHttp.status) {
case 200:
// Success. Do something with the
// data in XmlHttp.responseText
break;
case 299:
// Error! Display the message to the user.
alert(XmlHttp.responseText);
break;
default:
// Must be a 400+ or 500+ error - i.e. a
// problem with the server configuration.
break;
}



(We think this is quite elegant.)

The problem is that Opera drops the HTTP response body for all XmlHttp calls where the status code is anything other than 200. Therefore, a blank error message gets displayed.

There are three reasons for considering this a bug in Opera:

  • No other browser behaves this way.
  • There's nothing in RFC 2616 which obviously supports Opera's behaviour.
  • If Opera makes a normal (i.e. non-XmlHttp) request to a page which returns a status code such as 299, then it does display the response body. In other words, Opera's behaviour isn't consistent, and this tends to suggest that the XmlHttp implementation is in breach of RFC 2616.

We could, of course, change Matchpeg to pass back XmlHttp results in a way which works with Opera. But, frankly, it's not worth working round a bug in a browser which about 0.3% of our potential customers use.

Sunday 6 May 2007

Matchpeg Sudoku

We're often asked, "Why does Matchpeg have a Sudoku solver?" And also, though not usually by the same people, "How does it work?"

Important information for non-Brits: it is compulsory for every British newspaper to print at least one Sudoku puzzle daily. The freesheets for London commuters typically have three (which gives you an insight into the average journey time of a commuter into London, and the fact that these freesheets are only distantly related to "newspapers", and have rather more in common with the puzzle compendiums which you can buy in any airport before undertaking a seventeen hour flight in steerage).

More useful background information: British newspapers are well known for their bouts of collective mania. Their peerless executives reach a more-or-less simultaneous decision to fill them with spot-the-ball competitions, bingo, vouchers for free flights and meals in restaurants, free DVDs. Sudoku was the last-but-one or -two of these crazes.

The creation of Matcheg Sudoku was prompted by The Guardian printing one of these witless puzzles on every single page of its G2 supplement. This spoiled a perfectly nice breakfast, and writing a tool to solve them provided a handy little intellectual challenge to kick off the working day.

We stuck the solver on the site because we feel it chimes quite nicely with Matchpeg's aim of solving business frustrations.

--

How it works.

From a programming perspective, solving a Sudoku puzzle is mainly a simple exercise in recursion. The best method seems to be to keep track of all the values which a particular cell can't be. For example, if the cell in the top-left corner is known to contain 5, then the twenty other cells in the first row, first column, and first block can't contain 5.

Each time you set a known value, you record these 20 knock-on values. And each time you record a value which a cell can't be, you do two checks:

  • Does the cell now have eight values which it can't be? If so, it must be the ninth.
  • Is it now known that eight of the cells in a row, column, or block can't be a particular value? If so, then the ninth cell must contain that value.

When you discover a new value as a result of either of the above, you fill it in and process the 20 new implications of that. So, setting a single cell triggers recursive calls setting the values of other cells.

This method by itself solves the vast majority of Sudoku puzzles - typically, everything other than those rated as "very hard".

The next step involves looking for cells in a row, column, or block where only two of the cells can contain a pair of values: for example, there are only two cells which can contain 4, and the same two cells are also the only ones which can contain 8. If so, then you know that those two cells must contain either 4 or 8, and you can eliminate anything else on their can't-be list.

We've never seen a puzzle where this extra step actually gives a solution rather than just narrowing things down a bit. You could apply further subtle logic to the solution, but that's more computationally expensive than simply brute-forcing the puzzle from this point onwards. In fact, the check for pairs usually takes longer than its benefits merit: it's quicker to skip this check, and just brute-force the solution without first looking for pairs.

So, if the Matchpeg solver can't work out the puzzle through simple logic, it starts guessing. This falls into two parts: trying out guesses for single cells in isolation, and and then trying out a combination of guesses for multiple cells if necessary.

The first part simply consists of going down the grid, taking every value which each individual unknown cell could still be, and seeing what happens if that value is filled in. There are three possible results from trying out each one of these isolated hypotheses:

  • The value can't be right. Its knock-on effects are that the grid must be invalid (i.e. duplicate values in a row, column, or block).
  • Filling in that one value solves the puzzle. In other words, the hypothesis becomes a lucky guess.
  • It makes no difference. Filling in the value neither solves the puzzle nor is impossible.

Recording the hypotheses which can't be right (and their knock-on effects) usually means that you then hit a "lucky guess" very quickly. You typically only need to try out about 10 hypotheses before you get a solution.

In a very, very small number of cases, no single cell by itself gives the solution. You have to try out a combination of guesses for multiple cells at once.

The Matchpeg solver builds a list of the hardest remaining cells, and then tries all the possible combinations of the two hardest cells. If that doesn't work, it tries all the permuations of the three hardest. And then four, and then five.

However, we've never seen a puzzle which requires guessing four or five cells at once. The "world's hardest Sudoku puzzle" gets solved from the combination of guesses for only three cells.

Wednesday 2 May 2007

NEW feature - central list of RSS feeds

As we hope you already know, Matchpeg makes a very large number of RSS feeds available. For example:
  • Feed of all your pending meetings
  • Feed of all your incomplete action points
  • Feed of all your pending brainstorming sessions
  • Feed of all your current workflow items
  • ...Plus individual feeds for each meeting, workflow item, and brainstorming session
However, no web browser has quite cracked the issue of advertising feed-availability to people. Therefore, in order to make them more prominent and better-known, we've added a central list of the main feeds. This is accessible using the new "RSS feeds" link on the right of the Dashboard.

(If you have no idea what RSS is what are you doing reading a blog? we suggest that you read a generic introduction to the subject, such as the one published by the BBC. All Matchpeg's feeds can be added to places such as a Google home page.)

Tuesday 1 May 2007

NEW feature - full help file

Matchpeg's context-sensitive help file is now complete - i.e. full documentation of the system in addition to the Getting Started guides, the brief help text displayed on each screen (e.g. at the top of boxes), and all the various tooltips.


Now that the help file is complete, help on each page can be viewed in either or two ways:


  • Click on the new help icon in the top right of each page

  • Or just press F1

The "Help" link in the "Help and support" section on the Dashboard continues to link to the first page of the help file.


We recommend that everyone - though particularly new users - reads the "hints and tips" section of the help file. Almost everyone will already know 80% of the information in this, but it will be a different 80% for each person, and the remaining 20% may well turn out to be valuable information.

Introducing the Matchpeg Introducer scheme

Big drum roll for the launch of... the Matchpeg Introducer scheme.

The basis for this is simple, and it's worked really well in our previous ventures: word-of-mouth recommendations are much more effective and much cheaper than any other form of marketing, and anyone who recommends us to their friends and colleagues deserves a share of the proceeds.
  • You sign up as an introducer.
  • You put a link to Matchpeg on your website/blog.
  • People sign up with Matchpeg after coming to us via your link.
  • We pay you commission whenever your referrals spend money with us.

We also provide other kinds of marketing support such as e-mail templates which you can use when contacting your friends and colleagues about Matchpeg.

You can even introduce other introducers: if someone becomes an introducer themselves after coming to Matchpeg via you, then you can earn extra commission on their referrals. (No, this is not a Ponzi scheme. Payments to introducers don't come from payments by other introducers. Registration as an introducer is free.)

Thursday 26 April 2007

Welcome to Matchpeg

Welcome to Matchpeg, the site for relieving business frustrations and delivering results.