[AccessD] Paean to the Access Development Team

JWColby jwcolby at colbyconsulting.com
Mon Jan 29 15:23:08 CST 2007


>The "Chevrolet" set would be most pleased to learn that an Access developer
can deliver a functional application for approximately 1/10 the cost of the
equivalent app developed in .NET.

My client (who comes from a lifetime in the insurance industry and has
tentacles out there yet) told me an interesting story.  One of his clients
(a huge insurance company) contracted, for a mere 12 million dollars, to
have their mainframe program modified to allow paying the claims directly
in-house.  Several years and $10 million into the project, they canceled the
project (it wasn't ever going to work it seems) and purchased an application
to do this, for about another 12 million dollars.

In the meantime, my client (a little company of 50 people) is busily paying
claims using the system that I am developing for them in Access.  To my
client, the price has been high - we started the design effort to add
issuing checks (paying the claims) back in July of 1996 and within 2 months
issued the first checks.  The cost for those two months of development was
about $12K.  

We are now adding two more clients who want their claims paid as well. Each
of these clients has their own set of requirements, mainframe exports to our
system, mainframe imports (reports) required back, exports to banks to tell
the banks to pay etc.  Again, to my client, the price is pretty high, again
probably about 15K to add these two new clients.  We are already paying
checks for these two new clients.

One developer, three tools (Access, an FTP client and an encryption client)
and several months of running around like a chicken with our heads cut off,
talking to everyone in site about all kinds of nasty details.  Oh yes, and
~$30K so far.

They already have more insurers talking to them about paying THEIR claims.
I can't imagine why.

BTW, since I started working for them, we have designed an incredibly
complex call center application (you would not BELIEVE the business rules
that insurance contracts (policies) dictate) that handles many different
types of claims, all aspects of the business, including talking to
QuickBooks, mail merge, attachments to email coming in and imported into the
database, text file reports generated and attached to emails going out, FTP
etc. - closing in on 4 years of development on this app - for a grand total
of 99K so far.

I have always said, and I continue to say - Access is the most powerful RAD
environment in the world for database applications.  Throw in an Access
application framework... <grin>

John W. Colby
Colby Consulting
www.ColbyConsulting.com

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of artful at rogers.com
Sent: Monday, January 29, 2007 3:42 PM
To: AccessD at databaseadvisors. com
Cc: dba-SQLServer
Subject: [AccessD] Paean to the Access Development Team

In the beginning were Relational Databases -- a valiant attempt by the late
and lamented Dr. Edgar (Ted) Codd. His set-based theories changed the
database world. I wish he had lived 20 more years, so he could address the
new issues. (He did try, late in life, to address the OODB issues, but
didn't survive long enough to complete his arguments.)

Yes, Dr. Codd rationalized the world of databases as viewed from set theory.
But the most important and radical of Dr. Codd's propositions was that
statement X ought to work in implementations Y and Z. 

Vendors and their marketing staff view the world differently. Thus they
foisted upon Dr. Codd's universal language the Language Extension. And the
Language Extensions proliferated, on grounds similar to brand-name crack or
heroin dealers in Manhattan. 

The new mantra: "Adhere to the standards, but toss in a few really addictive
commands that are way cool and extend the language in proprietary ways."

Dr. Codd's rules were thus undermined by the capitalist system, at every
possible step. "Offer tempting extensions that force or at least coerce
total buy-in." Make it difficult or impossible to port code-X from
implementation Y to implementation Z. To the extent that you buy in, you are
our captive market.

Any reasonable (i.e. non-marketing) person would agree that this approach
totally violates everything Dr. Codd's achievements stood for. As an IBM
Fellow, Dr. Codd was above and beyond the fray of market competition. He
thought only of the big picture. Smaller minds plundered his ideas and the
result is an array of variants upon commands that ought to have been
standard across all implementations.

The ISO SQL projects notwithstanding, virtually every vendor persists in
redefining or extending the language in proprietary ways.  I have a tiny
book published by O'Reilly and written by Jonathan Gennick, which is a
Prince Valiant attempt to sort all this out and provide a Rosetta Stone.
Thank you, Sir Jonathan! You have saved those cross-implementation readers
such as I hundreds or even thousands of hours of investigative time. To be
objective, there are one or two subjects you haven't covered, but you are
the Valiant of the SQL Wars!

I began in dBASE not SQL (and expect that many readers will immediately
slight me for my origins), but even back then the strategic path was the
same. Wayne Ratliff and Jeb Long invented a language based on JPL-DIS. It
was called Vulcan, but after one ad in Byte magazine they discovered that
Harris Computing owned the name. Enter Hal Pollock, a marketing genious. He
suggested the name dBASE II, on the grounds that no one would buy dBASE 1.0.
He also created the legendary "bilge pump" ad. dBASE II took over the CP/M
and then DOS world by storm. A couple of years later, a vastly superior
product called KnowledgeMan came along, but could not compete against
Pollock's brilliant marketing of dBASE II. 

Despite numerous interanl arguments, Ashton-Tate refused to release a
compiler, and committed seppukku. A couple of frustrated, not to mention
opportunity-sensitive, A-T employees, met in a restaurant called Nantucket,
and  to conceive and devise a compiler for dBASE. The result was Clipper,
from Nantucket Software.

I bought into Nantucket big-time (not in shares but in development hours). I
wrote two books about Clipper, and I like to pretend that I helped lead the
way for these folks into O-O programming, but in reality I borrowed lessons
learned from playing with SmallTalk and other O-O languages.

The point is, Brian and Rich and Barry realized that the way to capture the
market is to provide 98% compatibility with dBASE syntax, but also offer
totally addictive extensions, which delivered much more power but also
trapped the developer into Clipper. The Clipper code would not readily port
to FoxPro or dbCompiler and most certainly not into dBASE. So, to the extent
that one bought in to the extensions -- and I bought in, big time, because
they were so powerful -- one excluded porting the code to other variants of
dBASE.

Jump-cut to the SQL world. Oracle releases Java extensions. MS releases .NET
extensions. Sybase struggles to tread water (not a slight on their team --
they are underfunded and carry the albatross of PowerBuilder compatibility,
etc.) and Borland tries to find a way to fit. Later, Gupta and Clarion and a
dozen others. The market is a vicious place.

The world is not flat, and here is an interesting example. Although I know
nothing about MS internal development and even less about the development
hierarchy, what I can deduce from outside is that the MS-Access team is seen
as a wart, if not a threat, to the marketing of all the .NET stuff. This, in
my view, is most unfortunate. Admittedly, there are things that an Access
expert cannot implement, but that covers the 20% of the people who insist
upon a BMW or better. The "Chevrolet" set would be most pleased to learn
that an Access developer can deliver a functional application for
approximately 1/10 the cost of the equivalent app developed in .NET.

The C# and VB.NET developers don't like to acknowledge this, nor does
Microsoft. But facts are facts. If you need to deliver a shrink-wrapped
package that depends on nothing (a laughable concept in itself, but let's
let that pass), then C# or VB.NET are the languages of choice. But if you
need to deliver something quickly and easily changed in the light of revised
requirements, then I vote Access as the best available platform. There is no
problem in directly connecting it to the SQL Server database of choice.
Granted, an Access developer cannot deliver an executable. This distinction
matters, apparently, to those who would bill you 10 times as much for an
equivalent project.

I cannot understand why Microsoft continues (over the past decade at least)
to slight the achievements possible in Access. This particular newsgroup is
ALL about what can be done in Access. I can cite numerous developers here
who have bolstered my argument, but I will cite only a few and hope those
whose contributions I didn't cite will forgive me): 

Bartow, Brock, Connelly, Carbonell, Colby, Der, Enright, Fields, Foust,
Harkins, Kjos, Hindman, Lacey, Lawrence, Matte, Mattys, McLachlan, Reid,
Salakhetitov, Skolits, Smolin, Tapia, Tejpal, Williamson, Wutka.

I wish all the best to MS-Access development team, and I hope that one or
two or three of said team occasionally visits our group, to learn how much
we appreciate their efforts, and to know that we understand what challenges
they face. All the marketing $ focus on .NET (which is very cool - no slight
on that team intended) but the Access team delivers top-quality stuff in
spite of its underfunding. 

Hats off to the Access development team. Without you, many of us would be in
serious financial trouble. Thanks to you, we can make a living. You give us
the tools and we discover ingenious ways to use them.

My $.02. 
 
Arthur Fuller
Technical Writer, Data Modeler, SQL Sensei Artful Databases Organization
www.artfulsoftware.com
--
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com




More information about the AccessD mailing list