An expert system is a program that uses a set of rules to analyse information about a specific subject with a view to solving problems or giving advice. It emulates a human expert's problem solving ability by performing relevant tasks as well as, or better than, the expert. Often, the expert system will explain and justify its output and provide a measure of certainty in the appropriateness of the output. Furthermore, the output given by an expert system is, as is the case with humans, heuristic (a rule of thumb) rather than algorithmic (guaranteed to succeed).

Expert systems are incredibly useful tools. Traditional tasks have included:

• Data interpretation – such as responding to business "intelligence" like key performance indicators.
• Problem diagnosis – such as advising on equipment failure or human diseases.
• Configuration of complex systems – such as guiding the set-up of computer software.
• Planning actions – such as advising on business strategy or suggesting robotic manoeuvres.

I have already written an expert system in a previous role as Artitificial Intelligence developer for a (now out-of-business) software start-up. It was built to meet a very specific need in an even more specific way and made use of custom "in-house" tools for doing so.

This was a mistake that I do not intend repeating. The expert system I am about to write will be generic in scope and standards based. Delivered as a web-service via a simple API (Application Programming Interface) and a web-based user-interface I aim to make it a classic example of software as a service.

Who will use it?

I envisage two types of users – providers and consumers:

• Providers disseminate and sell their expertise through the tool. They might be consultants, companies, teachers or any other person or organisation that wishes to market and deliver expertise.
• Consumers pay for and make use of the expertise as well as provide feedback. They might be clients of a provider or simply persons or organisations that wish to "buy-in" expertise.

The feedback I mention above will work in the same way as the review system on Amazon. It exists because consumers will need as much information as possible about the expertise they are buying without actually accessing the expertise itself.

The expert system will make money by charging a percentage of the payment from the consumer to the provider.

Various models for providers to sell expertise will be made available: large one-off payments for unlimited access to a provider's expertise, rental (monthly or annual) access and even cheap one-off "shots". The providers set the pricing for their expertise and the open-market and customer feedback does the rest.

How will it work?

Providers will administer their account through an easy-to-use web-site that also provides information concerning the usage of their expertise. This is so they can view (for example) usage trends, popular areas of expertise, basic customer profiling and feedback on their offerings enabling them to concentrate on the most valuable areas of the market.

Consumers will be able to access expertise in various ways to reflect their individual requirements. This includes both forward chaining (data driven) and backward chaining (goal driven) interrogation strategies.

Consumers will also be able to interact with the system in one of two ways:

• Through the expert system's own simple, easy-to-use web-based interface.
• Through bespoke mash-ups developed by third parties that access the expert system's web-services API mentioned earlier.

When will it be ready?

I have already spent a lot of time designing the expert-system "engine" – the piece of software at the heart of the system. There is still a lot to do in order to make it more efficient and flexible and I still need to make extensive tests.

I have yet to start on both the web-services API and the web-site but I hope to get initial mock-ups for the user interface and specifications for the web-services completed in the not-too-distant future. This will, of course, involve discussions with potential end users (encompassing providers, consumers and potential third party software developers).

Finally, as with all my other projects described on this site, I need to spend some time writing a business and marketing plan.

The Economist magazine recently contained a survey of current trends in the Human Resources (HR) field. One article, "Everybody's doing it", examined how companies organise and manage "talent". The authors explained that "[c]ompanies are also trying to give their people-managers better tools" and that "the market [for talent-management technology] will nearly double by 2009." They make it explicit that companies of all sizes are focusing more resources on attracting, retaining and managing "talent".

Why is this interesting? Well, for the past twelve months I have been contracted to produce bespoke vacancy / applicant management systems. My impression of this market (as a technologist on the inside) is that the products on offer are overly complex, difficult to use, expensive and cumbersome. Informal conversations with various HR professionals confirm this opinion.

So an opportunity presents itself: there exists a relatively large yet growing market, serviced by immature or inappropriate applications that users don't feel meet their needs.

As a result I'm going to develop a web-based candidate management system that is:

• Simple and elegant in form and function
• Easy to use and learn
• Competitively priced
• Agile and adaptable to user's requirements

The desire for simplicity and elegance should come as no surprise to those who are familiar with my development philosophy. However, it is important to understand that simplicity does not mean lacking in features. Rather, that the most useful features are easy to use and do exactly what the user expects in a well presented manner.

Simplicity also brings about ease of use and the need for little (if any) training. There is nothing worse than an unintuitive application that requires an incomprehensible manual and various training days (when users should be getting on with ‘real' work).

That companies won't have to pay for training will save money. That the application will be web-based means there won't be distribution costs. That updates and patches will be applied instantly means there won't be expensive re-deployments. That the software will be delivered as a service means customers will only pay for it when it is required.

Simplicity also leads to agility and adaptability. Most companies have very different recruitment processes – yet these all derive from two simple generic processes; the standard funnel and reverse funnel. Implementing only these processes in a flexible way means that customers build upon the application's features rather than battle against them. In other words, the system is designed so users can extend and define their own requirements for the recruitment process.

So without further ado, let me introduce…

TalentTool.com

TalentTool.com is a tool for managing talent (where "talent" represents potential candidates and the ".com" identifies it as a web-based application). The name is also the project's customer facing web-site.

TalentTool.com will organise and manage the various important pieces of information required for recruiting candidates by utilising the two most common processes for recruitment: the afore mentioned standard funnel and reverse funnel.

Standard Funnel

A specific need is identified and a vacancy is created with matching requirements. The cohort of applicants is reduced in size by a series of generic filtering processes until a final candidate is chosen. The need is considered fulfilled when the final candidate is placed in role.

The filtering processes are usually of the following three types falling in the following order:

1. Shortlisting – involves filtering the raw application forms / CVs against the vacancy's requirements.
2. Assessment – in the form of tests and other means of measuring performance against the vacancy's requirements.
3. Interview – where candidates are invited for face-to-face assessment and possible trial work activities matching the vacancy's requirements.

Reverse Funnel

HR professionals pro-actively recruit candidates with in-demand skill-sets that are required to meet an anticipated need or match general roles or specific current positions. Candidates are:

1. Profiled – usually by examining experience, qualifications, career interests and availability.
2. Interviewed – often using a structured format or general behavioural model.
3. Assessed – in the form of tests and other means of measuring performance against their profiled skills.

If successful, a list of roles that the candidate is interested in and qualified to fulfil is drawn up.

If they are interested in immediate work then they are matched to current vacancies. If they show an interest in career development then further analysis is undertaken and a training curriculum devised to meet the mutual needs and goals of the company and candidate.

Information

The two most important types of information that a candidate management system is concerned with relate to vacancies and candidates.

Vacancy Information

In addition to the job-title, description of duties, location and salary/benefits package a vacancy will have the following details associated with it:

• Requirements – A list of the specific skills, qualifications, attributes and experience needed to fulfil the role on offer.
• Adverts – The means by which potential candidates are made aware of the vacancy.
• Events – Deadlines, appointments, activities and meetings that make up the roadmap for the life of a vacancy.
• Administrators – Who, within the hiring company, is allowed to administer this vacancy. Other roles with "view only" privileges may also be available.
• Reports – Statistics, facts and figures concerning the vacancy and the candidates.

Candidate Information

Candidates obviously have personal and contact information. In addition, the following details provide a fuller picture of their capabilites:

• Skill-set – A list of specific skills, usually with an indication of level of achievement that a candidate can offer.
• Education – The qualifications and training that a candidate has achieved.
• CV – Also known as a resumé. The document that the candidate produced to support their application.
• References – Persons who are qualified to comment on the candidate's suitability for the role based upon previous experience.
• Experience – A list containing the candidate's employment history and other activities related to the requirements of the vacancy.

Conclusion

The essence of TalentTool.com is to match candidates and vacancies by utilising one of the two "tunnel" processes in the simplest and most elegant way possible.

What measure do I use to know that I am developing a tool that will be a success? Well, the root of the application's success depends on how easy and useful the end users find it.

As a result, the primary concerns during the development process are the needs of the user and their interaction with the application. To them the user interface (UI) is the application. It enables how the user usefully uses the capabilities of the system. It is also the part of the system that projects elegance and simplicity. With this in mind, the roadmap for developing this application involves the following steps:

1. Initial requirements analysis – complete and summarised above.
2. Application mock-up and testing – the creation of easily modifiable screen-shots organised as a "story board" of the application. Feedback sought from target users and a focus group of interested parties.
3. Development / Testing cycle – using the final version of the Application mock-ups as the basis of the technical specification. Throughout this stage development will be shared with the focus group so feed back and changes can be implemented.
4. Beta-testing – feedback sought from target users after "real-world" usage. No new features to be added at this stage (project to be branched into development and release versions).
5. Release and maintenance cycle of version one.
6. Development of version two to integrate most popular requested features.

In addition to the above steps, a business plan that encompasses the marketing strategy, costs and pricing structure will need writing. I'll deal with that aspect of the project in a future article.

Both my wife and I play with the Northampton Symphony Orchestra, a very good local amateur group.

Every season they include short (often humorous) biographies of selected members of the orchestra in the programme notes. The selection criteria for this changes each year but is currently families who play in the orchestra.

This is the biography we submitted to be printed in the programme for the next concert:

"Mary and Nicholas first met as students at that well known dating agency for musicians, the Royal College of Music. This was in keeping with Mary's family tradition (she is the third generation of her family to attend the RCM). Since leaving the RCM both Mary and Nicholas have worked as professional musicians although they now make a living doing other things (both teach music and Nicholas went on to read for degrees in Philosophy and then Computing – he now works in IT). Music continues to play a significant role in their lives and playing with the NSO affords them the opportunity to make eyes at each other in rehearsals just like they used to when they were courting."

When I explain my plans for the month of November to my friends, family and (soon-to-be-former) colleagues they inevitably comment on how I'll (not) find the time to do all the tasks I have set myself to a standard that I will be happy with.

However, in my favour:

• I always set myself unrealistic work-loads and high targets.
• I understand that I do so because I know how to be lazy.

These are positive character traits for the following reasons:

By setting unrealistic work-loads I am forced to brutally prioritise and deal with my work in the most efficient way possible. I know that I won't get everything done in the time I have allotted; but what I will get done will have been done in the most efficient way possible to give me a maximum "return" on my time and effort. Think of it as a kind of anti-Parkinson's law used in order to overcome Hofstadter's Law.

This promotes a certain sort of laziness: I'm not going to waste my time doing things I don't need or have to do. If possible, I'll either automate what I want to avoid (with a computer program) or I'll find ways to re-use either my own or others' work to my own advantage (by using freely available software libraries and tools such as the Textpattern content management system that runs this site).

With these points in mind, my software-development philosophy is encapsulated in the following quote:

"As simple as possible, but no simpler." (Albert Einstein).

My intention is always to implement only the minimum of required features in the simplest, easiest and most helpful way possible.

Why?

• The lack of complexity means the code performs better (i.e. there is less for it to do).
• The lack of complexity means that I and any other developer working on the code understand it quicker, making it easier to maintain and modify.
• The lack of complexity makes it less prone to hidden bugs.
• The analytical approach required to implement something as simply as possible demands a thorough understanding of the problem being considered.

Aiming at a seemingly unrealistic high target is also a means of discovering what one is capable of. This is best illustrated with advice received from a music teacher I once knew:

I had only recently started playing the Tuba. I was going to audition for a very good local youth orchestra and I wasn't sure if I was good enough to join. His advice was that I wouldn't know unless I auditioned and that, more importantly, if I didn't attend the audition I'd always regret excluding myself from this opportunity.

Since then I have always had an "if I don't try I'll never find out" attitude and this has worked to my advantage on so many occasions. (I was successful in the audition, too!)

Finally, seriously considering the possibility of such work, targets, aims and objectives demonstrates a positive outlook, energy, imagination and creativity tempered with a healthy dose of realism and cunning.

Program#

My original .NET chat-bot was written over three years ago and is based upon the AIML specifications. It was also my first project in C# and became a vehicle for me to learn about the .NET platform.

Now that I have extensive experience and knowledge of .NET, I am re-designing this library to include several modifications and improvements. The definite modifications will be (in no particular order):

• Better cross-platform compatibility: .NET 1.1 and 2.0 as well as MONO support.
• A significant change in the architecture of the library (more modular to make it easier for developers to extend and add functionality).
• Better (i.e. more efficient and standards-compliant) AIML support.
• A simpler and more logical API.

I also aim (but no promises) to include the following features (in order of priority):

• A means of saving the bot's "brain" as a binary file. Loading a binary file into memory will be significantly faster than having to re-load and process the AIML every time the software starts up.
• The option to run the library with at least two different types of backend:
  • The regular in-memory "brain" built from the AIML or binary file described above.
  • A relational database (initially SQL Server2000/2005, MySql and PostgreSQL) and associated code to import and process the AIML into a relational structure.
• The implementation of some non-AIML compliant learning algorithms so the bot's vocabulary and scope for conversation grows.
• User profiling for better awareness of conversational context.
• Some simple code snippets and examples for developers to get started.

ProgramR

In addition to the work on Program#, I have been in touch with the developers of a Ruby version of the standard AIML bot (ProgramR).

By their own admission, the project is very much "alpha" code. I am going to spend time contributing to this project as both a bug fixer and implementer of new features.

My reasons for doing this are to:

• Deepen my understanding of the capabilities and stylistic conventions of the Ruby programming language.
• Advance ProgramR to the same level of maturity as Program#.
• Help bring into existence something insanely useful.
• Create a platform upon which new chat-bot techniques can be easily tried and tested.

Ultimately, both Program# and ProgramR will implement only the minimum of required features in the simplest, easiest and most helpful way possible and become solid foundations upon which bespoke systems can be built.