What is mentoring?  Listening?  Advising?  Helping?  I was looking for the definition of mentoring today and came across some interesting things.

dictionary.com lists two definitions:

1, a wise and trusted counselor or teacher.

2. an influential senior sponsor or supporter

These are both correct, but not very helpful to me.  Sometime later I came across an article that really expresses what I was looking for.

Mentoring is about one person helping another to achieve something. More specifically, something that is important to them. It is about giving help and support in a non-threatening way, in a manner that the recipient will appreciate and value and that will empower them to move forward with confidence towards what they want to achieve. Mentoring is also concerned with creating an informal environment in which one person can feel encouraged to discuss their needs and circumstances openly and in confidence with another person who is in a position to be of positive help to them

Parts of this initial paragraph really jump out at me.  I’ve listed the relevant keywords and phrases here with my thoughts on them from both being a formal/informal mentor/mentee:

• helping - Why am I not surprised the first verb in the description is so critical?  Mentoring really does boil down to helping someone else.  The mentee is still responsible for themselves and everything pertaining to the situation.  Whereas the mentor gives advice/opinions/guidance to help the person.
• achieve something - The goal might or might not be known to the mentee.  Sometimes there is a specific issue that one wants to discuss.   In that case there is a pretty clear goal.  Sometimes it’s just to hear advice on what is coming.  This is kind of vague.  For example, technical people are known for needing to improve their soft skills.  Yet we don’t tend to seek out advice on the topic.  A good mentor will bring it up anyway helping the person at least realize there is an opportunity out there.
• non-threatening way - This should go without saying.  The idea of mentoring is to be guidance not “do this or else.”
• appreciate and value - I found this phrase particularly interesting.  Usually I appreciate and value my mentor’s advice right away.  However sometime it takes time to sink in.  I received some advice related to answering questions about a year out of college.  About two years later, I told the person giving the advice that it finally clicked and now I understand what he was talking about!  At the time I did appreciate that the advice was given, but I wasn’t at the point yet where it could be useful.
• empower and move forward with confidence - The mentee really is responsible for themselves and the mentor is just trying to help that person succeed.
• discuss needs and circumstances openly and in confidence - One needs to know what’s going on to provide useful help and advice.  Yet often when we need advice, it’s because something problematic is going on or our innermost desires conflict with others.  Not the easiest thing to talk about in general.  Especially for technical people like us who are more comfortable with computers and logic.  Being assured of confidence allows one to “just talk” as if one is talking to a friend.  Sometimes that means your mentor (or one of your mentors) should be someone you know well or someone you don’t work with directly.
• informal environment - Some environments are more informal than others.  Part of managing someone involves mentoring and providing career guidance.  This type of mentoring is extremely valuable because a manager knows more about a person’s job than anyone else.  It’s also valuable to have someone to talk to who is NOT your direct manager.  For one thing, it’s uncomfortable discussing things directly relating to your manager with your manager.  For another, no matter how much you trust your manager, there’s still a nagging feeling that the person is your manager which affects openness.  It’s hard to present an idea you haven’t thought through directly to your manager.  It’s also useful discussing things with someone else to gather more points of view.  This “other person” to talk to doesn’t need to be formally named a mentor.
• in a position to be of positive help - There are multiple levels of help.  Sometimes a person just needs someone talk to.  Expressing ideas to someone else helps clear ones head and make connections between ideas.  This is the really basic level of help.  At higher levels of help, it advances it to making suggestions and asking questions to help the person think about solutions and next steps.

Formal mentoring tends to be easier to visualize.  As an example of informal mentoring, I talked to a collegue at JavaRanch (where I volunteer, not my “real” job) about something this weekend.  This is someone who I really respect - especially when it comes to process and team dynamics.  And with mentoring!  He asked me a bunch of questions to understand both the scenario and what I was thinking/what I wanted.  He also asked some higher level questions.  This was the most valueable thing for me.  If I had talked to someone I work with, this question would have been unlikely to come up because everyone would be thinking within the job and taking certain things for granted.  Now this is the only time I asked this particular person for advice (that I can recall.)  But I’ve absorbed so much from him over the years.  I think this shows that there is informal mentoring (”can I talk to you about this one thing” vs just learning from watching/listening to someone who doesn’t even realize they are mentoring.)

Hope everyone is enjoying the black-Friday/cyber-Monday sales. Personally, I haven’t seen many good ones this year but I did come across this gem in my inbox. It offers an impressive 20% off all their products if you happen to own a time machine:

Hope everyone had a nice Thanksgiving!
-Scott

There were a number of comments about my recent article on the negative effects of too much database normalization so allow me to expand the topic a little more. The most consistent comment I saw was that while many of you agreed with me in principle that too much normalization can lead to poor performance, the country name example was a bad choice. As a former teacher, I tend to choose illustrative examples that are easy to understand and explain. As a blog writer, I also tend to forget the web is full of nitpickers that will argue with you unless presented with a concrete example from the real world.

My favorite comment was about how in Europe a poster’s country name has changed 3-4 times in the last few years. I could argue most Americans would be shocked to see their country name or state name change, but I have to think… how hard is it to update the name of a country in a database even if it does change once a year? The trick with database denormalization is you have to write code that updates two separate sets of items, and in a lot of cases this is less difficult than many of you imagine. If updates are uncommon (static) as I mentioned, the performance gain from reading can far outweigh the rare cost of performing an update.

Perhaps its better to move on to a better example of where denormalization of data can play an important part: managing user permissions. And no, this is not to be confused with database security (which is completely useless for user/application-level permission management). Let’s say you have a tree-based system of widgets. Widgets can have sub-widgets and so on such that each widget has only one parent but can have many children. Now let’s say users within the application (again not to be confused with database users) are assigned read/write roles on individual widgets as well as to entire subtrees of widgets. For example, Bob may be able to read the entire tree, but he can only write to select widgets A, B, and C or a select sub-tree of widgets D which contains X, Y and Z. Now, how would you design a database system that allowed for quick determination of a user’s permissions on a node, considering the user may be accessing dozens or hundreds of nodes at a time, such as in a tree viewer?

Since the height of the tree is unbounded, we would need a database schema that allowed for arbitrary height. A common solution is to have a single table, let’s call it WidgetTable, with a field for the parent reference, let’s call it ParentId. Obviously, the root node would have a null ParentId. Given a node X, how do I quickly determine if X is writable? In this case, the user may have write access to X directly or through a parent node somewhere up the tree.

The most common answer, since SQL doesn’t support unlimited-recursive queries of this nature, is to query the parent and check if its writable, then query the parent’s parent and check if that’s writable, and so on until you find a writable permission for the group or you hit the root. Well, let’s do worst case asymptotic analysis on this! The worst case would be if you had one really long chain of single nodes with X being the leaf and the writable flag being on the root. In this case you need to perform O(n) number of queries where n is the number of nodes in the database. The performance of this solution in worst case could be awful.

Amortized (average case) analysis would find better bounds, but remember the earlier stipulation that you may be viewing dozens or hundreds of widgets at once? In worst case, that would be O(n*m) where n is the number of nodes in the table, and m is the number of nodes you are looking up. One of the best solutions in a situation like this is to maintain a denormalized lookup table, let’s call it UserToWidget that maps users to nodes they currently have permissions on, taking all parent relationships into account. With such a table in place (and hopefully good indexes on that table), determining a user’s permissions on a large set of nodes can be done in O(m) time, or near constant depending on the number of nodes you are looking up.

What’s the cost here? Maintaining the UserToWidget table of course! In Oracle, there are options such as materialized views which can help. You could also use database triggers to maintain the relationships anytime the higher-level permissions change. But let’s say you want a solution that isn’t database specific, which most of us do, then you could write application code that acts anytime a user’s permissions are updated, to seek out and update changes to affected nodes below the node you updated. If database reads are more common than database writes (which I suspect they are if you’re viewing hundreds of nodes at a time), the cost of performing the complex update will be far less than the cost of quickly being able to read a widget and determine its permission for a given user.

I hope this example helps to illustrate cases where pure normalization can be too costly for practical use. If not, try reading it again

As someone with a long history in database optimization and who even did their Master’s project on Database normalization, I’m probably the last person in the world to argue against database normalization. From a theoretical standpoint, database normalization is a wonderful thing, helping to organize your data into easy-to-manage and understandable parts. For this article, I will play devil’s advocate and argue why too much normalization can be a bad thing.

The years of working in the professional software industry has taught me the practical implications of a fully normalized database system: it’s often slow. It’s a non-trivial issue to design a good database schema that is both fully normalized and performs well on a variety of circumstances. I think back to some systems that I have seen in which a single common query joins dozens or more very large tables. Keep in mind, the more normalized your data is, the more joins that are required. For example, if you normalize a user’s address into a separate table (so the user can have a set of addresses) you have to join the user table with the address table every time you want to display their address. Then, you often have to join with a city, state, and country tables for full normalization.

Let’s take some of the advantages of database normalization and look at why they might not be so great:

Normalization saves space, but space is cheap!
The most obvious advantage of normalization is spacing saving. For example, instead of listing a “United States of America” for 10,000 records in a Users table, I can create a country table that lists the text once, then create a reference with an integer. Clearly, 10,000 integers take less space than 10,000 24-digit text fields. But these days, space is cheap! Terabyte drives are now common, so would normalizing some of the fields of a table really save much space? Probably not. I’m not saying denormalize all fields, but there’s some where the advantages to space are negligible.

Normalization simplifies updates, but reads are more common!
Another common reason for normalization is to simplify updates and reduce anomalies. For example, in the case of “United States of America” text in the Users table, its a lot easier to update/change the text in a single record than it is to update 10,000 records. But that brings up an interesting point, how often does the text “United States of America” change? I would argue almost never. There are examples where data does change more frequently, such as a user’s address, but its common knowledge in database systems that in most tables reads are far more frequent than writes. Therefore, if you have a table with relatively stable data that changes infrequently, normalization isn’t buying you a lot.

Performance, performance, Performance
Database administrators spend the bulk of their time worrying about performance, how to optimize queries and table structure, and in that regard normalization rarely helps. Those calls people tend to get at 2AM about the system crashing over a specific query? They often related to normalization in some way. If you have a case where you can eliminate a normalized table with minimal impact on functionality, it is better to do so. For example, in the case of address you might need users to be able to have multiple addresses (1-to-many relationship), therefore there’s no way to avoid normalizing the data into a separate table. But there are other cases such as with States and Countries, where constantly joining to two completely static tables is not helping. You can still have the tables present in order for a user to select a state or country from a drop-down list, but it may be better to save the text of the state or country in the user’s table, instead of a reference.

Conclusion and Next Article
In this article I played devil’s advocate arguing that too much normalization can be a bad thing. On the other end of the spectrum, too little normalization can also be a bad thing. The mark of a good database designer and software developer is the ability to find a good balance between the two that matches the database structure against the actual or expected use of the system. In the next article, I will discuss some of the tools available in most databases to help combat the performance issues of normalization such as indexes, triggers, and materialized views.

I was watching a Google Tech Talk on Dependency Injection.  Sixteen minutes in the speaker gave an interesting example of the Law of Demeter: If buying item for $25 in store, do you hand clerk $25 or give clerk your wallet and have him/her retrieve the $25.

This got me thinking about why we so frequently violate the Law of Demeter.  I can think of three reasons that come up frequently.

Familiarity with code/process

When we think about what needs to be done, we think “I’ll get out my wallet and get the money.”  This does translate literally to handing the clerk the $25. Since the wallet is an inanimate object, we think more about the wallet than the cash.

Wallet wallet = customer.getWallet();
Cash cash = wallet.getMoney(25);
customer.payCashier(cash);

If it were a person, we would think of the separate step.  If a six year old was buying something, he might think of the transaction as “ask mommy or daddy for $25 and then hand that to the clerk $25.”  This translates better to:

Cash cash = parent.getMoney(25);
customer.payCashier(cash);

In the real life scenario of an intermediary person, the requestor (child) never even rifles through the wallet.  (Granted in the real life scenario, the child doesn’t really ask the wallet - rather the person holding the wallet.)

Access data we shouldn’t

This is really a variant of being overly familiar with all the objects/data.  We tend to think about what we are doing rather than from the object’s point of view.

Can’t touch other code

To me this is the most interesting reason.  We have an object that we think really should have a new method but can’t touch that object.  One solution to this is to create a new object that holds the original and does contain the new method.  This solution is useful when the object belongs to a third party and really can’t be changed.  Sometimes it’s more of a mental block.

I recently came across a case where two numbers where compared via a string comparison (and some other logic) because the author didn’t want to touch the object that owned the data (and was exposing it via a string.)  After further discussion we concluded the owning object really needed a method that told us if this number was positive or negative.  And the complex logic was a “code smell” pointing us to that fact.

Personally, I find the reasons behind things to be more interesting than the actual instance.  It’s easy to say “don’t violate the Law of Demeter.”  Discussing why is plenty interesting (as in the Google Tech Talk.)  It’s thinking about what drives us to such things that helps actually prevent them.