13 March 2006

Use your head

From time to time, as a software developer, I encounter a client who wants the electronic brain to do something that the human brain can do so much more easily.

Nothing outstanding here, I suppose.  It's obvious that people can do a lot of stuff that computers can't.  But what I am referring to is where it seems like a job for a computer, but on closer examination it's a tough call.  It's where computation is involved, but I think the confusion happens in scenarios where the decisions require a fair degree of flexibility - computers are not known for their flexibility!

If you're interested in the gory details, here's a case in point:  in software for the administration of sports competitions, the process of allocating games/matches to venues (grounds / pitches / courts / fields etc).  Many sports competitions follow a "round robin" schedule.  Each team should play once against each other team.  Each team should have a even number of games "home" and "away".  So far, so good... these are mathematical problems and the programmer can sort it out with a minimum of headaches.

And then - where are they going to play?  This is where mathematics bumps headlong into practical reality.  Does each team have a "home ground", based on the club/school they represent?  Is this venue subdivided into a number of fields/courts?  If so, we can allocate a venue according to the home ground of the home team.  That is, unless this venue already has a match allocated to it from another competition (grade/league).  Can we make sure this does not happen?  Well, if every grade has the same number of teams, and if each club has enough home fields for the number of teams, and if each club has only one team in any given grade, then I think it may be theoretically possible.  Does this ever happen?  No, in practice the reality is normally far from this.  What does this mean?  It means there will always be venue clashes, based on the playing schedule that the computer works out mathematically.  It's inevitable.

So, now what can we do?  We can get the computer to check through the match details, and identify the venue clashes.  This can be done during the process of calculating the playing schedule, or afterwards.  And it also needs to be done whenever a manual change of venue or playing time is made.  Ok, fair enough, we can do that - that's mathematical.

And then what?  Does it seem like we can just get the computer to sort out the double-booking?  Well, here's the answer - if we can define the rules in sufficient detail, regarding what the computer should do when it encounters a venue clash, then theoretically we could resolve many of the clashes.

It might go something like this... For each clashing match, see if the opposing team has a vacant field.  If so, would this create a situation of more than 3 home games in a row for any team?  If not, put the game there instead.  If so, see if the original home team has a field available at another timeslot?  If not, is there a neutral field available at that time within 50 Km?  And so on.  Of course, a solution according to the rules may in fact be mathematically impossible, or so complex that it would take a normal PC many hours to calculate it.  And of course, the rules for resolving clashes are likely to be peculiar to each organisation, and it would take a huge number of hours of programming to get them working right.

So, in practice, in most cases the resolution of scheduling clashes requires human intervention.  Is this a drag for the administrator?  Possibly (though using software like SportsRunner will still be hugely preferable to doing the whole darn thing manually).  But this is where the human flexibility factor comes to the fore.  The administrator knows the venues, and knows the competitions.  If the software provides the administrator with:

  • a popup warning when data is entered which results in a venue clash

  • a list of matches where the venues are double-booked

  • a list of all possible venues showing which ones are already booked when

... then the administrator will normally be able to sort out a suitable playing schedule much more easily than the computer could.  Juggling and jockeying and creativity may be involved, and making computers juggle and jockey and be creative is not easy, believe me.

Tags: , ,

12 March 2006

Software in between - Part 2

Well, there are many different angles from which you can classify software.  In Part 1, I considered “generality”.  In this article, I want to focus briefly on the aspect of “connectivity”.  This will help understand the relationship between the user of the software, and the developer.  This is a complex subject, and the following is an oversimplification to illustrate the concept.

Desktop and Web applications

At one end of the spectrum is software that is designed for installation on a PC, and use on the local machine by a single user at any given time.  A very large percentage of productivity applications today fall into this category.

At the other end of the spectrum is the explosive number of web-based applications available.  This is software that is installed by a third party on a web server, and you use it via an internet connection.  This is an exciting field, as the technological developments increase the possibilities.

I do not propose to regurgitate the huge number of discussions on this subject.  However, many of these discussions have taken a Web vs Desktop flavour, as if it’s a religious war.  I don’t think “which is best” is the right question.  I think we should ask “when shall we use which”.  It’s more like deciding whether to use a car or a boat … it depends where you want to go.

Trade-off

Here are a few of the reasons that people are attracted to desktop applications:

  • “Rich user experience” – speed, flexibility, power, productivity, extended feature set, customisation.
  • Local ownership and control of data and documents.
  • Self-reliance for problem resolution.

Here are a few of the reasons that people are attracted to web applications:

  • Simplicity of deployment, installation, and upgrading.
  • Trendy and sexy.
  • Can be accessed from anywhere, and independent of platform.

So, in the case of any specific software scenario, the relative merits of these factors need to be considered.  Of course, nothing has changed here, except in some instances the choices have become broader.  In a very over-simplified nutshell, it often comes down to a trade-off between usability and connectivity.  What is most important for each particular business purpose?

Not that simple

However, the usability scale and the connectivity scale are becoming increasingly blurry.

Web applications are becoming more flexible and more usable.  AJAX and other technologies are making greater web functionality possible.  For business purposes where a rich user experience is important, it will be a number of years (in my estimation) before web applications can come close to matching today’s desktop possibilities – and by that time where will the desktop have evolved to?

Besides, many web applications now are browser based, and it is pretty obvious to me that the web browser is in decline as a productivity tool.

On the other hand, the connectivity factor of desktop applications is also rapidly moving forward.  I think we will see a further extension of the remote desktop concept to production scenarios.  I think we will see a simplification of the installation and upgrade processes for desktop applications.  And some of the investments that Microsoft are making, for example in the connectivity functionality available in Office 2007, are very exciting.

In between

So in the end, it comes down to what it has always come down to… software needs to meet the needs of the user for their particular purpose.  There are certainly many scenarios where web applications are superb, and there are clearly many scenarios where they are not.

Thinking about SportsRunner, our sports administration application, it is about ¼ way along, I reckon, between Desktop and Web-based.  It is a desktop application which integrates web functionality.  Here are some of the reasons why we chose that path:

  • First and foremost, the work which is done by this application requires a large degree of flexibility and access to options, speed in the user interface, number crunching, local functionality such as printing, emailing, and text messaging, local control over when the data becomes publicly available, and so on.  A considerable proportion of the application’s functionality simply could not be done at the moment in a web application, and a further proportion would be possible but less usable.
  • Because of the type of organisations using this application, in many cases it is managed by just one person within the organisation.
  • In those cases where more than one person uses the software, they normally all work in the same location, so their local network is the correct solution to their connectivity needs, and any web-based connectivity would not be appropriate.
  • In those cases where use from an external site is required, Remote Desktop or Terminal Services is preferable to any browser-based system.
  • To most users, effective is more important than sexy.
  • In those aspects where internet functionality is required and appropriate, (for example, publication of data for public access, and entry of sports results by multiple personnel where greater connectivity becomes important), then web applications are provided for these purposes, along with effective means of integrating the web-based data with the desktop-based data.
It is difficult to predict the future.  I believe that, given the currently available technologies, and given the business requirements of our users, we have made good choices.  As the future unfolds, SportsRunner will continue to evolve by taking advantage of new technologies.  In the end, the goal is to provide our users with tools that assist them to effectively do their work, and all else is based on this.

Tags: , ,

Powered by Qumana

09 March 2006

Niche business

I've been to a very interesting meeting tonight.  When you're really busy, and especially focussed (as tends to happen with micro-ISVs), it's easy to get absorbed in one's own little corner of business life.  So sometimes it's great to see what others are doing - stuff you wouldn't normally have contact with.
For me, I spend a big percentage of my work-related time revolving around using software to solve the challenges of sports administrators, and of my other customers.  I have been energised by hearing something of the stories of small businesses who are:
  • manufacturing and selling proteins for the use of medical diagnosticians
  • manufacturing and selling plastic pallets for the use of exporters
  • manufacturing and selling clocks for installation in electric grids to help track where a fault occurs

Somehow it is so reassuring to see that many of the processes and considerations of building a business are similar, when you are trying to solve problems in niche markets, regardless of the industry sector or the product.

Tags: