Tuesday 13 November 2012

What to know before hiring professional Access developers

My Australian friends at Access Guru liked my post about "The Access Developer's Dilemma", and asked what I thought about the process of hiring Access developers. I thought that I'd share my response here.

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.

No comments:

Post a Comment