This is a portion of a conversation between two of my cherished internet friends and fellow travellers, both gifted programmers. I thought that it might be interesting to the more general populace, rather than just the narrow world of Access developers. So here it is, in chronological order. I should emphasize that I deem both Martin and John most esteemed and respected colleagues, I've met John only once, but liked him immensely. I've never met Martin in the physical universe, but we have been communicating for several years, and I even got a credit in one of his books.
Sent: 04/09/2012 18:54
To: Access Developers discussion and problem solving
Subject: [AccessD] Access skills testing
Does anyone have anything on testing MS Access skills?
One of my clients wants to see what his applicants know.
--
John W. Colby
They have a Colby, why do they need anything else?That's a moving target if ever I've seen one. Consider 2003 v. 2007-10. However, it's true that at least some of the knowledge of old commands is portable. But I sense another problem here, and that would be that this question is asked in the absence of app-requirements, which I don't think is fair either to the applicants or to the client.
Martin
Sent from my Windows Phone
________________________________
Instead I might suggest that a description of the app-requirements might first be formulated, and then the questions to ask might just "fall out" of the requirements. For example, is the BE to be SQL Server or MDB or Accdb? That question alone matters hugely, and influences all subsequent questions, on that path at least. Then there would be the issue of user-quantity: 100 users is significantly different than 10. Another consideration is the quantity of locations: if it's only one, things become much simpler. If it's several, then other skills are required, such as the ability to set up a Terminal Services server and establish the connections to same. After that I would want to know the demands involve Office Automation, such as populating Excel spreadsheets or Word documents from data inhaled from the database, and whether such documents require translation to Acrobat files to be automatically emailed to Outlook recipients or perhaps some other email client.
IMO, without answers to these questions, I could not begin to devise a set of test questions to determine whether candidate A or B or C would be a good fit.
And there are several more questions, having more to do with the client's environment that the actual skill set. Does everyone wear ties, or shorts and tees? Are there rigid restrictions on start-and-stop time, or is the developer free to work her own hours? Are time zones involved (which might happen if the client does business in Asia)? How much technology-transfer is considered part of the gig (which means, do I not only have to write the app but also provide sufficient instruction for the in-house people to be able to perform maintenance)?
I can probably come up with a few dozen more questions, but the bottom line is, before we can proceed we need to understand the client's opinion about what defines a successful hire, and that means that we need to know the requirements of the app itself. Without this information, you and I and the client are in the dark, asking abstract questions such as "Do you know how to open the same form thrice?" or perhaps, "Can you write a class that abstracts the details of an argument to the OpenForm method", which questions, I daresay, do not begin to approach the immediate problems at hand. If there is no possibility in the given app to be written that a user will ever open the same form twice, why ask the question? On the other hand, if a given report must be able to accept a date-scope and/or a client scope, then that question is definitely worth asking: "How would you suggest that we accomplish this, and secondly, will your solution be portable from app to app?" In this case, that's how I would phrase the question.
There's one more thing that I feel that I should toss into this discussion: although I started out in dBASE-II and then Fox and then Access and then Oracle and then SQL Server, one thing I learned way back when is that the user should NEVER NEVER NEVER have access to the native tables. No No No! (If I'm sounding like Adele, I can live with that!) Nobody but God, which means the DBA, should be able to access a table, and if you have not accepted that fundamental truth, then go back to school and learn why. I learned from Dr. E.F. Cood and Fabian Pascal and Michale Stonebreaker, and also a few set-theory mathematicians, and after them, a few of the NoSQL people. Life goes on, and so does exploration of where this is going to get us, in the big picture. I admit that considering these giant brains, I am a follower, not a leader, But I also say that I walk into these arguments without baggage. I am looking for two things: correctness and speed. That's all I have to say about my decisions in this respect: at any given moment, I could be wrong and chosen the wrong horse. I accept that. But I have no favourite horses in this particular Kentucky Derby. I might have a favourite and might bet an unhealthy amount of loot on that gorgeous horse, but that doesn't mean that if another horse wins, I shall call the raced fixed. That's not where I go with this stuff. I have my emotional favourites -- of course I do! But that doesn't mean that I reject Evidence. Above all, I try to be objective in these matters, and if the evidence turns against me, I shall most happy to declare that I was mistaken. I am not out to win arguments, in the face of evidence. I am most willing to be proved incorrect. That is my nature.
--
On Tue, Sep 4, 2012 at 2:11 PM, Martin Reid <mwp.reid@qub.ac.uk> wrote:
They have a Colby, why do they need anything else?
Martin
Sent from my Windows Phone
________________________________
From: jwcolby
Sent: 04/09/2012 18:54
To: Access Developers discussion and problem solving
Subject: [AccessD] Access skills testing
Does anyone have anything on testing MS Access skills?
One of my clients wants to see what his applicants know.
--
John W. Colby
Colby Consulting
Reality is what refuses to go away
when you do not believe in it
--
AccessD mailing list
AccessD@databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com
--
AccessD mailing list
AccessD@databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com
Arthur
Cell: 647.710.1314
Prediction is difficult, especially of the future.
-- Niels Bohr
No comments:
Post a Comment