One of the real strengths of Access as a development platform is that in the hands of a capable soloist, it can handle projects that, developed in another environment such as C#, would require require a team of developers as well as considerably more time. This is not to say that such development tools are overkill; they most certainly are not. It comes down to some combination of target market, development schedule, developer skills available, budget and so on. That said, Access is an excellent vehicle for developing a wide variety of applications.
As the old saying goes, there are three types of developer: those who can count and those who can’t. In this context, I’m
dividing Access developers into two camps: soloists and accompanists.
Soloists are one-person shops; they design the database, the
User Interface more often than not, the release schedule (as opposed to the
project’s deadline), the testing procedure if any, the on-line help if any, and
the documentation (user and system), if any. As you can see, as we step through
the list, the phrase “if any” recurs frequently. This is typically due to one
or both of two facts: a) project size, and b) budget available. A soloist
almost by definition works on bite-size projects, most often for small
businesses and occasionally for much larger organizations such as government
ministries, which in my experience might have a dozen projects on the go at
once, outsourcing each of them to a soloist, thus mitigating the risk that all
dozen projects fail; it is to be expected that one or two will either miss their
budget or their deadline, or fail completely. A soloist project might take
anywhere from a few weeks to a few months to develop and release; seldom
longer. But the point is, such a project is of a size that a single developer can manage.
Accompanists have typically never run a project, and often
know they are not ready for that level of responsibility. Their work experience
is often in large corporate or governmental organizations, and the project size
mandates both a larger timeline and a team of developers, one of whom takes the
lead. This sort of project might take, say, 5000 person-hours to complete.
As the person in charge of hiring, you will know at once
whether you are looking for a soloist or an accompanist. It’s not that one is
“better” than the other. To think so is to miss the point, and let me try to
explain why.
A soloist does everything herself. To put it another way, she
is a team player only when forced to become one, typically due to lack of an
immediately next client – in which situation, hard-pressed to cover next
month’s expenses, she begins scanning the career sites and flinging
CVs into the cybersphere.
An accompanist is first and foremost a team player. She
knows that he cannot perform some or all of the tasks masterfully, yet is
confident that she can provide a meaningful contribution to some aspect of the
big picture. She wants to learn from the experience of the team members.
Negatively stated, she wants to be shielded from full responsibility for the
failure of the project. More positively stated, she wants the opportunity to
surround herself with more experienced people, and is eager to learn. From the
hirer’s viewpoint, she is willing to work lots of unpaid hours for the
opportunity to learn and grow.
Any given
project may be divided into three chunks:
a) Hard
– designing the database and the overall user interface (UI); this might be two
separate roles, and in large projects, most often is. DB designers are seldom
gifted at UI design. There is a huge benefit in separating these roles: the
strength of the DB design can be combined with the strength of the UI, and even
better, the UI can be revised and enhanced without touching the rest of the
project.
b) Medium
– implementing the required queries that will support the forms and reports.
This requires the ability to understand database diagrams, know all about the
relative merits of various join types (and in the case of a SQL back end, the
subtleties of calling stored procedures versus views, etc.).
c) Easy
– creating basic forms and reports, based on queries that have already removed
the heavy lifting from the task.
A well-assembled team will consist of one or
two members of each class. Follow the chain. The DB Designer figures out all
the Normal-Form stuff and how deep to go with it (3NF, 4NF, BCNF, 5NF)[1]. The
second aspect of this, which may or may not involve a second team member, is to
design the overall UE. I am the first to admit that I would prefer that someone
else design the UI. I can deliver basic UIs that work, but if you’re looking
for elegant layouts, l need help.
When considering assembling a team, it’s useful to bear in
mind Brooks’s Law[2]:
The more programmers you throw at a problem, the longer it will take to solve.
This is neither maxim nor theory; it is fact, borne out in thousands of
projects worldwide, on everything from mainframes to PCs. The manager is thus caught
between two pincers (which I might suggest is the definition of that position):
Job A is to listen to your underlings’ estimates and shave them down; Job B is
to fudge up those estimates and fatten the project’s schedule, explaining to
your superiors why it will take so long, all the while knowing they will shave
you back (hence the original fattening).
So. We have soloists and accompanists, and you need to know
which you’re seeking. I avoided the word “classes” because neither is “better”
than the other, in the same sense as neither a cow or a goat is better than the
other – both produce milk and ultimately meat – everything depends on the
environment.
Know which you need. If you need a soloist, fine. In that
case, prior experience in the business domain of interest may be paramount. If
you need an accompanist, other factors come into play; as I tried to describe,
there are levels, and when dividing the Big Picture into Smaller Pictures, you
need to be aware of which aspects can be handled by developers with which
levels of experience. Don’t try to hire a crew of experts; not only will egos
get in your way, but you’ll be overpaying somebody for doing easy work.
The worst mistake you could make is to try to assemble a
team from a group of soloists. Egos, programming styles, and a dozen other
things as trivial as one’s ability to carry a conversation at the coffee-making
machine, will come into play.
[1]
There’s lots of information on-line about these refinements. If you need more
info, visit www.artfulsoftware.com.
[2]
“The Mythical Man Month” by Frederick J. Brooks, is an absolutely essential
read for any professional developer, regardless of programming language(s)
chosen.
