By the time you read this article, I will have been working
with my current employer for four years. During that time,
I have been involved in the development of many “cost
management” applications. Asset management/valuation and
cost estimating applications appear to be a common
requirement and are applications I have spent a considerable
amount of time designing, developing, testing, etc. My user-
base consists of cost-estimators, data input clerks, quantity
surveyors – i.e. people who are generally comfortable using
office products such as Microsoft Excel. In fact, I’m happy
to admit that I have the benefit of working with users who
are able to exploit the true power of Microsoft Excel. As
such, some of my applications have a workbook look and
feel, just like Microsoft Excel.
However, there is one thing that a majority of my users
say: “I can do a lot of what your application does using
Microsoft Excel”. That’s probably true; however I often
have to explain the rationale behind database theory, Client/
Server, multi-user update, etc. Usually the pre-cursor to
our applications is a Microsoft Excel workbook that has
outgrown the capabilities of Excel. Often the original
“author” of the workbook is able to verbally/graphically
explain what they need the system to do – but they don’t
know how to develop the solution. Convincing a user to
let go of a spreadsheet-based solution can be difficult, so
frequently we re-use the existing office technologies, such
as Microsoft Excel, Microsoft Word and even Microsoft
Project. The Component Object Model (COM) has made
this possible with the majority of Microsoft products.
However, what if the application is being deployed in an
environment without Microsoft Excel? This isn’t an
uncommon scenario – there are still a lot of our clients
using Lotus products, if not for their office solutions, then
for their groupware. Similarly, Microsoft Excel has
licensing requirements – and since there are costs involved,
using Excel might be prohibitive.
Since users don’t ne