I recently spent two days training a group of about 30 developers and DBAs out east. As with any sizeable collection of technologists, the level of expertise and the years of experience varied greatly (and don't always go hand in hand!).
I was pleased to see that everyone seemed to get along well, there wasn't any great reluctance to ask questions (that is, admit ignorance), and several attendees didn't hesitate to challenge my ideas and suggest other ways of doing things. Just the way I like it!
Yet, as with so many other organizations I'd visited, and developers I'd trained, they hadn't come up with any thorough and effective ways to share information, techniques and code among the various application teams.
I've always been surprised at this situation. In company after company, there will be dozens to even hundreds of PL/SQL developers working virtually side by side, yet also coding largely in isolation. Some companies will hold occasional, informal brown bag lunches, others might make some limited gestures at using Sharepoint or Lotus Notes or wikis to share some ideas. But it seemed that many developers would still end up reinventing the wheel, over and over again.
What a waste!
Now, I don't think this situation arises because developers don't want to share, or want to write everything from scratch. It can just be very hard to organize material, make it accessible, keep it current, create libraries or toolboxes of generic, reusable code, and so on. Everyone's busy and resources are limited.
I got to thinking about this on the plane ride home (yes, I am writing this at 37,000 feet) and realized that this situation is never going to change. Resources will always be tight. Time will always be precious. And expertise will reside largely in the brains of individuals, not written down on paper or deposited in some collaborative repository.
I had a revelation on the plane: if this is how it is going to be, why fight that? Why not accept reality and work with it?
Rather than trying to build an elaborate structure for sharing knowledge, in other words, perhaps we should try something that is very simple and build directly from individual expertise, with a minimum of commitment and overhead. If that works, and everyone starts experiencing the concrete benefits of sharing, then perhaps a company will invest (more) resources to promote this sharing.
Enter the Expertise Matrix (see below, and download it here).It's nothing more than a list of topics relevant to any PL/SQL developer (and definitely not all of them). Next to each topic is the "In the Know" column: a space that should contain the name (or names) of individuals in your organization who have experience and some depth in that topic. And at the bottom of the matrix, you will find a section that you can fill in with your own application-specific areas of interest/concern.
How does it work? Very simply: circulate the matrix to your developers. Have them fill in their names and contact info next to any of the topics in which they feel they know enough, have enough experience and depth, to be able to answer questions from others (or share their code).It's perfectly fine to have more than one name volunteered for a topic.
Once it is filled out, post the document in whatever shared space you have, or simply email it to everyone in the organization.
Every quarter or so, ask everyone to update the matrix: take their name off of a topic if they’ve grown rusty or haven't kept up, add their name to reflect recent experience and study.
Great, so the Matrix exists. Now what?
Now, anytime a developer runs into a problem, or has trouble understanding a particular feature of PL/SQL, or wonders if the code they need to do XYZ might already have been written by someone, she can simply open up the document (or glance at the printed version that is hanging on the wall of her cubicle), find the name next to the topic, and give the person a call (or pay a visit). That issue-specific expert will then provide assistance as needed (within the constraints of their time and knowledge, of course).
The reason I think this might actually work is that...
(a) people will have volunteered their names, so they are agreeing implicitly to share what they know and are therefore more likely to do so, and
(b) specific and direct requests for help are both easier to deal with and harder to evade than upfront tasks like "Put together a toolbox of all the useful code you have ever written in this area." or "Write a document explaining the best ways to do X, Y or Z." Not only is it lots of work to produce such resources, but they get stale quickly, and are often not utilized – who's going to bother doing that?
(c) incentives: I urge any manager who decides to adopt this strategy to build incentives into the Matrix. Every six months, poll your developers. Find out which of the experts were most helpful. Publicly thank them and give them gift certificates, or something concrete to express your and the team's gratitude.
And if you like my concept, but don't particularly like my matrix, don't hesitate to change it all you want to make it fit your organization's needs and common problem areas.
Finally, I would love to hear about any experiences you have with the Expertise Matrix, so please don't hesitate to get in touch with your stories and ideas for improvements.
Expertise Matrix
|
Area of Interest
|
In the Know and How to Contact Them
|
|
Package construction / modularization
|
|
|
Exception handling
|
|
|
PL/SQL tuning
|
|
|
Testing PL/SQL programs
|
|
|
Invoker rights (AUTHID)
|
|
|
Data modeling
|
|
|
Code Review
|
|
|
Coding Standards
|
|
|
Oracle data dictionary
|
|
|
Security (encryption, row level security, auditing)
|
|
|
Regular expressions
|
|
|
Globalization/localization
|
|
|
Calling Java from PL/SQL (JSPs)
|
|
|
Calling C from PL/SQL (external procedures)
|
|
|
SQL
|
|
|
SQL construction
|
|
|
SQL optimization
|
|
|
DML triggers
|
|
|
Table Functions
|
|
|
BULK COLLECT and FORALL
|
|
|
Dynamic SQL
|
|
|
Dynamic PL/SQL
|
|
|
Datatypes
|
|
|
Strings
|
|
|
Dates, Timestamps, Intervals
|
|
|
Numbers
|
|
|
Object Types (object-oriented development)
|
|
|
Collections
|
|
|
Large Objects
|
|
|
XML
|
|
|
Cursor variables (REF CURSORs)
|
|
|
Supplied packages and Subsystems
|
|
|
UTL_FILE
|
|
|
DBMS_OUTPUT
|
`
|
|
DBMS_SQL
|